copyleft-next August 2012

copyleft-next@lists.fedorahosted.org

11 participants
19 discussions

Update 2012-08-02
by Richard Fontana 04 Dec '12

04 Dec '12

Here's an update of what's been going on with the copyleft-next draft. Deletion of dl-supp =================== The biggest change of the past week was my deletion of "dl-supp". In an earlier commit, I moved the "anti-Tivoization" provisions derived from the second part of GPLv3 section 6 into a supplementary document which an initial licensor could place on a new program. I now see no point in even having it as a supplement. Thus, copyleft-next has no anti-Tivoization provisions, and so the patch originally proposed by mcgrof (see <https://lkml.org/lkml/2012/7/12/401> ) has now effectively been applied. A lot of careful thought and discussion went into the corresponding provisions of GPLv3. They represent the result of a difficult compromise, and are motivated by policy goals for which I have deep personal sympathy. I contend that they are among the best-drafted parts of that license. The policy concern about locked-down consumer devices with effectively nonmodifiable GPL-licensed software has become more relevant in the years since those provisions were drafted. Yet, with respect to GPLv3, it has been my own intuition that few projects consciously choosing that license do so because of the anti-Tivoization provisions. I do not have the sense that the inclusion of these provisions in GPLv3 has had the effect of increasing users' freedom to modify software in consumer devices they own. To the contrary, it appears if anything to have motivated risk-averse companies to avoid use of GPLv3-licensed software. That is not dispositive but it is relevant. (There may be evidence to the contrary that I am unaware of.) I'm open to being convinced that this deletion should be reverted, but if no one successfully convinces me, it is likely to stay deleted. Part of what influences me is the availability of outbound (A)GPLv3 compatibility. As with the more obscure 'contractor' provision of GPLv3 section 2, those who care strongly about these provisions will be able to incorporate copyleft-next code in GPLv3-licensed works. Deletion of first part of anti-anti-circumvention provision =========================================================== While I currently continue to feel it is worthwhile for copyleft-next to explicitly address anti-circumvention law, I no longer consider the first paragraph of what was GPLv3 section 3 to be desirable. The basic idea here was the hope that courts would be influenced by a general declaration by the licensor that covered works are, in some sense fundamental to the license, not 'effective technological protection measures'. There is no known history of use of this provision by those defending against invocation of anti-circumvention law. This strikes me as being an inherently weak provision, but, the less weak one assumes it is, the more problematic it becomes from a free software perspective, since it approaches something like a field of use restriction. That certainly is not what the FSF intended, but that lack of intent does not make the discomfort go away. The reason for effectively two (or three, depending on how you look at it) anti-anti-circumvention provisions had to do with concerns about differences between US and EU approaches to anti-circumvention law. I consider it better to come up with one provision suitable for major jurisdictions in which the license is likely to be granted. A modification of the second part of what was GPLv3 section 3 is a better basis for such a provision. Further changes to termination ============================== In response to discussion on the mailing list, I have changed the EPL-inspired "reasonable time period" cure to a 30-day cure. I have also eliminated the relatively complex "automatic termination -> provisional automatic reinstatement -> permanent automatic reinstatement' feature which was originally added to GPLv3 section 8 in the final draft. I have explained this in a posting to this list made earlier today. Deletion of liberty-or-death example ==================================== This is a noteworthy change. If people think that we need the example given in GPLv3 section 12, let me know. - Richard

7 32

Compatibility with Eclipse Public License.
by Tom Marble 20 Nov '12

20 Nov '12

All: As Richard brought to my attention on identi.ca [0] there appears to be interest in making CLN (copyleft.next) compatible with EPL [1]. This is certainly an interesting goal and I'm wondering how the to comply with EPL in a CLN combined work? Historically this seems to have been "impossible" with GPL. AFAICT the incompatibility rises from the EPL choice of venue [2] which makes EPL not GPL compatible. Interestingly there seem to be claims that GPL is not EPL compatible [3][4][5] yet they all seem to hinge reflexively on the former case. Thus if EPL is CLN compatible then is there any stronger assertion we can make to assure that CLN is EPL compatible (specifically that a combined work under CLN is possible)? If such a solution is found it would give CLN another powerful advantage (along with deflating Proprietary Relicensing [6]) to combat the EPL reflexive assertions and (optionally via ws-supp) go further by copylefting network services (so-called "Web Services"). This would seem to be significant as it is not clear a developer today could deploy an EPL work (e.g. Clojure) combined with copyleft network services (e.g. under AGPLv3+) while complying with both licenses. At the risk of adding a second issue to this mail I am concerned that the "at no charge" qualification in ws-supp creates a loophole for additional albeit gratis conditions. Especially in the land of network services we are becoming increasingly aware of draconian and even abusive "Terms of Service" in exchange for gratis offerings. CLN seems to want to make conveying Software Freedom unconditional. Respectfully, --Tom [0] https://identi.ca/notice/95887462 [1] https://gitorious.org/copyleft-next/copyleft-next/blobs/master/license-draf… [2] https://www.gnu.org/licenses/license-list.html#EPL [3] http://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE [4] https://mmilinkov.wordpress.com/2010/04/06/epl-gpl-commentary/ [5] https://en.wikipedia.org/wiki/Eclipse_Public_License#Compatibility [6] https://gitorious.org/copyleft-next/copyleft-next/blobs/master/license-draf…

6 23

Update
by Richard Fontana 14 Oct '12

14 Oct '12

Here's an update on some of what's been going on in the copyleft-next draft since a week ago. One of the more significant changes is a substantial simplification of the termination section. For what are best summarized as "historical reasons", GPLv3 has effectively two cure provisions (interestingly, MPL 2.0's drafters chose to adapt much of the GPLv3 language). I've replaced it with one cure period and I just refer to a "reasonable time period" (cf. EPL 1.0) instead of the 30-day and 60-day periods of GPLv3. I'm not convinced that it's better not to have a fixed time period for cure, though I am convinced that a 30-day and a 60-day provision are not both needed. The structure of having automatic termination coupled with automatic reinstatement upon cure is preserved. This is unusual but it reflected concerns expressed by those active in GPL enforcement in Germany that automatic termination facilitated enforcement under German law. I have added a 'severability clause' which is a common feature of contracts and is found in a number of FLOSS licenses. The FSF opted not to have a severability clause in GPLv3 out of concern that it could lead to unpredictable judge-made alterations of the GPL that might frustrate basic policy objectives. The advantages of a severability clause seem to me to outweigh this concern. (GPLv2 has a limited severability clause in its 'liberty-or-death' section, which was removed from GPLv3.) I added a section at the beginning giving a 'general rule of construction', in some ways replacing one function the GPL Preamble ought to serve. The language here was adapted from the Preamble of Allison Randal's experimental short GPLv3 alternative which she drafted in 2007. I deleted the lengthy yet narrow provision I call, for lack of a better name, "child of downstream shielding" (GPLv3 section 11 paragraph 5). This is actually a very important provision for historical reasons, as a guide to understanding the FSF's interpretation of the GPL, but I believe it has proven to have little value in the license itself. With this deletion, note that all the patent-related provisions of GPLv3 are now gone except for the Licensor's patent license grant (which has been restructured but, at least as I conceive it currently, is not different in scope from the patent license grant of GPLv3). Sadly, vanilla copyleft-next is still over 100 lines longer than the Apache License 2.0, but great progress has been made. :-) - Richard

5 14

Update 2012-08-08
by Richard Fontana 14 Oct '12

14 Oct '12

Here's an update of what's been going on with the copyleft-next draft during the past week: While Bradley Kuhn's attempted resurrection of the anti-lockdown provisions has failed, I incorporated some of his suggestions for improvements in the definition of Corresponding Source (including a recent change that addresses the 'know-how' issue). I have put a "FIXME" for the System Libraries definition, as, to be frank, all definitions of this exception in all versions of the GNU GPL are suboptimal and if we wish to preserve this concept at all we need to start over. (Query whether it's actually needed anyway.) I deleted the 'rule of construction' in response to some criticism from Luis Villa, but I might restore it in response to some of his further comments on said deletion. I deleted the "inbound=outbound" provision adapted from the Apache License 2.0. I think this is difficult to draft *well* and may not be worth the effort. In many cases, contributions to a hypothetical copyleft-next project will be themselves 'Derived Works', and I have argued publicly in various talks and writings that FLOSS legal culture features the inbound=outbound custom anyway. The patent license grant is arguably broadened from GPLv3 by referring to 'Covered Works', although perhaps this is best seen as a clarification. In this I was influenced by the patent license grant in the Microsoft Public License. I considered and discussed on the mailing list a provision that would attempt to achieve compatibility with EPL. I ended up not including this, though I am still open to the idea. The anti-anti-circumvention waiver/disclaimer is clarified as something that the initial licensor and all 'Distributors' make. At least with the deletion of the first part of what was GPLv3 section 3, it was not clear that the initial licensor was making the same waiver/disclaimer as downstream parties. I applied Luis Villa's proposal to delete the written offer option from the object code distribution section. No one came to its defense on the mailing list. It is gone! In the past few days I've been experimenting, probably too much, with rearranging sections and subsections and typographical presentation and such. I deleted the anti-patent-litigation condition descended from the end of GPLv3 section 10 and replaced it with a provision closely modeled on the patent peace provision in MPL 2.0 (and put it in the termination section). I did so despite having some concerns about the breadth of the MPL provision. The old liberty-or-death provision is now reduced to one sentence in the no-further-restrictions section. I removed the ancient clarification that you can charge for distribution or services, as hopefully obvious by now. Apart from the draft, I made some modifications to the Harvey Birdman Rule (as it is again known). copyleft-next (ignoring ws-supp) continues to shrink: it is now at 270 lines and 1620 words. Of course, that's with the placeholder System Libraries definition.For comparison, the Apache License 2.0 is 202 lines and 1581 words. The Object Code Distribution section makes up about one quarter of copyleft-next - Richard

2 3

best way to describe the contents of "Corresponding Source"
by Luis Villa 12 Oct '12

12 Oct '12

On Sun, Aug 5, 2012 at 7:30 AM, Bradley M. Kuhn <bkuhn(a)ebb.org> wrote: > Luis Villa wrote at 22:57 (EDT) on Friday: >> That should be "any scripts..." not just "scripts", no? > > What is the point of adding 'any'? In this context, "any" would typically be read to mean '"every", with the additional implication that "every" was not used because there might not be such scripts. So long as no other part of the language does not explicitly require such a script to exist (which is currently the case), it is essentially the same as your proposed "all," because both "any" and "all" permit the case where no such scripts exist. I suggested this because Richard's original language, without either "any" or "all", was ambiguous as to whether or not the scripts were required, and my sense is that "any" (i.e., permitting there to be no scripts existing) was what was intended. If instead the license is intended to require that such scripts exist (which is perfectly reasonable) neither "any" nor "all" does that with 100% clarity. It would be much better to say something like "and must include the scripts and instructions necessary..." Or perhaps, better integrated into the rest of the definition "Corresponding Source" of a work means all the Source Code needed to build, compile, generate, modify, install, and run the work (to the extent those activities are meaningful for the work), * including scripts, instructions and configuration files that can be used [are used?] to perform those activities.* Obviously "are used" is extremely strong, as it prohibits having parallel build systems (one that can be used internally and one used by GPL licensees). I dislike "know-how" because it is insanely vague. Much better to list the things (like configuration files) that might contain such know-how. >> I've never been sure what "control" means in this context. Given that >> "perform" is probably broad enough to completely encompass "control," >> and given how comprehensive the list of tasks is now (it's arguably >> impossible to "perform" a build without some form of control) I'd be >> inclined to replace "control and perform" with simply "perform," or >> else give a more specific definition of "control" (e.g, by reference >> to configuration files.) > > I actually think "scripts used to control compilation and installation > of the executable" is effectively the same as what I wrote in my > original patch, but I've seen weasely lawyers argue otherwise to defend > their GPL-violating clients, so I > think we need as much text in there as possible. We should keep adding > verbs until we can't think of any more. I'm not necessarily against adding more verbs (especially in the first group (build, compile, etc.)) but I think the license is stronger when the drafters can clearly explain and describe what each verb they put in means :) Control has always been problematic this way because in common parlance scripts don't "control" - they perform or act, and configuration files or command-line options control. So I like the simple "perform" because it makes clear that the goal is to do that first set of actions, instead of burying it in other verbs. [Building on that last sentence, here's a radical rewriting of the sentence at issue, though I'm not 100% sure it works: "Corresponding Source" of a work means the Source Code of all materials needed to enable You to generate, install, and run the Received Work, including [but not limited to] scripts, instructions, and configuration files." I like this because it puts the emphasis on enabling the recipient's rights; if the recipient can't generate/install/run the work, then by definition they are not enabled and the requirement is not satisfied. I like "generate" because again it focuses on the outcome (that the work is generated from the Corresponding Source) rather than specific technical means of achieving that end (building, compiling). I put [but not limited to] in brackets because, while commonly used, it probably shouldn't be: http://www.adamsdrafting.com/2007/04/02/including-without-limitation/ I don't like that this makes it theoretically impossible for a Distributor to know, a priori, if they are in compliance, since they don't know who "You" will be, or what capabilities You will have, but obviously that can be read as a feature and not a bug. :) ] Luis

