copyleft-next May 2013

copyleft-next@lists.fedorahosted.org

17 participants
7 discussions

An interesting take on license compatibility
by Theodore Ts'o 15 Aug '13

15 Aug '13

Althought I don't always agree with all of Rob Landley's positions, I think he had a very interesting take copyleft compatibility issues, and it makes a very interesting counterpoint to the "the state of copyleft is fine" talks that I've been listening to lately. In particular I was taken by Rob's comment: But there's no "the GPL" anymore. Linux and Samba can't share code, even though they implement two ends of the same protocol. And making your project "GPLv2 or later" means you can't take code from _either_ source. Since many people don't have the time (or patience) to wade through the admittedly rather low signal-to-noise ratio of LKML, and I think folks on this list might find it interesting, I thought I'd take the liberty of forwarding it here. So the question with respect to copyleft-next is whether the diagnosis that the reason for the decline in copyleft's popuarity is because the license is too complicated, or for the reasons which Rob has articulated. If the answer is a little of both, is there anything we can do to make sure that copyleft-next doesn't make the problem of splitting the copyleft community worse? (i.e., by introducing a new license which is both GPLv2 and GPLv3 incompatible) The other thing that's worth thinking revisiting is the whole "friendly to app store" question. I do believe that if more and more users get their applications via application stores (insert the standard story of the rise of mobile devices and the decline of PC's), the fact that code can't be used by people who intend to publish their products via app stores is going to significantly decrease their desire to want to use a copyleft license. Is there some way we could introduce some kind of DMCA passthrough like arrangement? I can easily imagine Amazon not being thrilled about the possibility, if someone uploads sources which do not correspond to the binary, and a Rabid Copyleft Enforcement organization (which is hypothetical; I am not positing that any of the existing copyleft efforts fall is this category) sues Amazon to be in compliance, it could very easily be the case that Amazon does not have the power to force the organization which uploaded the the binary to cure the noncompliance. And if said copylefted source code was something Amazon was using in other contexts (for example, the Linux Kernel or glibc), the fact that some cad uploaded a non-compliant binary package should not be grounds for forcing Amazon from not using said package forever. And the obvious solution here is for Amazon to simply have a rule "no GPL in packages you upload to our app store". I understand that in the case where it is a embedded handset manufacturer, you want to be able to hold their feet to the fire, but if the goal is to promote the use of the copyleft license, it's not clear that the threat of holding an app store owner to the file is neither just nor wise. Especially since you could substitute "Debian" for "Amazon" in the above scenario, and realize that a malicious Debian maintainer, colluding with someone who owned copyright on some or all of some package which is critical to Debian's operations, could conduct a very nasty, legal Denial of Service attack on Debian.... - Ted On Tue, May 21, 2013 at 05:11:47AM -0500, Rob Landley wrote: > On 05/18/2013 01:27:21 PM, luke.leighton wrote: ... > > actually, that's a good point. please can it be specifically noted, > >from this moment onwards, that all contributions that i have made to > >the linux kernel are dual-licensed under both the GPLv2 and also the > >GPLv3+ license? > > I have a git repository that goes back to 0.0.1. The word "leighton" > (case insensitive) occurs in the full log exactly once, in a single > 2004 commit that wasn't even done by you but was apparently inspired > by a patch you did. > > >someone has to start somewhere on this. it doesn't matter if it takes > >20 years for all GPLv2-exlusive contributions to be made obselete, > >deleted or replaced: a start has to be made. > > You're aware that copyleft in general is declining, right? > > "The GPL" was synonymous with copyleft. It was a terminal node in a > directed graph of license convertability, and the only thing > programmers had to know is whether or not some other license was > GPL-compatible. If it was: treat it as GPL. If it wasn't: ignore it. > > But there's no "the GPL" anymore. Linux and Samba can't share code, > even though they implement two ends of the same protocol. And making > your project "GPLv2 or later" means you can't take code from > _either_ source. These days the GPL largely serves to _prevent_ code > re-use, and people have responded to the percieved problems with > "GPL-next" initiatives where they fragment copyleft further with > Affero variants, by using creative commons on code, and so on. But > copyleft only ever worked as one big universal license, and now it > doesn't. > > In the absence of a universal receiver, most developers have > switched to universal donor licenses: MIT/BSD or even public domain. > Yes, "most": the most common license on Github is "no license > specified", and that's not just ignorance, that's napster-style > civil disobedience from a generation of coders who lump copyright in > with software patents and consider it all "too dumb to live". (You > think GPL enforcement suits are viewed any differently than DMCA > takedown notices on youtube, both coming from clueless old people?) > > Now add in Android's official "no GPL in userspace" policy, which > means that if you preinstall GPL (or LGPL) software in your install > image, you can't use the Android trademark to describe your product. > (Did I mention that smartphones are replacing the PC? Mainframe, > minicomputer, microcomputer, smartphone: > http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=30s and that's why > Android matters; it can get preinstalled on that class of hardware. > Linux has been trying for 20 years and still has less than 2% > marketshare on any device an end-user interacts directly with.) > > I'm sorry, but Richard Stallman _screwed_up_. GPLv3 suceeded where > Sun's CDDL failed: it split copyleft into incompatible warring > factions which are collectively shrinking in market share because > none of them are as useful a "The GPL" was. > > I miss "the GPL". But it's gone. It seems to be being replaced by a > gradual shift to public domain code on the part of younger coders. > (Part of this may just be that proprietary software ran its course. > The ability to sell binary-only software was invented by the Apple > vs Franklin decision in 1983 extending copyright to binaries, and > over the next 20 years the market proved that just leads to > abandonware and monopoly exclusion. That's about when Microsoft > peaked and started stagnating, a dozen years ago. Making a killing > selling shrinkwrapped software isn't nearly as attractive as it used > to be.*) > > Advocating for GPLv2 to go away is sad, but understandable. > Expecting GPLv2 to be replaced by GPLv3 is just delusional. > > Rob > > * Except for terminal nodes like games where there can't be any > lock-in because users don't derive work product from the software. > Users seem to have developed a resistance to "you can hold my thesis > for ransom because I wrote it with your software and your gatekeeper > program can revoke my access to my own work", presumably because so > many tools have gone away over the years. Of course the lesson has > to be learned all over again with web services, and some things like > photoshop are grandfathered in. As always, reality is > complicated...

