I thought about doing something like what's done with MPL-2.0, but my understanding is that the exceptions to GPL are important. Maybe I'm just thinking about it too hard.
e.g. I believe that all of these are valid permutations... EPL-2.0 EPL-2.0 with GPL-2.0 EPL-2.0 with (GPL-2.0 with Classpath-exception-2.0) EPL-2.0 with (GPL-2.0 with Assembly-exception-2.0) EPL-2.0 with (GPL-2.0 with Classpath-exception-2.0 with Assembly-exception-2.0) etc. Again, I may just be thinking about this too hard. Wayne On Mon, Aug 21, 2017 at 9:00 PM, Richard Fontana <rfont...@redhat.com> wrote: > Regarding the secondary license support, should it follow what's done with > MPL 2.0 (SPDX has separate license identifiers for MPL-2.0 and > "MPL-2.0-no-copyleft-exception"), thus something like "EPL-2.0" and > "EPL-2.0-copyleft-exception"? > > I don't like the "MPL-2.0-no-copyleft-exception" myself as I find it > confusing/counterintuitive, given that MPL-2.0 itself is a copyleft > license, the 'exception' is not some sort of general exception having to do > with copyleft (but rather is GPL-family-specific), and the GPL > compatibility feature of MPL 2.0 is not described or (I think) generally > thought of as an "exception". > > Richard > ------------------------------ > > From: "Wayne Beaton" <wayne.bea...@eclipse-foundation.org> > To: spdx-legal@lists.spdx.org > Sent: Monday, August 21, 2017 8:52:44 PM > Subject: New License/Exception Request: EPL-2.0 > > > > The EPL-2.0 has been approved by the OSI and the Eclipse Board of > Directors. We'd obviously like to see it included in the SPDX license list. > FWIW, we're updating our legal documentation requirements to make heavy use > of SPDX. > > 1. License name: Eclipse Public License 2.0 > 2. Proposed Identifier: EPL-2.0 > 3. URL: https://www.eclipse.org/legal/epl-2.0/ > 4. The license is OSI-approved (though only just recently and so it's > not posted yet) > 5. The Eclipse OMR and Eclipse OpenJ9 projects are both currently > switching over to the new version and we expect numerous other existing > Eclipse projects do so as well. > 6. The Eclipse Foundation is investing in the use of SPDX and since we > expect many/most of our projects to update to the new version of the > license, having representation in SPDX is critical path. > > > > The wrinkle, I think, is that there is a provision in the license for > "secondary license" support. A project team may opt to declare that their > project code is GPL compatible. I believe that this means that GPL > compatibility is an exception; this is compounded by the ability to include > various exceptions to the GPL. > > The OpenJ9 project, for example, will be EPL-2.0 with GPL-2.0+CPE+AE. I > think that this would manifest something like this: > > EPL-2.0 WITH (GPL-2.0 WITH Classpath-exception-2.0 WITH > Assembly-exception-2.0) > > I'm a little concerned that I don't see Assembly-exception-2.0 on the > exceptions list. I assume that this means that I'll have to shepherd this > exception through as well. > > Is this syntax even supported? > > > > > FWIW, in a fit of stupidity--after misreading a comment on another > issue--I opened a GitHub Issue to track this. > > > > > Thanks, > > > > > Wayne > > -- > Wayne Beaton > Director of Open Source Projects > The Eclipse Foundation > > _______________________________________________ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal > -- Wayne Beaton Director of Open Source Projects The Eclipse Foundation
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
