copyleft-next June 2013

copyleft-next@lists.fedorahosted.org

11 participants
7 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

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

An idea
by Richard Fontana 04 Jul '13

04 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

Non-update on copyleft-next
by Richard Fontana 30 Jun '13

30 Jun '13

Hi, Not really much of an update: Of late I've been trying to do something I believe I talked about before, re-implement copyleft-next as a 'file-based' copyleft that is less minimalist than MPL. As of yet I have not figured out how to do this in a way I consider satisfactory, particularly one which is (adequately) programming-language-agnostic and would have normally-sane results, but I feel that it is important to attempt. I am coming to appreciate certain qualities in the MPL approach that I had previously overlooked, or been in some denial about. If some satisfactory result is produced by this effort, it will be a significant change to previous drafts of copyleft-next. It *might* mean enough of a loss of structural elegance as to make it preferable to stick with the existing approach (which I thought was coming along okay), but that is not clear to me yet. - RF

6 7

Expanding the scope of OSI to be an "open source best practices" clearinghouse
by Alison Chaiken 08 Jun '13

08 Jun '13

Thanks to Luis, Simon and Richard for sharing their thoughts about the Certificate of Origin. Codes of Conduct is perhaps another area where OSI could usefully have a compliance specification or approval process similar to its role with open-source licenses: http://www.h-online.com/open/news/item/Python-Software-Foundation-publishes… Codes of Conduct and Certificates of Origin, like software licenses, are areas where larger open-source projects want to adopt accepted best practices, and smaller communities want to expend minimal effort. Perhaps OSI could serve as a central source of all the policies that such communities need to consider, not just software licenses. Best wishes, Alison -- Alison Chaiken (650) 279-5600 (cell) {she-devel.com, exerciseforthereader.org} Your body is governed by ancillary concerns like “stopping the intolerable pain” and “not dying”. Those types of concerns have no place in cycling. -- Velominati, www.velominati.com/look-pro/look-pro-part-vi-move-sur-la-plaque/

4 3

Re: [copyleft-next] LibreOffice Follow Up
by Luis R. Rodriguez 04 Jun '13

04 Jun '13

Putting the DCO / OSI talk onto copyleft-next public lists as that is where we should be talking about DCO evolution. Getting the DCO formalized through the OSI might be appealing to some so throwing it out there as Alison brought this up. Not sure if we need any additional resources at this point, most of the legwork to get it as a standalone document is thankfully already done by W. King but what we do need though is just more visibility, and perhaps address together with the community an FAQ. I believe its best we evolve it openly through copyleft-next and as it stands I believe we last left with the conclusion Fontana would be volunteered to oversee final edits. Curious if anyone has other opinions? Simon, what if we don't need resources other than to declare it as OSI sane or something? Perhaps we could just start off with the existing standalone DCO text that W. King wrote, see if Fontana can help review when the stars align and later see if the board can bless and publish it? If we need an FAQ I can likely hack that up together based on the slides. If this path is desirable I guess I need to join OSI ? Luis On Tue, Jun 4, 2013 at 1:39 PM, Alison Chaiken <alchaiken(a)gmail.com> wrote: > ---------- Forwarded message ---------- > From: "Simon Phipps" <simon(a)webmink.com> > Date: Jun 4, 2013 4:31 AM > Subject: Re: LibreOffice Follow Up > To: "Alison Chaiken" <alchaiken(a)gmail.com> > Cc: > > DCO: Best plan is to form a Member Working Group around it to make a > proposal for adoption. We're still testing the Working Group process but it > involves: > > * A group of OSI Members who > * Write a Charter proposal for the Board stating nwhat they plan to achieve, > starting and ending when, using what resources > * Meet to create a deliverable for OSI that has clearly defined processes > for implementation and maintenance (keeping in mind the Board will not > itself maintain anything - there either has to be a member team or a > staffing proposal) > * Deliver to the Board for adoption > > Does that sound interesting? You could be a test case... > > S. > > > On Tue, Jun 4, 2013 at 6:39 AM, Alison Chaiken <alchaiken(a)gmail.com> wrote: >> >> Simon, I hope that you will consider adopting the Developer Certificate of Origin as >> an OSI-endorsed and maintained document, as there is no other more >> logical party. >> >> Luis Rodriguez' slides: >> >> https://events.linuxfoundation.org/images/stories/slides/lfcs2013_rodriguez…

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

copyleft-next June 2013