copyleft-next March 2014

copyleft-next@lists.fedorahosted.org

3 participants
3 discussions

EPL 2.0
by Richard Fontana 27 Apr '15

27 Apr '15

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: https://dev.eclipse.org/mailman/listinfo/epl-discuss 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 discussed here. 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. - RF

2 1

Impending release of copyleft-next 0.4.0
by Richard Fontana 27 Aug '14

27 Aug '14

Hi everybody! 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: https://gitorious.org/copyleft-next/copyleft-next/raw/3baab310f662811ba48d8… The most notable changes are the following: Section 2b: (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. Section 3: 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 'Proprietary License'. I have eliminated the effort to include an Apache License 2.0 section 5-style mechanism for formalizing the 'inbound=outbound' rule. - RF

5 9

LAGPL
by Tom Marble 08 May '14

08 May '14

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; http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL This may be the closest to the following snippet from https://www.gnu.org/licenses/why-affero-gpl.html 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: http://www.gnu.org/licenses/gpl-faq.html#WhySomeGPLAndNotLGPL 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? Comments welcome! --Tom

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next March 2014