copyleft-next July 2012

copyleft-next@lists.fedorahosted.org

10 participants
8 discussions

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

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

in defense of the TGPPL idea
by Zooko Wilcox-O'Hearn 13 Aug '12

13 Aug '12

Folks: Mike Linksvayer asked me if I was aware of Ted Ts'o's Temporary Proprietary License. I was not consciously aware of it when I developed the Transitive Grace Period Public Licence. I exchanged email with Ted about it later. One particular detail of my TGPPL that I value and that I'm not sure the TPL provides is that if you take advantage of the permission to keep a derived work temporarily proprietary, then this obligates you to offer the same permission to people who make worked derived from your derived work. Make sense? So when I publish source code under the TGPPL, I'm not offering people the option of making a derived work, keeping it proprietary for a limited time, and then releasing it under a strict copyleft which disallows others from making time-limited proprietary derived works of it. On the other hand, I *am* offering people the option of making a derived work, making it Free/Open immediately, and disallowing others from making a proprietary derived work from it, even for a limited time. The latter option is currently the case for Tahoe-LAFS and the other software that I release in this way because I offer the recipient the choice of GPL or TGPPL. So if you want to make a derived work of Tahoe-LAFS without allowing anyone "downstream" of you to make a proprietary derivation of your work, even for a limited time, then you can do so by releasing your derived work solely under GPL. I'm interested in developing a "TGPPLv2" which is expressed as an "Additional Permission" to GPL. That would have exactly the same consequences as the current TGPPLv1, sketched above, but it would probably be better in a lot of ways to have it expressed as an "Additional Permission" to GPLv3+. Mike posted some criticism of the very idea of TGPPL which I'd like to (briefly‽) address. Mike wrote: > It may be possible to demonstrate theoretically that an in-between tweak is necessarily superior to both, but not with any precision, and I'm dubious even of this. I agree that reliable evidence about this is difficult to come by. Nonetheless, I believe I should act based on my current understanding rather than hesitate while looking for better data. I personally have pretty high confidence that copyright maximalism, including "Limited Time → ∞", will yield a worse social outcome than some alternatives. More controversially in some circles (presumably including this one), but less controversially among mainstream economists, I have pretty high confidence that pure copyleft, in which "Limited Time = 0", will yield a worse social outcome than some alternatives. My reason for believing that latter assertion is that I think the production and usage of Free/Open software on earth has grown only modestly over the last couple of decades, while production and usage of all software has exploded immeasurably. Software has changed everything for billions of humans, it appears likely to do so even more rapidly in the coming decades, and Free/Open software is less and less important to that. Free/Open software is a tiny and rapidly shrinking sliver of all software, as measured by human values -- how much time people spend with it, how much of their money, their memories, their rights and freedoms they entrust to it, etc. A typical situation is that the lower-layer and more commoditized parts of the software stack are more likely to be Free/Open, e.g. operating systems and web browsers, and the higher-layer and newer parts are more likely to be proprietary and to otherwise deny freedom to their users, e.g. Facebook and more or less the entirety of the Web. It is those newer and higher-layer services that are most valuable to users and most dangerous to their freedoms. For the vast majority users it would make little difference to them if you switched their Windows for Linux or their MSIE for Firefox, but it would be unthinkable for them to leave Facebook, or migrate off of Oracle, or stop subscribing to the software vendors and web sites that they rely on, etc. So, I personally believe Free/Open software is a social good that is massively, drastically under-produced, just as simple economic theory would predict. I think -- or rather I hope -- that a better social outcome is possible somewhere in the middle, between the two extremes of 0 and ∞. TGPPL is my stab at it. We can't do much worse than we are already doing. ☹ I recognize that this may be surprising or unpleasant to this audience. I mean no offense. You are the big fish in a pond. I'm asserting that beyond this pond, the world of bigger ponds is growing at an incredible rate. I very much value and respect your contributions, including those of Red Hat, which can be measured in real money. > The nearest practice I know of was Aladdin's, I don't think it is a valid comparison. Aladdin never offered to anyone the option that they could make a proprietary derived work for a limited time. So it provides no evidence on whether anyone would have been interested in that option. Now Tahoe-LAFS *has* offered people that option, and so far, to my knowledge, nobody has taken us up on it. This probably just shows how there is little commercial interest in Tahoe-LAFS, but it could also be taken as evidence that the TGPPL is not itself a big draw for investment. By the way, commercial interest in Tahoe-LAFS is growing -- there are now three companies offering commercial services based on it including my own startup, and I'm aware of a few other expressions of commercial interest. Thank you for your attention. Please accept my bold, normative statements in the spirit of constructive criticism that I intend. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep -- Least Authority Enterprises https://leastauthority.com

