copyleft-next July 2013

copyleft-next@lists.fedorahosted.org

4 participants
6 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

Pull requests on GitHub
by Adam Saunders 23 Aug '13

23 Aug '13

Hello, Recent Canadian law school graduate here. I like simple open source licenses, hence my interest in copyleft-next. Are you still taking pull requests on the GitHub repository? I understand that the Gitorious repository is the official one for the project, but it seems to me that both repos are kept in sync, and I don't have a Gitorious account (yet). If not, I'd be happy to get a Gitorious account to make my pull request there. Thanks, Adam Saunders

3 2

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

Comments on experimental
by Engel Nyst 09 Jul '13

09 Jul '13

A few comments on the experimental branch.[1] 1) Section 4, copyleft conditions, 3rd paragraph, says that you could distribute "a Modification under this License even if it incorporates third-party material governed by a license that is both OSI-Approved and FSF-Free". It seems to amount to distribution of code under two licenses, in the sense of juxtaposing code under different licenses in the same file, which sounds very confusing. I suppose this reading is incorrect, or there is some reason for this? 2) I'd think the licensing condition on a patch (section 6) should be licensing by default under the free and open license of the file as applicable, like the DCO language, or I'm not sure how it'd work otherwise... 3) Trivial stylistic comment The definition of Modified Code doesn't sound as nice as the previous definition of Derived Work :-) (sorry!) I wonder if it is necessary to entirely replace the use of the verbs (i.e. adapt, transform) with addition and deletion operations? I think to me, it'd seem natural if some of these verbs would be expressly applied to source code in files. 4) Copyleft conditions To summarize (please correct me if this is wrong), as long as a file has copyrightable code under copyleft-next, the file is licensed under copyleft-next. Neighboring code, code using the copyleft-next-ed code, is free and open source. (within some limits) One reason why I support this experiment, is that to me, there isn't a clear difference between the neighboring code in copyleft-next-experimental and the code incorporated as open licensed in copyleft-next-master (under section 4). I mean this in the sense that code incorporated as open licensed (under section 4 master) can lead to neighboring code easily during development, without necessarily realizing it. But any recipient should be able to trust it has the open license under which it's distributed. Accepting neighboring code as open licensed in the license, makes that clear. 5) A remark MPL copyleft is IMHO the closest match for the 'strongest layer'. I mean I think it's a very understandable definition of the first layer for the copyleft-next scope. And I think the reason is indeed as noted by Fontana in another thread: because MPL boundary is the same with almost all other licenses (MIT, BSD) boundary: the copyrightable code, the source of licensing conditions on the code. An open source developer will know when there's MIT code in a file to respect its attribution conditions accordingly; or BSD code, or AL2.0 code. The criteria for MPL are no different. The file headers reflect copyright and any license under which there is copyrightable code in this file. (AFAIK, it's much more common to write headers with copyright and license information in files; even if this information is of course also per package.) I'd say it's routine in an open source project, and I'd say it's simple. I'll add here some thoughts I've been having, not in an organized manner, I will only note them down, for the list. Richard Fontana reminded in a previous email thread on this experiment, of GPLv2 section 2, the 2nd and 3rd paragraphs. I remember reading these paragraphs years ago, and finding the concept *fair*. I'm not sure GPL really does that, though. Or the way it does it, through relicensing every open license, or reject combination with it if it can't (calling it incompatible), is arguably not ideal. (which is not necessarily to say there is another objectively better way, but other ways with different trade-offs.) When there's no copyrightable code in a file, it's work written entirely by someone else. Taken in itself. It applies to a package, a library, an application. It doesn't matter if individual developers may happen to be the same, because the *license* matters more in many ways. And the license on that file can be BSD. Or MIT, AL2.0, or MPL. It might be more obvious for web applications in some interpreted languages, with open repositories. (or for permissive projects). OTOH, when there's no copyrightable code in a file/package, the code _written entirely by someone else_ might interact with copylefted code, add behavior or change behavior, such that the result of their combination will be a work of authorship standing on its own too. Or, it might not; it can be very loosely related, a package with an implementation which has nothing to do with another, except there's a call to tie the two. (such as 'import' and use some method, as it's been noted lately on this list) In copyleft-next-experimental, as long as work "written by you" is combined with "my" code to form a new work, then I will ask you explicitly only to offer users the same freedoms as any open licensed software does: your code can be BSD, MIT, MPL licensed. Only that it will be as software should be: free and open software. Not copyleft-next. Experimental branch copyleft-next-ed code accepts around it any free and open license as it is. It doesn't (re)license neighboring code to copyleft-next, and it doesn't disallow code/data sharing if they're not relicensable to it. If I include a BSD file, in a copyleft-next-experimental project, it's unambiguously BSD. Whether it uses the copyleft-next code or not. If I take away a BSD file, from the copyleft-next-experimental project, it's BSD. It can be licensed proprietary separately (*its* downstream). But *not* as long as it's part of a work that incorporates the copyleft-next-ed code: the copyleft-next license guarantees that. Copyleft-next-ed code is incompatible with *proprietary* licensed code. Not as much open licensed. It can't be incorporated in proprietary software.[2] This is an essential goal of strong copyleft, and it never changed. Its intention is to be incorporated in open source software. The concept is "weaker" than practically relicensing any part of the derivative/collective work. It doesn't do that. But, its scope extends beyond "weak" copyleft. It enables an ecosystem of free and open source software around it. To me, this license and its *clarity* would be very valuable, if it's possible. I should say I am biased, though, and I surely can miss otherwise very obvious issues. I think perhaps copyleft doesn't have to be a "license of all licenses, which converts everything to it, or rejects sharing". Copyleft is the guarantee of freedom. A guarantee to downstream users, in a way that enables free and open software to build upon it. I wonder if the concept is contradictory in some way I don't entirely see? Or unenforceable. It unambiguously allows every open license to set its own conditions only, when the software, source or binary, is distributed *separately*. (as Fontana mentioned in the idea thread). What would the worse scenario? [1] https://gitorious.org/copyleft-next/copyleft-next/blobs/experimental/Drafts… [2] cf GPLv2 and v3 last paragraph.