6 15

copyleft-next 0.3.0 released
by Richard Fontana 05 Jul '13

05 Jul '13

Good news, everyone! copyleft-next 0.3.0 has been released! https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/Releases… A summary of changes relative to the previous released verson shall be provided in due course. - RF

13 32

[OT] tips/tricks/best practices for non-programmers using git for plain text documents?
by Luis Villa 30 May '13

30 May '13

Apologies for the slightly OT post: Does anyone here know of a document/documents that give non-programmers tips/tricks/best practices on using git for plain text documents? Obviously to some extent this is just "git for non-programmers" but I'm guessing that there are other non-obvious best practices that non-programmers could stand to learn, and that I'm hoping someone has written up somewhere. For example, since non-programmers tend to pass around entire word docs instead of patches, they're likely to do all edits to a document and then submit a single gigantic change, instead of breaking it up into small functional changes (as is probably best practice). Compounding this (for me) is that I've often found it difficult to figure out how to cleanly break up patches into small bits in git. (I think there are some records of this in gitorious :) Thoughts? Suggestions? Thanks ahead of time- Luis

5 4

Disclosing two bugs filed
by Stephen Michael Kellat 20 May '13

20 May '13

It is best to note that I have filed two bugs seeking support for copyleft-next in various places. Stephen Michael Kellat Begin forwarded message: Date: Sun, 19 May 2013 17:52:15 -0000 From: Stephen Michael Kellat <skellat(a)fastmail.net> To: skellat(a)fastmail.net Subject: [Bug 1181818] [NEW] Launchpad does not support copyleft-next as a license choice for projects Public bug reported: For projects being hosted on Launchpad, Launchpad does not support the selection of copyleft-next as a usable license. The license is available via copyleft-next.org and the current version is available at https://gitorious.org/copyleft-next/copyleft- next/blobs/raw/master/Releases/copyleft-next-0.3.0 for review. ** Affects: launchpad Importance: Undecided Status: New -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/1181818 Title: Launchpad does not support copyleft-next as a license choice for projects Status in Launchpad itself: New Bug description: For projects being hosted on Launchpad, Launchpad does not support the selection of copyleft-next as a usable license. The license is available via copyleft-next.org and the current version is available at https://gitorious.org/copyleft-next/copyleft- next/blobs/raw/master/Releases/copyleft-next-0.3.0 for review. To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad/+bug/1181818/+subscriptions Begin forwarded message: Date: Sun, 19 May 2013 17:44:40 -0000 From: Stephen Michael Kellat <skellat(a)fastmail.net> To: skellat(a)fastmail.net Subject: [Bug 1181811] [NEW] Packaging tool does not support copyleft-next license Public bug reported: Description: Ubuntu 13.04 Release: 13.04 Installed: 3.1.1-2ubuntu6 Candidate: 3.1.1-2ubuntu6 Version table: *** 3.1.1-2ubuntu6 0 500 http://ca.archive.ubuntu.com/ubuntu/ raring/universe i386 Packages 100 /var/lib/dpkg/status The packaging tool does not support the copyleft-next license as an option. The latest version as of bug filing is available here: https://gitorious.org/copyleft-next/copyleft- next/blobs/raw/master/Releases/copyleft-next-0.3.0 Attempt to create a package. Select "Other license(s)". The wizard does not let you specify directly the license which requires post-wizard tampering. ** Affects: gambas Importance: Unknown Status: Unknown ** Affects: gambas3 (Ubuntu) Importance: Undecided Status: New ** Bug watch added: code.google.com/p/gambas/issues #431 http://code.google.com/p/gambas/issues/detail?id=431 ** Also affects: gambas via http://code.google.com/p/gambas/issues/detail?id=431 Importance: Unknown Status: Unknown -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/1181811 Title: Packaging tool does not support copyleft-next license Status in Gambas: Unknown Status in “gambas3” package in Ubuntu: New Bug description: Description: Ubuntu 13.04 Release: 13.04 Installed: 3.1.1-2ubuntu6 Candidate: 3.1.1-2ubuntu6 Version table: *** 3.1.1-2ubuntu6 0 500 http://ca.archive.ubuntu.com/ubuntu/ raring/universe i386 Packages 100 /var/lib/dpkg/status The packaging tool does not support the copyleft-next license as an option. The latest version as of bug filing is available here: https://gitorious.org/copyleft-next/copyleft- next/blobs/raw/master/Releases/copyleft-next-0.3.0 Attempt to create a package. Select "Other license(s)". The wizard does not let you specify directly the license which requires post- wizard tampering. To manage notifications about this bug go to: https://bugs.launchpad.net/gambas/+bug/1181811/+subscriptions

