It came to my attention earlier this week that the Eclipse Foundation
had begun public discussion of the drafting of a new version of the EPL.
So far little has been said on the relevant mailing list:
This caught my attention though:
http://dev.eclipse.org/mhonarc/lists/epl-discuss/msg00013.html as it
relates closely to the 'rule vs standard' issue that in the past was
The suggestion made by Jim Wright is interesting as at a high level it
bears some relationship to what I have been thinking about lately for
copyleft-next. It starts out with MPL-style copyleft as a conceptual
basis and tries to define something more extensive, but (unlike EPL
1.0) attempts to do so by articulating something bright line instead
of relying on some legal notion of derivative works.
After a considerable and unfortunate hiatus I have resumed development
of copyleft-next and feel it is close to appropriate for release of
v.0.4.0. Especially given the dormancy I thought I would point any
remaining and interested readers of this list to the latest draft:
The most notable changes are the following:
(Non-GPL) license compatibility is now dealt with through reference
to a brief illustrative appendix list of licenses (which include MPL
2.0, EPL 1.0, and LGPLv3 as well as some non-copyleft licenses).
The issue of compliance with export control regulations is dealt
with, something which I have come to view as sorely lacking in the GPL.
This is a new section containing an attempt at an Affero-style
condition. Don't laugh at this attempt without trying it yourself
first (though I should disclose that my attempt took place within the
space of an hour at most this evening). The inclusion of this condition
is notable given that at an earlier stage I specifically had decided
not to have an Affero-like condition in the main body of the license.
The original licensor can opt out. There is a special 'Corresponding
Source' definition here that is not identical to the one for
distribution of Object Code.
Section 4: The old 'poison pill' provision now includes a definition of
I have eliminated the effort to include an Apache License 2.0 section
5-style mechanism for formalizing the 'inbound=outbound' rule.
in the third line of the following section:
> "Separate Work" means a work that is separate from and independent of
> particular Covered Code and is not by its nature an extension or
> enhancement of the Covered Code, and/or a runtime library, standard
> library, or similar component that is used to generate an Object Code
> form of Covered Code..
"... and/or runtime library, ..." is confusing because of the part
before that says, "... and is not by its nature..."
before grokking the meaning of this paragraph, i was having difficulty
parsing this section since i didn't know whether the prior negation
still applied after "and/or" or not.
it could be more clear by saying:
> enhancement of the Covered Code, and/or is a runtime library, ...
(by inserting "is" after "and/or")
if this is a welcome addition, i'd be happy to make a pull request,
unless you want to add it yourself. :-)