3 4

Some initial comments on the copyleft-next draft
by Richard Fontana 11 Oct '12

11 Oct '12

Hi, During the past two weeks I've been working on modifying a document that started out as the text of the GNU GPLv3 but which is now quite different. I've had gracious help from several other people, but so far it's fair to say that most of the *policy* decisions underlying the various changes have come from me (IOW you can blame me for almost anything in the draft thus far if you disagree with it). I thought I'd provide a summary description of the more interesting aspects of what's been done. I deleted the following elements: * The Preamble and the 'How to Apply' appendix * The patent-related provisions that were introduced to GNU GPLv3 in the wake of the Microsoft/Novell deal of late 2006 * The old requirement to preserve legal notices in user interfaces * The acceptance provision (proposed by James Vasile) I removed the so-called 'anti-Tivoization' provisions of GNU GPLv3 section 6 out of vanilla copyleft-next and into a separate document currently called "dl-supp". I also added a separate document called "ws-supp" containing substantially similar text to the first half of the GNU AGPLv3 section 13. I don't think I really explained this in the commit logs so I'll go into that a bit here. The idea is that the vanilla version of copyleft-next won't have an 'Affero clause' (much as GNU GPLv3 doesn't) and, unlike GNU GPLv3, it won't have 'anti-Tivoization' provisions. Only the *initial* licensor (someone who's starting a new work from scratch) can choose to supplement copyleft-next with one of those "supp" documents. Currently, vanilla copyleft-next is incompatible with {copyleft-next + dl-supp} and {copyleft-next + ws-supp} (much like "GNU GPLv2-only" is incompatible with GNU GPL3) (i.e. there's nothing corresponding to GPLv3/AGPLv3 cross-compatibility), though this is just because I deferred thinking about whether there should be compatibility or not. I added a provision similar to Apache License 2.0 section 5 which is something like a built-in "inbound=outbound" contributor agreement for projects. (While I like this Apache feature very much it is a bit awkward in copyleft-next in its current form.) I added a provision to the basic copyleft clause that is designed to remove the copyleft requirement if the licensor separately offers a proprietary commercial version of essentially the same software. Maybe this isn't worthwhile, but it was something I'd wanted to experiment with trying to implement for a long time. I added a provision making copyleft-next relicensable under GNU GPLvn/AGPLv (the importance of this was impressed on me by Mike Linksvayer and it also addresses the FSF's reasonable concerns about GNU GPL derivatives). I added a "no trademark rights granted" clause (similar to what's in MPL and the Apache License 2.0). The old additional terms section has been drastically simplified and combined into the 'no-further-restrictions' section. I won't go into detail about the remainder of the changes in this message but I'd describe them generally as aimed at substantial simplification and normalization of language and structure. To take one example, the patent license grant of GNU GPLv3 is essentially the same but it is presented very differently: it now accompanies the basic copyright license grant in the 'basic permissions' section early in the license (this is more like how other free software/open source licenses with patent license grants are structured, and I think it may be easier to understand). I consider nothing of what I've done to be necessary or above criticism, but I think it gives you a sense of the direction I'm generally going in. This might be the most lightly trafficked mailing list in the entire legal history of free and open source software, but I'd be happy if it could serve as a forum for discussing, suggesting or criticizing ideas, and also as one way of submitting patches against the license draft. For those who don't know, currently I've been hosting the repository at https://gitorious.org/copyleft-next and mirroring at github https://github.com/richardfontana/copyleft-next There's an IRC channel #copyleft-next on Freenode though so far the only discussion there has been bcotton and I talking about today's weather in Massachusetts. :-) - Richard

7 48

Update 2012-08-25
by Richard Fontana 26 Aug '12

26 Aug '12

Here's an update on copyleft-next, a bit later than usual. I haven't had much time to work on the draft over the past week, so there isn't much to report. I made changes to two provisions, mainly in response to some discussion on this list. First, I abandoned my 'use FSF+OSI as a check' idea in the 'Later License Versions' section and instead drafted something similar to the corresponding provision of GPLv2. Second, I modified the 'proprietary relicensing poison pill' section by deleting the 'for commercial gain' trigger and added the OSI's OSD as an alternative basis for a 'relicensing' license to avoid activation of this provision. I've been thinking a lot lately about whether there could be improved ways of presenting the license to aid comprehensibility (stylistically/typographically, for example, or more significant structural changes that some lawyers might not feel so comfortable with). - Richard

5 9

YELLING email from github?
by Luis Villa 17 Aug '12

17 Aug '12

I no longer appear to have any copies of the long comment (including citations/links) that I made on "[GPL.next] Is YELLING (sections 15 and 16) necessary? (#9)" If someone here has a copy in their email archives, I would be much obliged if you could forward it to me. Thanks- Luis

2 2

Update 2012-08-15
by Richard Fontana 16 Aug '12

16 Aug '12

Hi, Here's yet another weekly update on what's been going on with the copyleft-next draft. One of the more interesting changes I made this week was in the 'Later License Versions' section (as it is now known). It was previously written as a built-in "or-later" provision of the sort we see in a number of FLOSS licenses such as MPL and EPL. I (for lack of any better alternative) used 'the Copyleft-Next Group' (now the 'Copyleft-Next Project') as the name of the license steward authorized to publish newer versions of the license. I have now revised this to state that any newer version released by said Copyleft-Next Project will not be 'Authorized' unless it is approved as such (as a sucessor to the earlier copyleft-next) by both the FSF and the OSI. My idea here was that there is an inherent problem of trust raised by these 'or later' clauses (especially where built into the license, but also where, as with the GNU GPL, 'or later' licensing is encouraged and all license versions indicate that absence of an indicated version constitutes permission to use any version). Since the FSF and OSI are establishm^Hed organizations that are perceived as not necessarily agreeing on things all the time, perhaps giving these venerable organizations a sort of veto power on the Copyleft-Next Project's designation of future versions is a decent idea. Or maybe not. Note that under this kind of provision, the Copyleft-Next Project could still issue a 2.0 license but it just wouldn't be one that 1.0 licensees could 'relicense' to via the built-in or-later clause. Cf. the mostly-ignored 'proxy' provision in the corresponding sections of (A)GPLv3. I have mostly deleted an earlier idea of listing representative permissive licenses as inbound-compatible to guide interpretation of what "Further Restrictions" means. Instead, I assume that figuring out inbound license compatibility will be no more difficult than it was under GPLv2. The one exception is that I explicitly provide for Apache License 2.0 compatibility, because this is both useful and necessary. As noted on the mailing list, I have deleted the anti-anti-circumvention provision. The offer remains open to restore it if anyone can explain to me a real-world scenario where it accomplishes something worth ~9 lines of license text. I reduced the 'Minimum Period' for Corresponding Source availability, where CS is made available on the net, from 3 years to 2 years, on the assumption that this was not problematic. I broadened and put into a separate section what has been called the proprietary-relicensing 'poison pill' (I briefly used that as the section title). Now, if the original licensor proprietary-relicenses, most of the conditions of the license vanish for the licensee, so copyleft-next turns into an ultra-permissive license. On the other hand, the provision is narrowed to apply only where the proprietary-relicensing is done for "commercial gain". For those who care about word counts, vanilla copyleft-next continues to shrink (though I think we are about at the limit now and if anything the license is likely to get longer). (And we still have a FIXME for the System Libraries definition. :) GPLv3: 5644 GPLv2: 2968 MPL 2.0: 2435 Apache License 2.0: 1581 copyleft-next: 1431 - Richard

3 4

compatibility language [was Re: Update 2012-08-15]
by Luis Villa 16 Aug '12

16 Aug '12

On Wed, Aug 15, 2012 at 8:38 PM, Richard Fontana <fontana(a)sharpeleven.org> wrote: > On 08/15/2012 09:31 PM, Luis Villa wrote: >>> I have mostly deleted an earlier idea of listing representative >>> permissive licenses as inbound-compatible to guide interpretation of >>> what "Further Restrictions" means. Instead, I assume that figuring out >>> inbound license compatibility will be no more difficult than it was >>> under GPLv2. The one exception is that I explicitly provide for >>> Apache License 2.0 compatibility, because this is both useful and >>> necessary. >> >> I am tempted to say that, once this language is refined, it should be >> split off and turned into a general-purpose additional permission >> exception for GPL *2*. > > I want Apache License 2.0 code to be compatible with copyleft-next > works without need to invoke the separate permission to 'relicense' > under a version of the (A)GPL. (I'm not sure if that's what you were > getting at.) Ah, I had not looked at the latest draft before opening my mouth. I am less optimistic than you about whether or not building an interpretive tradition works, but perhaps (assuming it ever got that far) copyleft.next could be published with explicit analysis and interpretation of various clauses that have previously been treated as Further Restrictions, and use that to establish the ground rules. > The idea here is that a common sense-based license > compatibility tradition can grow up organically around copyleft-next > much as it did under GPLv2; but the one interesting non-legacy license > which causes problems is the Apache License 2.0, chiefly because of > its section 9. The natural result (without this clause in > copyleft-next) ought to be that section 9 is a 'Further Restriction'. > What I don't want is some general categorical clause of the sort GPLv3 > section 7 has authorizing Apache-style upstream indemnification > clauses. FWIW, to be historically accurate, this would be "NPL 1.0-style indemnification clauses." It's still in MPL 2.0, if I correctly understand the part you find objectionable. Luis

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next August 2012