4 5

Developer Certificate of Origin - Signed-off-by standalone project followup
by Luis R. Rodriguez 17 May '13

17 May '13

At the 2013 San Francisco Linux Collaboration talk I gave a talk [0] as a followup on the discussions I initiated a while ago on lkml [1] on the possibility of taking the Linux kernel's Developer Certificate of Origin and streamlining it by making it a stand alone project for other projects to benefit from it. This is a follow up to that talk. W. Trevor King did some handy work by doing taking the Linux kernel's DCO and making it a standalone project on github [2] and keeping its history already. He's also made it project agnostic. To make a standalone DCO project agnostic and useful for any type of project it would help if any licensed project could use it. One question that we had over this idea was whether or not the DCO is licensed under the GPLv2 or not. Its arguable whether or not its copyrightable, perhaps not but just the idea of contributions to it might make it so. Although we could try to get a Creative Commons licensed DCO (and at least for the standard body text, not the rest of SubmittingPatches I'll go poke) King has made it possible for any licensed project to use the DCO standalone project by making a Creative Commons licensed file that simply refers to the public URL of the project. As per discussions at LF collab it was acknowledged that the DCO could indeed be a benefit to other projects but we'd need to ensure that the body of the text is maintained as a very conservative document. I also wanted to address volunteering a real life attorney to help with reviews / maintenance so I volunteered Richard Fontana given Richard's public work on copyleft-next and the copyleft-next mailing list availability and his public work as an attorney for the community there [3]. Richard seems to have accepted. What's next? Please join the copyleft-next mailing list if you are interested in evolving the DCO and helping with streamlining this effort. [0] https://docs.google.com/presentation/d/1J4VTSTuiJ88xcvOrYg7HRvwUoxOW9qvnBqO… [1] https://lkml.org/lkml/2012/11/20/636 [2] git://github.com/wking/signed-off-by.git [3] http://lists.fedorahosted.org/mailman/listinfo/copyleft-next Luis

