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.
On 02/27/2014 11:48 PM, Richard Fontana wrote:
> Yes. I'm currently convinced that a new copyleft license is largely
> pointless without an 'Affero provision' by default. However this makes
> the drafting effort much more difficult. I actually think my 1-2 hour
> attempt, while quite suboptimal, is better than AGPLv3 or any
> predecessor licenses that tried to tackle this issue (typically by
> expanding the definition of 'distribution', an unworkable approach if
> you ask me).
It may be instructive to clarify the difference between the AGPL
and the "long talked about" LAGPL.
There are a couple of interpretations of the AGPL
1. Free all the softwarez
The source for all the software on the host providing the network service
must be provided as well as that on any hosts communicated with in the
process of propagating the service.
2. Free the implementation
The source for all the software on the host involved in providing
the network service must be provided.
3. Free what *would have been* conveyed
If the object code used to provide the network service had
been conveyed the same source must be provided as if
it had been conveyed under the GPL. One could imagine
this comprises the set of linked object code;
This may be the closest to the following snippet from
If some program on this server is released under the GNU Affero GPL,
the server is required to offer the users the corresponding source of
that program. That is good, but having this source code does not give
them control over the computing done on that server. It also does not tell
them what other software may be running on that server, examining or
changing their data in other ways.
None of these are likely to be an accurate characterization of the AGPL.
However if we pretend that the AGPL means #1 then LAGPL might mean
#2 or #3.
If the AGPL means #2 then LAGPL might mean #3.
If the AGPL means #3 then the LAGPL might mean that only the
source code for the "library" part of the covered work must
have source code provided:
The "library part" of the covered work might be defined as the
modified implementation of any API in the covered work, but not *new* API's
which are not present in the covered work. Of course this approach
is problematic as any new API almost certainly has derived from
the covered work.
With this context can we reach consensus on the line between
AGPL and LAGPL?
Does the answer to this question inform our understanding
of Network Service Source ("NSS") in copyleft-next
§3. Network Services Condition?
Does the answer to the AGPL/LAGPL question suggest that copyleft-next
needs an optional "Lesser" Network Services Condition?