2 2

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

06 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

An idea
by Richard Fontana 05 Jul '13

05 Jul '13

Here's an idea, or rather half or so of an idea, I have. Suppose all there is is source code (more precisely the preferred form for making modifications); we live in a universe where there is no object code or where object code is beyond the scope of copyright (this is just for simplicity). A work is necessarily something digital and presented as a set of one or more files. This is of course the explicit basis for the weak approach to copyleft in the MPL and its ancestors and progeny. Although one might argue it is not so obvious from the language of any version of the MPL (or ancestral or derivative licenses -- I'll just say "MPL"), I think the common understanding, and certainly what makes MPL a 'rule-based' (and possibly-necessarily) weak copyleft, is that copyleft extends only to source files that are verbatim copies or new downstream files which copy sufficiently from upstream ones. To try to go further than this is what Jim was proposing in the epl-discuss posting I noted in my previous post. The implicit, and sometimes explicit, critique of MPL-family licenses by advocates for orthodox-discourse GPL strong copyleft interpretation, is that this leaves some possibility for circumvention of copyleft that is avoided either by the actual language of the GPL or by some consensus around its proper interpretation. The problem with the latter is the "legal angst" that was referred to in the epl-discuss thread, which kind of implies an absence of consensus, even in the weak copyleft context of EPL 1.0. Suppose I create a set of source files, S1. Someone downstream creates S2 by copying some files in S1 verbatim, modifying some S1 files (such that those files contain what is indisputably nontrivial literal copying from S1), and adding some new files that indisputably do *not* contain nontrivial literal copying from S1 (let us call that set of new files N). Regardless of the source code programming language, in the general case there will be dependency relationships among some of the files in S1, and, independently, among some of the files in S2. S2 might contain copyrightable code from third parties (as might S1) but ignore that complication. If I apply the MPL 'rule', I can easily figure out what files in S2 are in the scope of the copyleft coming from S1; I'll call that subset T. It will not include anything in N. There is a subset of the files in N, I'll call it N', that have direct or indirect programmatic dependency relationships (according to the nature of the particular programming language at issue) with files in T. Suppose the copyleft rule is this: as in MPL, files T must be licensed under copyleft-next. Files N' can be, but need not be, licensed under copyleft-next, and instead can be licensed under some sort of acceptable FLOSS license, copyleft or noncopyleft. GPL, MIT, whatever. Suppose further that the rule allows anyone to avoid the condition for the licensing of files N' by distributing them separately. If you want to distribute N' under a proprietary license, do it separately. (Ignore the possibility of some definitional problem here.) Otherwise those files have to be FLOSS, but the precise license doesn't matter (within some defined limits). Suppose further that copyleft-next has a clause (as some early versions did) clarifying that no lawful uses under copyright law are limited or excluded. Also suppose that copyleft-next has some kind of safe harbor for package-oriented operating system distros, app store vendors, and similar things (such that the separate distribution circumvention is something that the distro or app store vendor or whatever can engage in without having to worry too much about it until notice is received). This is a strange idea, but it is a kind of stronger copyleft than exists under MPL-like licenses. (Depending on the situation, and how one interprets the LGPL, it might be weaker or stronger than the LGPL.) It resolves the 'legal angst' in a number of ways: reducing copyleft analysis to something like a simple static analysis problem; making separate distribution an excuse (explicitly not so in GPLv3), potentially avoiding a lot of the perceived problems of license incompatibility across source file boundaries, ensuring closely related code (distributed together) is FLOSS (even if noncopyleft in isolation -- this is no different from what we see in some GPL works today, and cf. GPLv2 section 2, antepenultimate paragraph). It certainly allows modes of circumvention that are assumed to be absent under interpretive-orthodoxy GPL (which itself is understood to allow some modes of circumvention). But apart from that, is this a bad idea, or a nonsensical idea? - RF

5 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next July 2013