1 0

copyleft-next commit b2f0c69e - combining permissive license content
by Luis R. Rodriguez 17 May '13

17 May '13

I got a question regarding this commit: commit b2f0c69e5fc1ec37cb787a9981154630b09e8e0d Author: Richard Fontana <fontana2012(a)gmail.com> Date: Tue Nov 20 10:52:53 2012 -0500 Clarify language of section 5 (Distributing Derived Works) diff --git a/Drafts/copyleft-next b/Drafts/copyleft-next index 88addc2..e10119f 100644 --- a/Drafts/copyleft-next +++ b/Drafts/copyleft-next @@ -90,10 +90,10 @@ THIS IS A DRAFT. DO NOT USE AS A LICENSE. 5. Distributing Derived Works. - You may Distribute a Derived Work, provided that you license the - entire Derived Work under this License, and include prominent - notice of such licensing. This condition may not be avoided through - such means as separate Distribution. + 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. 6. Direct Licensing. Today's v0.3.0 added the GPL option too, so today's paragraph 3 reads: 3. 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 the GPL, so that the recipient may further Distribute the Derived Work under either this License or the GPL. The GPL allows for GPL-compatible work to be integrated into it. In a larger GPL project this allows for example say a group that wants to share code with the BSD family to license code under a permissive GPL-compatible license, and then through usage of things like the DCO maintain it under a permissive license. Then portions that are copyleft could be extracted by the BSD folks and they could go live happy in their permissive license world. Does the above paragraph prevent this type of sharing ? If so does the option to re-license to GPL allow for it? Luis

1 0

HBR cure (2013-04-17)
by Richard Fontana 06 May '13

06 May '13

This is a Harvey Birdman Rule violation cure. On or about Wednesday, 17 April 2013, in San Francisco, in the late afternoon, I had a short conversation with Mike Linksvayer concerning copyleft-next that I believe triggered HBR. As I recall: Mike asked me if I was still planning on drafting an Affero-ish variant of copyleft-next. I said I was, and that I had recently wondered whether my previous assumption (start with a non-Affero copyleft-next and work on the Affero variant afterwards) may have had things backwards. The substantive obstacle I have been facing with copyleft-next (as I think I explained on this list a couple of weeks ago) relates to the 'rule vs. standard' dichotomy; I believe a simpler alternative to the GPL ought to (ideally) require greater ease of application and interpretation. I do not know how to achieve this, and perhaps it is not achievable. That is to say, the best we can hope for wrt making copyleft-next "easier" (beyond the kind of structural and textual clarity and simplicity already present in existing versions) is to improve in small ways on some of the basic definitions in copyleft-next and rely on the development of useful authoritative interpretation. However, I'm still not ready to concede that. Anyway, as I recall, I said to Mike that perhaps drafting an Affero-ish variant of copyleft-next might produce insights into how to draft what I've previously been thinking of as the vanilla version. I have also previously and separately wondered whether an Affero-ish copyleft-next ought to be MPL-like in its approach to the copyleft boundary issue. This is all related to suggestions, made at times by Michael Meeks and by Bradley Kuhn, that a "Lesser AGPL" may be useful. - RF

6 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next May 2013