copyleft-next February 2013

copyleft-next@lists.fedorahosted.org

24 participants
22 discussions

copyleft-next patent commons?
by Gervase Markham 10 Apr '13

10 Apr '13

Again, forgive me if this has been discussed before... Has the group considered the pros and cons of changing section 10), para b), to cover all copyleft-nexted works? So: 10. Termination Your license grants under section 1 are automatically terminated if You ... b) initiate a patent infringement litigation claim (excluding declaratory judgment actions, counterclaims, and cross-claims) alleging that any work under this License directly or indirectly infringes any patent. In other words, if you sue someone over a patent in a copyleft-nexted work, you lose rights to use all copyleft-nexted works. As copyleft-nexted works become more common and more useful (say e.g. a copyleft-nexted work was incorporated into Android) it would become more and more of a bad idea to sue anyone for patent infringement relating to such work. After all, in that case, the first thing you'd have to do is replace all the company Android phones with iPhones... The potential disadvantage of this, presumably, is the risk that organizations will be less interested in writing or using copyleft-nexted works. Gerv

8 30

Section 4 and 7 - permissive license contenand development process
by Luis R. Rodriguez 09 Mar '13

09 Mar '13

Kudos on the copyleft-next-0.2.0 release! A few questions regarding section 4 and 7. For clarity I'll paste both sections and then post my questions after. 4. Conditions for Distributing Derived Works; Outbound GPL Compatibility If You distribute a Derived Work, You must license the entire Derived Work as a whole under this License, with prominent notice of such licensing. This condition may not be avoided through such means as separate distribution of portions of the Derived Work. You may additionally license the Derived Work under any version of the GNU General Public License published by the Free Software Foundation ("GPL"), so that the recipient may further distribute the Derived Work 7. Symmetrical Licensing Condition for Upstream Contributions If You distribute a work to Me specifically for inclusion in or modification of a Covered Work (Your "Patch"), then, unless Your Patch explicitly states otherwise, You license it to Me under this License, to the extent of Your copyright in Your Patch. This condition does not negate the other conditions of this License, if applicable to Your Patch. As it is today the GPL allows for permissive license contributions and for example you are entitled to extract these permissive license contributions (them having a license statement on the top of the header file) and use these permissive license components in permissive licensed / proprietary new or existing projects. We discovered this for a big project with the help of SFLC during the ath5k wars, for example, and we used this to help share code between BSD and Linux [0] and today I try to exploit this on my question on killing proprietary drivers. I'll note that there are some interpretations on intent on this on certain projects, like for example in a big GPL project the intent behind developers is that although we allow for this we do not intend to enable extracting permissive licensed components from the GPL larger project for you to go and make non-GPL compatible modifications of that extracted content to the same GPL larger project given that the license at run time of the individual components are all GPL [1]. My questions then: 1) Does copyleft-next allow for the same type of extraction of permissive licensed components if they are declared as such for sharing in a permissive license / proprietary project? 2) I argue that perhaps the last part that I describe in the above paragraph be actually clarified as intent and by design of the license, if not already. 3) The last question has to do with development process and licensing. Section 7 has language that asserts that if patches are submitted that it will be assumed the contribution is being made under the same license unless otherwise stated. This is good, however I invite you to please review and consider the effort behind the signed-off-by fork [2] by W. Trevor King that was spawned after discussions of the potential of forking the Signed-off-by Developer Certificate of Origin on the Linux kernel [3]. What I wonder is if a merge of such / similar language onto copyleft-next may help with development process therefore making an understanding and respect of development process through licensing, thereby making the requirement of a Signed-off-by tag perhaps not required. Thoughts? [0] https://lkml.org/lkml/2012/4/6/371 [1] https://lkml.org/lkml/2012/4/7/119 [2] https://github.com/wking/signed-off-by [3] https://lkml.org/lkml/2012/11/20/636 Luis

5 11

Inbound-outbound clause and licensor promise
by Engel Nyst 09 Mar '13

09 Mar '13

