EPICS Controls 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  2021  2022  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
<== Date ==> <== Thread ==>

Subject: Re: External source code repository
From: Andrew Johnson <[email protected]>
To: "Rees, NP (Nick)" <[email protected]>
Cc: [email protected], Mark Rivers <[email protected]>, Tim Mooney <[email protected]>
Date: Fri, 28 Apr 2006 12:57:11 -0500
Rees, NP (Nick) wrote:
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.
There are EPICS sites for whom the GPL is not an acceptable license. I
don't want to get into the whole Free Software debate here, I just
wanted to point that out.
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.
In which case the BSD and MIT (X11) licenses are not OSD compliant
either, because they don't require that source be included with binary
distributions either (which they both permit).
The EPICS Open license was written by Argonne lawyers to satisfy the
disclaimer requirements of the US Department of Energy, whose approval
we had to get before relicensing the code. It was intended to be
BSD-like in that it would not restrict what could be done with the code
after release, other than to retain the license conditions and copyright
notices, and it has been accepted by the Free Software Foundation as a
Free Software license conforming to their requirements. IANAL so I
can't give advice on its compatibility with the GPL, but personally I
believe that EPICS licensed code can be included in GPL licensed
programs and distrbuted under the terms of the GPL.
So, there are a number of possibilities:

1. I can propose to the community that we start using source forge for
   driver/application/extension that can be release under an open source
Personally I have always advocated that a program's author/site should
decide how and where they maintain their source code repository. We are
at Argonne not allowed to create projects on SourceForge, I believe
because of the agreement that Argonne would have to sign with them.
2. We can try and get the EPICS license OSI approved.
This might be hard to do now, since OSI are trying to reduce the number
of Open Source licenses in use in order to remove future compatibility
problems. However if you wish to try this feel free...
3. We can try and get the EPICS license changed.
Given what I wrote above, do you still think anything needs changing in
the EPICS license?
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.
This is my position on the matter: I would like to move the existing
EPICS code (and the EPICS website) onto an internet accessible server
that is under our control (but not on the current APS web server
machine, since there are restrictions on what can be done there and they
will be getting even more strict in the future), using Subversion for
the repository and Apache for the web server.
The aim would be to permit everyone read-only access to the repository,
and also be able to give out commit priviledge to different individuals
for different parts of the repository (or more likely with SVN to have
multiple repositories with different access rules). As before I don't
think we should try to force people to use the central repository, but
we could provide it as an option for EPICS-related projects. Projects
that use our SVN would also be allowed to provide web pages that could
be integrated into the EPICS website.
I have not pushed this idea internally yet, but I don't see too many
objections arising, and I think our IT group would be happy with it.
Would you see this as an acceptable solution instead of SourceForge?

- Andrew
There is no S in exprexxo.

External source code repository Rees, NP (Nick)

Navigate by Date:
Prev: RE: External source code repository Liyu, Andrei
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  2021  2022 
Navigate by Thread:
Prev: External source code repository Rees, NP (Nick)
Next: RE: External source code repository Mark Rivers
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
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 ·