Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: External source code repository
From: "Liyu, Andrei" <liyua@ornl.gov>
To: "Rees, NP (Nick)" <nick.rees@diamond.ac.uk>, core-talk@aps.anl.gov
Cc: "Williams Jr, Ernest L." <ernesto@ornl.gov>, "Pelaia II, Tom" <pelaiata@ornl.gov>
Date: Fri, 28 Apr 2006 09:01:02 -0400
Hi,

We discussed this problem on SNS ORNL.

We decided to add EPICS license to source code.
We decided that we are Ok with binary too because we bought MVC+, Qt and
other software package.

Maybe I am mistaken then Ernest and Thomas will correct me. Maybe they
will add comments - why, what ...

Have a nice day, Andrei Liyu.



-----Original Message-----
From: Rees, NP (Nick) [mailto:nick.rees@diamond.ac.uk] 
Sent: Friday, April 28, 2006 7:15 AM
To: core-talk@aps.anl.gov
Subject: RE: External source code repository

Hi Guys,

I was a bit disappointed not to get a response from anyone except Mark.
Can someone explain the current EPICS license situation? What are people
opinions about this? Should we discuss it at the EPICS meeting?

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713

> -----Original Message-----
> From: Rees, NP (Nick) 
> Sent: 19 April 2006 12:20
> To: 'core-talk@aps.anl.gov'; 'Mark Rivers'; Tim Mooney
> Subject: External source code repository
> 
> 
> Hi,
> 
> One result of the two synApps meetings at Diamond was a 
> desire for an external, site neutral, source code repository 
> for synApps type applications and possibly EPICS extensions. 
> The reason is that because the wide developer base for 
> synApps and extensions, and the modern security concerns, 
> creates to much overhead to authorise all the potential users 
> to have access to one of our local site's repositories.
> 
> Another decision we felt was reasonable was to host the 
> repository with subversion, rather than CVS, since this makes 
> file renames and other directory operations traceable. For an 
> external repository, this is particularly important.
> 
> The obvious place is Source Forge - so I waited until the end 
> of February when Source Forge became subversion hosting and I 
> have now created an epics project on source forge.
> 
> So far this is all speculative - it is just a proposal, but I 
> wanted to ensure I had the name reserved. What I now want to 
> do is explore the details. The biggest problem seems to me to 
> be licensing. A lot of code has been developed by people who 
> can release under an Open Source license (I chose GPL as the 
> initial default license for the EPICS project), but some can 
> only be issued under the EPICS license.
> 
> The problem is EPICS license is not OSI approved (and all 
> Source forge code must be issued under an OSI approved 
> license), and hence anything tainted with it may not be able 
> to be submitted to source forge. OTOH, the EPICS pages say 
> that the EPICS license is designed to be OSD compliant, but 
> has not be submitted to OSI for approval. Reading the 
> licenses, my main concern is that the EPICS license makes a 
> distinction between copies in source and copies in binary 
> form - which kind of implies that binaries can be distributed 
> without source. The OSD explicitly forbids this.
> 
> So, there are a number of possibilities:
> 
> 1. I can propose to the community that we start using source 
> forge for any
>    driver/application/extension that can be release under an 
> open source license.
> 2. We can try and get the EPICS license OSI approved.
> 3. We can try and get the EPICS license changed.
> 4. We can try some combination of the above.
> 5. We can drop the whole idea altogether.
> 
> The real problem with 1 is that it might stop any DOE person 
> from touching the code, which is not the intention. Hence, I 
> would like to find where we are on the true open source 
> nature of EPICS and whether we can try and move away from the 
> DOE-centric position we still seem to be in. Any suggestions, 
> comments, ideas are welcome.
> 
> Cheers, 
> 
> Nick Rees
> Principal Software Engineer           Phone: +44 (0)1235-778430
> Diamond Light Source                  Fax:   +44 (0)1235-446713
> 


Navigate by Date:
Prev: RE: External source code repository Rees, NP (Nick)
Next: Re: External source code repository Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: External source code repository Rees, NP (Nick)
Next: Re: alarm hook Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·