Hello copyleft-next, I'd submit for discussion the (re)introduction of an inbound-outbound clause for contributions, and the possibility to use it as the place where the upstream licensor makes an explicit promise: to keep the software under copyleft. A clause in the style of Apache License 2.0 section 5[1] has been in the text of copyleft-next at some point[2], however it has been removed later. I'd suggest to re-add it (and thereby make CLAs more clearly unnecessary), and also, to consider addition of a second part. Part #1: "Unless You explicitly state otherwise when making it, any Contribution intentionally submitted for inclusion in a Covered Work by You to Us shall be under the terms and conditions of this License, without any additional terms or conditions." Part #2: "By accepting the Contribution, We promise to only distribute it under copyleft-next, or future versions." Or, "By accepting your Contribution, We acknowledge your intention to be distributed by Us under copyleft-next only, unless You make a public express statement of your agreement to different terms." Or, "By accepting your Contribution, We acknowledge your intention that We distribute it solely under copyleft-next or future versions, and We promise to offer any work we prepare based on it under these terms (or of a future version)." I assume these attempts are quite unworkable (please shut them down), but consider the point itself. As far as I can tell, this will not, and can not, make the licensor legally bound, because Licensor (in AL 2.0 sense) can always receive a different license, like the CLA grant. The CLA, IMO, will apply unrestricted anyway. IANAL though. OTOH, this opinion is not widely shared[3]: it seems the respective AL 2.0 paragraph can be read as precisely making room for Apache itself to not follow the conditions of the AL 2.0 grant, but instead license on the basis of the CLA grant. Please see the thread: the potential that AL 2.0 submissions clause *could limit* the CLA holding entity in some way is quite interesting. But is legally binding of the promise the only issue worth pursuing? The expression of intention of contributors, or the creation of an expectation from the community in regard to the behavior of a CLA-holding entity, could have more positive effects. Added up to part #1. Some of the issues with CLAs are that they might be signed with many unwritten expectations, and they may grant much more rights, than they were originally intended for. A clause like this is a place to have those expectations written. Other issues with CLAs are simply that they're separate documents, which give licensing rights, are deemed necessary for some reason, and are written as an agreement (not as a license) typically in legalese. Personally, I see a concerning potential for proprietary relicensing to affect community contributions which were not intended to be proprietary by contributors. (as far as I understand, Richard Fontana disagrees with this. I admit I am not objective on the matter.) In any case, I wonder if this proposal can reduce the potential, creating a better environment *before* proprietary relicensing has occasion, agreements, interests, to happen. [1] http://apache.org/licenses/LICENSE-2.0 [2] http://ur1.ca/crp2u [3] http://thread.gmane.org/gmane.comp.apache.legal.discuss/2708

2 5

Inquiry About Having A UDS March 2013 Session on Copyleft-Next
by Stephen Michael Kellat 26 Feb '13

26 Feb '13

Dear Mr. Castro: Greetings from Ashtabula. After asking Richard Fontana, our project leader, on Identica I write to inquire about having a session during UDS March 2013 where the copyleft-next team can talk about the license we have been developing and how it may be used by projects within the Ubuntu ecosystem. I caught Mr. Bacon's note earlier today that we're experimenting with having virtual summits in lieu of in-person ones and I would like to spread the word about this license development effort with our community during UDS March. The license project has a website here: http://copyleft-next.org/ The current working release of the license is available here: https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases… In attempting to comply with the spirit of the project's Harvey Birdman Rule, I am copying the project's e-mail list so that this inquiry is disclosed to other project participants. I urge you to join us on the list via the mailman form here so as to further discuss the matter: https://lists.fedorahosted.org/mailman/listinfo/copyleft-next Thank you for your time and consideration. Respectfully Submitted, Stephen Michael Kellat An Ubuntu Member

1 0

copyleft-next 0.2.0 released
by Richard Fontana 25 Feb '13

25 Feb '13

Good news, everyone! copyleft-next 0.2.0 has been released! https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases… A summary of the principal changes relative to 0.1.1 will follow in due course. - RF

