HBR cure (2013-04-17)
copyleft-next commit b2f0c69e -...
copyleft-next patent commons?
Richard Fontana
Friday, 19 April 2013 Fri, 19 Apr '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
Pamela Chestek
Friday, 19 April Fri, 19 Apr
I've had thoughts about the "rule vs. standard" question but I haven't been able to reach any conclusion, so I'll just throw them out there. My first thought was that the appeal of a rules-based license is that it is the form probably preferred by people who write code because it most closely fits with how they process a decision tree. So I expect it will be more appealing from a license-adoption standpoint. But others have described the flaws; to me lack of flexibility in changing circumstances and the high likelihood of silly results if no common sense is applied are the two most important. The problem with the standard- based license is that it requires much more trust that the enforcer will be reasonable and not stretch ambiguous boundaries too far. But when you have a license that is perceived as ideologically-based, then there will naturally be a fear of over-enforcement. So what you're inhibiting is the adoption of the software, even by those of good intention. Perhaps the FAQs will be a partial solution, they can at least explain in more detail what the intent was and perhaps provide a governor on over-enforcement. So I think it depends on what your goals are, and if you want copyleft software to be more widely-disseminated you have to find a way to provide reassurance that the enforcement will be forgiving of human error, ambiguity, and the differing of reasonable minds. Pam On Fri, Apr 19, 2013 at 5:27 PM, Richard Fontana <fontana(a)sharpeleven.org&gt;wrote:
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 _______________________________________________ copyleft-next mailing list copyleft-next(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
Luis Villa
On Fri, Apr 19, 2013 at 2:27 PM, Richard Fontana <fontana(a)sharpeleven.org&gt;wrote:
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.
It certainly can't hurt in getting out of your writer's block. You might also consider tackling a permissive ("by-next" ;) at the same time. By the way, did you ever look at http://tieguy.org/blog/2011/03/31/mpl-beta-2-as-faq/ (specifically http://mpl.mozilla.org/wp-content/uploads/2011/03/MPL-as-FAQ-B2.pdf ? ) Strikes me that I've never discussed that here, and that you might find it interesting.
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.
FWIW I agree with them, and have considered drafting, but never had the time for, a "Mozilla Network Services Public License." Luis
Monday, 22 April Mon, 22 Apr
On Fri, Apr 19, 2013 at 06:51:23PM -0700, Luis Villa wrote:
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. It certainly can't hurt in getting out of your writer's block.
Yeah, I guess it is partly writer's block.
You might also consider tackling a permissive ("by-next" ;) at the same time. By the way, did you ever look at http://tieguy.org/blog/2011/03/31/ mpl-beta-2-as-faq/ (specifically http://mpl.mozilla.org/wp-content/uploads/ 2011/03/MPL-as-FAQ-B2.pdf ? ) Strikes me that I've never discussed that here, and that you might find it interesting.
I remember looking at that, yes, shortly after you published it. For a while I was thinking about radically different forms of presentation for copyleft-next (not sure what I meant by that other than some vague notions about typography) but had forgotten about the license-written-as-FAQ idea. - RF
On Apr 22, 2013 8:46 PM, "Richard Fontana" <fontana(a)sharpeleven.org&gt; wrote:
On Fri, Apr 19, 2013 at 06:51:23PM -0700, Luis Villa wrote: > Anyway, as I recall, I said to Mike that perhaps drafting an > Affero-ish variant of copyleft-next might produce insights into how
> draft what I've previously been thinking of as the vanilla version. > > > It certainly can't hurt in getting out of your writer's block. Yeah, I guess it is partly writer's block.
It is other, more weighty, concerns as well, and I don't intend to trivialize them. But tackling something else can free you up. Luis
Kuno Woudt
Wednesday, 24 April Wed, 24 Apr
Hello, On 19-04-13 16:27, Richard Fontana wrote:
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.
I'm not sure exactly where the boundaries are with either GPL or LGPL when dealing with web applications (which is where you'd expect developers to pick the AGPL), so I would certainly welcome a license where this is clearer. When you consider the GPL as applied to a statically compiled binary, the GPLis easy to understand. The third-party libraries you're using areintertwined with your own code, and so the GPL applies to the entirething. But web applications are often distributed as source repositories with a machine-readable list of third-party libraries [1]. Usually a package manager such as npm, pip, gem, maven, cabal, cpanm, etc.. will read the list and install the requirements for you as part of the installation process. In most cases I would consider such libraries to be creative works separate from the web applications which use them, and asa web developer I don't think it is necessary for the (A)GPL to extendto them in the same way the GPL does for a statically compiled command line or desktop application. Often though javascript libraries are not installed in that way, but areembedded in the repository [2]. In this case it is tempting for a developer who discovers a bug in such a library to patch it in their source tree in addition to reporting the bug upstream -- which then means the copy embedded in your source repository has changesspecific to your web application, which makes it much more part ofyour project compared to a library which is only referenced in a machine readable requirements list. So, for typical web application projects I'd say the copyleft license shouldextend to all code which is part of the same source code repository, butnot be "viral" beyond that. (I have no idea if that can be implemented in a copyleft license without any serious loopholes). How do you envision the boundaries of an AGPL or Lesser AGPL variant of copyleft-next? [1] Some examples (though there are many more): mediagoblin: https://gitorious.org/mediagoblin/mediagoblin/blobs/master/setup.py musicbrainz: https://github.com/metabrainz/musicbrainz-server/blob/master/Makefile.PL pump.io: https://github.com/e14n/pump.io/blob/master/package.json [2] Embedded javascript examples: mediagoblin: https://gitorious.org/mediagoblin/mediagoblin/trees/master/extlib musicbrainz: https://github.com/metabrainz/musicbrainz-server/tree/master/root/static/lib pump.io: https://github.com/e14n/pump.io/tree/master/public/javascript/libs (note there are solutions like bower and fanstatic which avoid this, but they don't seem to be very popular yet).
On Wed, Apr 24, 2013 at 04:23:43PM -0500, Kuno Woudt wrote:
When you consider the GPL as applied to a statically compiled binary, the GPL is easy to understand. The third-party libraries you're using are intertwined with your own code, and so the GPL applies to the entire thing.
Apart from whatever is covered by the system library exception. At the Collab Summit there was a panel with me, bkuhn and Eileen Evans of HP on AGPL, a sort of reprise of the one we did with Chris Webber at FOSDEM. I recall making the point that there was a more difficult 'copyleft boundary' issue with AGPL, that with GPL you can sort of work your way back from the binary you receive. But bkuhn argued that this was illusory; the GPL really raises as many difficult 'boundary' questions as the AGPL (though I think he might argue that they often are of secondary importance in the kinds of compliance situations he deals with). I actually think he may be right, but I consider this suboptimal (I think I jokingly said that bkuhn 'celebrated' the complexity of the boundary issue).
But web applications are often distributed as source repositories with a machine-readable list of third-party libraries [1]. Usually a package manager such as npm, pip, gem, maven, cabal, cpanm, etc.. will read the list and install the requirements for you as part of the installation process. In most cases I would consider such libraries to be creative works separate from the web applications which use them, and as a web developer I don't think it is necessary for the (A)GPL to extend to them in the same way the GPL does for a statically compiled command line or desktop application. Often though javascript libraries are not installed in that way, but are embedded in the repository [2]. In this case it is tempting for a developer who discovers a bug in such a library to patch it in their source tree in addition to reporting the bug upstream -- which then means the copy embedded in your source repository has changes specific to your web application, which makes it much more part of your project compared to a library which is only referenced in a machine readable requirements list. So, for typical web application projects I'd say the copyleft license should extend to all code which is part of the same source code repository, but not be "viral" beyond that. (I have no idea if that can be implemented in a copyleft license without any serious loopholes).
This is a very interesting point, as I think it also has relevance to the GPL. This is precisely what I was getting at in my posting on 7 April, where I complained: We have things like the FSF's FAQ, perhaps intentionally designed to encourage people to err on the side of releasing more rather than less GPL-compatible source code, and at any rate *largely out of touch with actual conduct by projects (including the very distributions the FSF endorses!) that release or use strong (or, for that matter, weak) copyleft code*. (emphasis added) What I specifically meant there was the conduct of mainstream Linux distros. I contend that, if you study any such distro, you will have to conclude that the distro assumes that the copyleft boundary is the package boundary, even for GPL-licensed packages, except in really unusual cases. (The unusual cases are typically the result of someone raising an issue that is rooted in some understanding, correct or not, derived from FSF GPL doctrine.) Put a little more simply: For mainstream Linux distros, strong copyleft seems to be quite a bit weaker than the strong copyleft a person from Mars would assume to be correct interpretation merely by reading the FSF FAQ and so forth. It is also interesting to me that almost no one has talked about this difference between theory and practice. My own intuition about this is that Linux distros (distributing thousands of modularly distinct packages with complex dependency relationships, most of the code being GPL'd) simply cannot do the analysis that FSF GPL doctrine might seem to imply ought to be done. It is probably also relevant that such distros are typically 'good actors'; they are often noncommercial community projects and they all tend to provide source code and so forth. Now of course the fact that source code is provided and the software tends to be free software is also relevant in that this arises as an issue of license compatibility. That shouldn't make a difference beyond what I said in the previous paragraph, because the entire orthodox doctrine of GPL license compatibility is based on the theory of strong copyleft. (BTW I think I have kind of solved all significant license compatibility problems in a change made yesterday to copyleft-next, somewhat relevant to this topic.)
How do you envision the boundaries of an AGPL or Lesser AGPL variant of copyleft-next?
Not sure yet, but I will say that it is reassuring that you are seeing the same issues that I am seeing. :) - RF
Joshua Gay
Monday, 6 May Mon, 6 May
On 04/25/2013 12:40 AM, Richard Fontana wrote:
My own intuition about this is that Linux distros (distributing thousands of modularly distinct packages with complex dependency relationships, most of the code being GPL'd) simply cannot do the analysis that FSF GPL doctrine might seem to imply ought to be done.
I think you are blowing the complexity out of proportion. The entire point of distros is to organize the source and binary package information including the build dependency info. The complete and corresponding source and build information is usually maintained pretty well in the individual source packages (and note that binary packages do not always have a one-to-one correspondence with source packages, so when reasoning about any of this it is important to look at how source packages are mapped to binaries, etc). And, while it is true that most distros do not attempt to distinguish between what is part of the covered work vs the installation information vs aggregate works, it is also true that some distros, like Debian are actually taking big steps to improve this situation. Debian is starting to add machine readable copyright and licensing info to their packages. Recently we began importing Debian packages with licensing info into the Free Software Directory, so I have had a chance to look over *a lot* of these packages. So far I have been pretty impressed at the care a lot of package maintainers are taking in their attempts to list copyright and licensing info within source packages. But, this is also a big step toward having more detailed info organized and provided that brings the licensing info together with the dependency info. Which will also make it a lot easier for large distros with lots of different packages of varying stages of maturity to be able to more easily keep track of licensing compatibilities and everything else. But, anyhow, I'm being just as vague and general as you are. Perhaps this conversation would be better off looking at some examples or perhaps someone would be willing to put together a little case study (or an outline of one).
On Mon, May 06, 2013 at 11:27:56AM -0400, Joshua Gay wrote:
Debian is starting to add machine readable copyright and licensing info to their packages. Recently we began importing Debian packages with licensing info into the Free Software Directory, so I have had a chance to look over *a lot* of these packages. So far I have been pretty impressed at the care a lot of package maintainers are taking in their attempts to list copyright and licensing info within source packages.
Sure, that is a good thing.
But, this is also a big step toward having more detailed info organized and provided that brings the licensing info together with the dependency info. Which will also make it a lot easier for large distros with lots of different packages of varying stages of maturity to be able to more easily keep track of licensing compatibilities and everything else.
I guess my point is that if it's taken this much time to get closer to that point, and Debian is only in the earliest stages of what is necessary to get to that point, something is wrong. The fact that no one thinks there is any big problem is also quite significant. Here's what I've been trying to say, or what I've been thinking about at least: There are obviously multiple ways of interpreting the GPL generally and as applied to some particular fact pattern. But I discern at least two principal macro-interpretations of the GPL. One consists of the collective and evolving (explicit where recorded at all) doctrine of the FSF, as further interpreted or, seemingly, misinterpreted by others. The other is a mostly implicit body of doctrine deducible from behavior, that consists of what developers and distributors actually *do*, and what upstream licensors seem to knowingly tolerate. There is some problem in the existence of a gap between these two things; they are in tension because the latter seems to suggest a more permissive interpretive theory than the former. By the way, this is not necessarily restricted to the GPL (or even to FLOSS licensing), but I think it's particularly interesting in the GPL context. - RF
On 06-05-13 11:49, Richard Fontana wrote:
Here's what I've been trying to say, or what I've been thinking about at least: There are obviously multiple ways of interpreting the GPL generally and as applied to some particular fact pattern. But I discern at least two principal macro-interpretations of the GPL. One consists of the collective and evolving (explicit where recorded at all) doctrine of the FSF, as further interpreted or, seemingly, misinterpreted by others. The other is a mostly implicit body of doctrine deducible from behavior, that consists of what developers and distributors actually *do*, and what upstream licensors seem to knowingly tolerate.
Hm, but Debian has certainly in the past acted on GPL incompatibilities between packages. For example "php -a" was broken for a while because the GNU readline license isn't compatible with the php license [1]. I vaguely remember similar problems with debian shipping various programs without SSL support for a while because the OpenSSL license is not considered GPL compatible. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286356 So, as far as I can tell at least Debian takes things seriously and largely follows the FSF interpretation. -- kuno / warp.
copyleft-next@lists.fedorahosted.org