4 6

[PATCH] Handling extraordinary private communications via publication.
by Bradley M. Kuhn 31 Jul '12

31 Jul '12

It seems to me that private communication is inevitable in a project. Here's a patch that I propose to add a rule to CONTRIBUTING to handle the issue. Not sure what the preferred protocol for patch submission/pull requests is in this project yet, so I just did everything that was possible. A Gitorious Merge request: https://gitorious.org/copyleft-next/copyleft-next/merge_requests/8 You can pull the change via: git pull git@gitorious.org:~bkuhn/copyleft-next/bkuhn-copyleft-next-proposals.git bkuhn/public-forum-pub-of-private-conversations And, for good measure, the patch is attached: Fontana, for future reference, which of this do you actually prefer? -- -- bkuhn

2 3

Re: [copyleft-next] "reasonable time period" Termination enforceability (was Re: Update)
by Joshua Gay 30 Jul '12

30 Jul '12

I too have witnessed potential violators claiming that 180+ days is reasonable amount of time to come into compliance. "Bradley M. Kuhn" <bkuhn(a)ebb.org> wrote: >Richard Fontana wrote: >> One of the more significant changes is a substantial simplification of >> the termination section. .... I've replaced it with one cure period and >> I just refer to a "reasonable time period" .. 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. > >And thus master branch of copyleft-next now reads: >>> However, if You cure such failure within a reasonable time period after >>> becoming aware of such noncompliance, then Your rights are reinstated. > >I strongly believe this will make copyleft-next de-facto unenforceable. >We'd have to litigate it all the way to the bitter end to get a ruling >that "reasonable time period" is less than the average life cycle of most >electronics and software products. > >In my experience, nearly all copyleft violators believe it's reasonable to come >into compliance only after a product is off the market. And most would >happily say "see you in Court" if a copyright holder says otherwise. > >Even those violators who make vague, half-hearted attempts to come into >compliance still believe heavily protracted schedules are reasonable. For >example, I've got compliance actions open today that were first opened last >fall, and I'm sure the lawyers would argue, that they're still "within a >reasonable time period" and tell me to sue them if I disagreed (of course, >I already do disagree). As everyone knows, because I know the community >prefers that we avoid lawsuits, I desperately avoid them until there is >just no other choice, but violators' lawyers now know this too, of course, >and play chicken. > >Since most of my compliance work is GPLv2, it means such violators are >(of course) dead to rights. Think about it: even with GPLv2's termination >clause, which everyone agrees very strict (from a policy perspective), most >violators take nearly the entire product lifecycle to come into compliance, >even when they know they've gotta beg for their rights back at the end of it >or face continued copyright infrigement even when *in* compliance on all >other non-termination points. If the termination clause says "reasonable >time", what incentive will be left to get them into compliance, ever? > >My point, simply: I think copyleft-next will have to chose between naming >a specific number of days, or be effectively unenforcable. Also, realize that >*whatever* time frame you pick will be the minimum time by which we get code >from companies gaming the system with delayed releases (which is already common, >even with GPLv2). > > -- bkuhn >_______________________________________________ >copyleft-next mailing list >copyleft-next(a)lists.fedorahosted.org >https://lists.fedorahosted.org/mailman/listinfo/copyleft-next

1 0

test, please ignore
by Richard Fontana 23 Jul '12

23 Jul '12

This is a test.

1 0

Temporary Propietary License
by Theodore Ts'o 22 Jul '12

22 Jul '12

This is something I wrote up almost ten years ago, and since the copyleft-next is an opportunity to consider some different variations on copyleft, I thought I would throw this out there. The full proposal, complete with rationale, can be found here: http://web.mit.edu/tytso/www/TPL.html But the tl;dr summary of the proposal is this: The Temporary Proprietary License (TPL) allows derivative works to be released without source code (i.e., in a proprietary fashion), but only for a limited amount of time. After N months (where N would likely be somewhere between 12 and 18 months) of the software being released, the company/person doing the proprietary distribution must make the sources available under terms which specify that the contributed code must be made available under the terms which are no more restrictive than that of the original code base, and must send a copy of the modified sources to the original maintainer. The original maintainer must be notified before derivitive works can be distributed under the terms of the TPL. In my original conception, source code would be released under a dual-license of the TPL plus the GPL, which is how someone would be allowed to make propietary changes, but be required to release them some time later. It might be useful to consider use the supplemental framework in copyleft-next for this option. I'm curious what people think of this idea; is it workable? Are there some fundamental flaws with this approach? Thanks, - Ted

5 6

test
by Richard Fontana 16 Jul '12

16 Jul '12

This is a test.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next July 2012