6 27

Limited-term copyleft
by Richard Fontana 23 Feb '13

23 Feb '13

Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea? We're now a few years from the point where there could be 30-year-old code under GPL-like licenses. I have found from $DAYJOB experience that one occasionally has to deal with legal issues concerning *really* old code (in a situation I dealt with today, from 1979; admittedly that's unusual). The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term. This is of course conceptually similar to the Creative Commons 'Founder's Copyright' idea and is related to general criticisms of present-day copyright term duration. If anyone thinks it's a good idea, what would be a good copyleft duration? 15, 20, 25 years? Please do not hesitate to shoot this down. - RF

13 30

HBR cure 2013-02-18
by Richard Fontana 23 Feb '13

23 Feb '13

This is a HBR cure. First, for those of you not following the official draft closely, as of a recent commit, I have audaciously and iconoclastically added this sentence to the (now single) section on object code disribution: Each recipient of the Covered Work from You is an intended third-party beneficiary of this License solely as to this section [] with the right to enforce its terms. If any of the lawyers on this list have any comments of a strictly insider-professional-knowledge *legal* nature on this sentence, including arguments for its deletion or modification, feel free to speak up (in a HBR-compliant manner of course). If anyone (non-lawyer or otherwise) thinks it would be bad *policy* to live in a world where a GPL-like license could be enforced through the legal system by the obvious immediate beneficiaries of the source code requirement, feel free to speak up (in a HBR-compliant manner of course). That said, on to the HBR cure: I had a conversation with Bradley Kuhn in which we very briefly discussed this issue, as Bradley was long under the impression that the GPL could not *possibly* support an argument that mere licensees have some standing to enforce the source code requirement (despite the fact, of which Bradley might not be aware, that over the years some legal academics have at last taken the question seriously, if skeptically, and some private practice lawyers [admittedly seeking to profit from the erstwhile open source boom, the SCO crisis, etc.] purported to take this qite seriously too). I noted the obvious point that copyleft-next and GPLv2/GPLv3 are not worded identically, so his comment was partially irrelevant. Bradley mentioned some interesting work that Australian lawyer Brendan Scott had done attempting, AIUI, to use Australian consumer protection law to give a basis for GPL licensees to sue upstream distributors for failure to provide source code. It is not clear whether such efforts have been successful. - RF

6 14

IRC HBR cure 2013-02-21
by Tom Marble 22 Feb '13

22 Feb '13

Yesterday on IRC a handle of substantive topics were discussed. While it's not clear that any decisions have been taken, the issues raised seem worthy of HBR disclosure. --Tom tmarble discussed the "transitive grace period" mail from Zooko - noted Zooko brought this up before on debian-legal http://lists.debian.org/debian-legal/2009/02/msg00050.html - expressed uncertainty of downstream licensors could "take advantage" of §2 to effectively withhold CCS to derived works for up to a year. fontana noted - §2 does apply to downstream licensors - there is potential for confusion between various grace periods (and maybe even a potential for hucksterism) The group discussed the problematic nature of defining "proprietary" software as not meeting the OSD (too much room for interpretation, lobbying). Fontana considers going back to "OSI Approved". tmarble expressed concern that TPL or TGPPL like terms may introduce vulnerabilities to copyleft-next. Perhaps a permissive license is better suited to that audience? The group was discussing EPL compatibility when mlinksva mentioned another Rich Hickey license. The license in question is the "Datomic Free Edition License" http://www.datomic.com/datomic-free-edition-license.html Despite the title this is a virally non-free license. Interestingly mlinksva points out that large sections of that license are copied verbatim from CC-by-nd 3.0. tmarble brought up the issue of *Sui Generis* database rights and mlinksva stated that he has some pending comments on this topic which are apropos to copyleft-next (for use with licensing data). mlinksva commented on how long and complex the new OSM ODbL license is: http://opendatacommons.org/licenses/odbl/1.0/ warp mentions that coverage of database rights for Europe would be welcome.

1 0

transitive grace period
by Zooko Wilcox-OHearn 21 Feb '13

21 Feb '13

Folks: I'm interested in the possibility of using (a future version of) copyleft-next for Tahoe-LAFS ¹. One possible way to do that would be to define "version 2 of the Transitive Grace Period Public Licence" to be some future version of copyleft-next, or a derivative of copyleft-next. Since Tahoe-LAFS is licensed ³ under "Transitive Grace Period Public Licence, version 1 or, at your option, any later version", then I think this would allow everyone to start using Tahoe-LAFS under the terms of copyleft-next. Another possibility could be that the rights-holders (the Tahoe-LAFS Software Foundation) could re-license it under copyleft-next. My main motivation for considering copyleft-next is that I value concision, simplicity, and readability-to-the-layman. So the pitch for copyleft-next as published in LWN ⁴ appeals to me. There are other things that appeal to me about it, such as the patent lawsuit termination clause. Now, I'm writing to ask: what would it take for me to offer a *transitive* grace period for proprietary derived works? If I understand correctly, §2 prevents a copyright holder from granting only copyleft (not permissive) rights to some people under copyleft-next while granting time-unlimited permissive works to other people. However, consider this scenario, which is actually real life and not hypothetical: 1. Copyright to the Tahoe-LAFS source code is held by The Tahoe-LAFS Software Foundation. 2. LeastAuthority.com (that's my company) has written extensions to Tahoe-LAFS, which constitute a derived work of Tahoe-LAFS source code. LeastAuthority.com has no special permissions to use the Tahoe-LAFS source code other than the publicly available open source licensing cited above. 3. LeastAuthority.com would like to keep our derived work proprietary for a limited time — 12 months from when we start redistributing or hosting it. 4. LeastAuthority.com would like to *not have the option* of changing our minds and keeping the derived work proprietary for longer than that. This may be surprising to you, but it is a form of safety for our customers. We're hoping to get more customers because they know that we *don't have that option*, even if we were to get bought out by a larger company with very different plans than ours. 5. LeastAuthority.com would like, at that future time when we grant open source rights to use our derived work, if other people are able to make derived works of our derived work, and if they are able to keep their derived work proprietary for a limited time, but it is important to us that they are *not* able to keep their derived work proprietary for longer than that. All of the above is actually true, except of course that the parts about what we desire and intend may change with the weather. Now if I understand correctly, if the Tahoe-LAFS Software Foundation were to license the Tahoe-LAFS source code under copyleft-next v0.2, then the Tahoe-LAFS Software Foundation would be able to make proprietary derived works, or to license others to do so, in a time-limited way, but LeastAuthority.com would not. Is that correct? Do you see why that doesn't satisfy our (current) desires? ¹ https://tahoe-lafs.org ² https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.TGPPL.rst ³ https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/about.rst ⁴ http://lwn.net/SubscriberLink/537559/d26523c309dc9933/ Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com

3 4

On emphasizing Sec. 10 & 11
by Masayuki Hatta 19 Feb '13

19 Feb '13

Hi, I know this has been discussed several times and quite cosmetic, but still think that emphasizing Sections 10 & 11 by enclosing hash symbols "##" is (slightly, I admit) confusing. I have to confess that I wondered for some time why those very important clauses are commented-out...maybe I'm too used to some scripting langages ;-) The issue ticket [1] claims that it followed the MPL 2.0 convention, but they actually use asterisks instead[2]. Well, asterisks also remind me of old C-style comments, but I guess * is better than #... Best regards, MH -- Masayuki Hatta Assistant Professor of Economics, Surugadai University, Japan mhatta(a)gnu.org / mhatta(a)debian.org / mhatta(a)mhatta.org / hatta.masayuki(a)surugadai.ac.jp WWW: http://about.me/mhatta [1] https://github.com/richardfontana/copyleft-next/issues/9 [2] http://www.mozilla.org/MPL/2.0/index.txt

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next February 2013