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
On Fri, Jun 21, 2013 at 8:31 PM, Richard Fontana fontana@sharpeleven.org wrote:
But apart from that, is this a bad idea, or a nonsensical idea?
Sensical, maybe good, but from one traditional perspective sounds like weak-copyleft-next.
Mike
On Fri, Jun 21, 2013 at 11:31:00PM -0400, Richard Fontana wrote:
This is a strange idea, but it is a kind of stronger copyleft than exists under MPL-like licenses.
I'm not sure I understand why you consider it "stronger". The main difference as I understand it from your description is that unlike in the MPL, where the copylefted files and non-copylefted files can be distributed in the same tarball, in your proposal, this is prohibited, and the files have to be distributed in two separate tarballs. Is that a correct rendering of your idea?
If so, what's the benefit you see flowing by requiring the files to be distributed separately?
Thanks,
- Ted
On Sat, Jun 22, 2013 at 10:41:21PM -0400, Theodore Ts'o wrote:
On Fri, Jun 21, 2013 at 11:31:00PM -0400, Richard Fontana wrote:
This is a strange idea, but it is a kind of stronger copyleft than exists under MPL-like licenses.
I'm not sure I understand why you consider it "stronger". The main difference as I understand it from your description is that unlike in the MPL, where the copylefted files and non-copylefted files can be distributed in the same tarball, in your proposal, this is prohibited, and the files have to be distributed in two separate tarballs. Is that a correct rendering of your idea?
First, I don't yet know exactly what I mean by separate distribution (although as I noted GPLv2 incorporates this idea that 'some kinds of things are different if distributed separately' -- something which I am responsible for deleting from GPLv3, because it seemed to me that many lawyers I was interacting with at the time found that clause confusing and unhelpful). But for simplicity let's assume it has to mean two separate tarballs.
That aside, what I am suggesting is not what has to be copyleft vs. what can be noncopyleft, but rather what has to be open source vs. what can be proprietary.
Still, you're right that, as I outlined it, the main difference with MPL is that MPL allows me to easily create a 'Larger Work' that consists of, say, some MPL files and some proprietary files, whereas in my proposal you'd need to engage in 'separate distribution' to distribute proprietary files bearing certain relationships to the copyleft-next files.
I believe the main reason I suggested 'separate distribution is an excuse' here is just that I thought what I was outlining was potentially unreasonable otherwise -- but because it would go *beyond* FSF-orthodoxy strong copyleft theory in some circumstances. Maybe that assumption is wrong though.
- RF
On Fri, Jun 21, 2013 at 8:31 PM, Richard Fontana fontana@sharpeleven.org wrote:
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).
Like Ted, I'm not sure this ends up being substantially/meaningfully stronger copyleft than MPL. It does impose a slightly larger engineering tax, I suppose, but still a pretty minor one.
Unless perhaps you mean that any resulting binaries must also be distributed separately?
That said, it would simplify things for packagers/license auditors, which is not nothing.
Luis
On Sun, Jun 23, 2013 at 05:17:03PM -0700, Luis Villa wrote:
Like Ted, I'm not sure this ends up being substantially/meaningfully stronger copyleft than MPL.
In practice, maybe it wouldn't. But one of the epiphanies I had was that GPL and MPL are not treated differently in practice, *in close-to-pure FLOSS distribution contexts*, except with respect to notions of license (in)compatibilities, where GPL gives well-meaning FLOSS developers and packagers socially-costly headaches and MPL is always a welcome surprise. So even if you're right that this wouldn't be substantially stronger copyleft than MPL, I ask whether the GPL is really stronger than MPL-in-most-situations in a meaningful sense.
Bradley's chiming in on this thread is relevant in this context. Some months after I left SFLC in 2008, SFLC published an influential document, "A Practical Guide to GPL Compliance". http://www.softwarefreedom.org/resources/2008/compliance-guide.html One of the side points in this document that resonated with me particularly, perhaps because I've also heard Bradley state it in his talks, is the one in this footnote: http://www.softwarefreedom.org/resources/2008/compliance-guide.html#fn3x0 :
"There has been much legal discussion regarding copyleft and derivative works. In practical reality, this issue is not relevant to the vast majority of companies distributing GPL’d software."
I think Bradley must have authored that footnote (and may have been the principal author of the _Guide_). It is, I still think after five years, one of the more subversive statements ever made in the legal history of free software, though I am probably misinterpreting it. :)
Indeed, I recall from at least one conversation with Bradley that I think he means that companies that are actually creating derivative works in any interesting sense are going to have the sophistication to steer clear of the FSF-orthodoxy boundaries of strong copyleft, so interesting derivative works questions do not tend to arise. I think he may also mean that what Bradley would call violators typically are not even creating derivative works in an interesting sense (this calls to mind Rob Landley's complaint that BusyBox GPL enforcement tended not to result in the disclosure of any valuable downstream enhancements), or else that the fundamental violations are significant enough without even getting to issues of derivative works implied by theories of strong copyleft scope.
That is kind of relevant here because the violations that Bradley has often talked about would also be present if MPL were the upstream license rather than GPL, particularly if MPL were to have included, as it does not, an explicit 'scripts to control compilation and installation of the executable' disclosure requirement. (I deliberately avoided the issue of what to do about binaries, but I have seen no need to relax that requirement, which is actually "stronger" if you will in copyleft-next than in GPLv2. MPL and EPL say nothing about providing extra information to facilitate building the source code that must be made available -- this is one of the things that distinguishes them from GPL and, arguably, LGPL.)
So, in fact, Bradley's complaint about the inadequacies of file-based copyleft is in conflict with that long-overlooked footnote 3 of the _Guide_. If interesting derivative works questions do not arise in the real world *except possibly for well-meaning FLOSS developers and distributors*, why is file-based copyleft so bad?
It does impose a slightly larger engineering tax, I suppose, but still a pretty minor one.
Unless perhaps you mean that any resulting binaries must also be distributed separately?
I'm looking at a piece of paper where I scribbled some thoughts on binary distribution... Yes (if this is what you mean), an idea I had there was that with object code distribution, it would be a license violation to distribute under a proprietary license anything corresponding to what would be within the weaker notion of copyleft scope in a pure-source distribution.
- RF
On Mon, Jun 24, 2013 at 11:46:33PM -0400, Richard Fontana wrote:
notions of license (in)compatibilities, where GPL gives well-meaning FLOSS developers and packagers socially-costly headaches and MPL is always a welcome surprise.
Well, unless MPL pre-2.0/GPL incompatibility issues are present, but I have not found that to be common given the past use of the tri-license in Mozilla Foundation projects.
- RF
On Mon, Jun 24, 2013 at 11:46:33PM -0400, Richard Fontana wrote:
In practice, maybe it wouldn't. But one of the epiphanies I had was that GPL and MPL are not treated differently in practice, *in close-to-pure FLOSS distribution contexts*, except with respect to notions of license (in)compatibilities, where GPL gives well-meaning FLOSS developers and packagers socially-costly headaches and MPL is always a welcome surprise. So even if you're right that this wouldn't be substantially stronger copyleft than MPL, I ask whether the GPL is really stronger than MPL-in-most-situations in a meaningful sense.
Bradley's chiming in on this thread is relevant in this context. Some months after I left SFLC in 2008, SFLC published an influential document, "A Practical Guide to GPL Compliance". http://www.softwarefreedom.org/resources/2008/compliance-guide.html One of the side points in this document that resonated with me particularly, perhaps because I've also heard Bradley state it in his talks, is the one in this footnote: http://www.softwarefreedom.org/resources/2008/compliance-guide.html#fn3x0
Actually, I think the more interesting footnote is footnote #1 in the same document:
One example is the public outcry over NeXT’s attempt to make the Objective-C front-end to GCC proprietary.
It may very well be the case that the bulk of the software enforcement has been about "stupid stuff" --- i.e., companies who just need to make sure they release the busybox sources, and to perhaps play games of "gotcha" with companeis who misdisigned their software packaging such that they are caught between the rock of the blue ray consortium and the hard place of the SFLC.
However, there is a much more controversial issue, and that has to do with the attempt to extend the GPL to situations such as what happened with NeXT's attempt to use a proprietary front-end parser for Object-C which then communicated to the back-end GCC code generator over a pipe. So the proprietary code and the GPL'ed code were in different processes and different address spaces. But the assertion was made that this was not "mere aggregation", and that logically they were part of the same program. Ultimately NeXT decided to open source the Objective-C front-end without this coming to a legal fight, but it's never been clear to me that the courts would decide that from the copyright law, what the difference would be between:
output_of_proprietary_program | gpled_sort_program"
and what NeXT computer was doing.
The assertion made by GPL activists is that the courts take the intention of the license drafters into account. Whether this would extend to interface copyrights and whether or not the GPL can infect across a pipe, or a RPC mechanism, etc., I suspect remains still an interesting legal question.
But I think this goes to the heart of your question of whether the GPL is stonger than file-based copyright. Today, someone could take a GPL'ed program, and rip out some GPL'ed functions, and create a new GPL functions which exported their functionality over an RPC layer. Now suppose the RPC server is ACL'ed so it only listens to processes running on the local CPU, and it is used by a proprietary program to call these GPL'ed functions.
This is essentially the same thing you could do with code under the LGPL, or under a file-based copyright, in terms of the practical effect. Would such an approach stand up in court as being compliant to the letter of the requirements of the GPL? I'm not a lawyer. OTOH, would it cause hundreds of slashdot kiddies to stand up and flame a company that tried to do that, and perhaps DDOS their servers? Quite possibly.
So regardless of whether from a legal perspective there might be any practical different, the social understanding of a file-based versus the GPL'ed so-called "strong copyleft" is quite strong.
Regards,
- Ted
On Mon, Jul 01, 2013 at 09:53:58AM -0400, Theodore Ts'o wrote:
But I think this goes to the heart of your question of whether the GPL is stonger than file-based copyright. Today, someone could take a GPL'ed program, and rip out some GPL'ed functions, and create a new GPL functions which exported their functionality over an RPC layer. Now suppose the RPC server is ACL'ed so it only listens to processes running on the local CPU, and it is used by a proprietary program to call these GPL'ed functions.
Sorry, for clarity, this should have read, "and create a new GPL'ed program"...
- Ted
This is essentially the same thing you could do with code under the LGPL, or under a file-based copyright, in terms of the practical effect. Would such an approach stand up in court as being compliant to the letter of the requirements of the GPL? I'm not a lawyer. OTOH, would it cause hundreds of slashdot kiddies to stand up and flame a company that tried to do that, and perhaps DDOS their servers? Quite possibly.
So regardless of whether from a legal perspective there might be any practical different, the social understanding of a file-based versus the GPL'ed so-called "strong copyleft" is quite strong.
Regards,
- Ted
On Mon, Jul 01, 2013 at 09:53:58AM -0400, Theodore Ts'o wrote:
Actually, I think the more interesting footnote is footnote #1 in the same document:
One example is the public outcry over NeXT’s attempt to make the Objective-C front-end to GCC proprietary.
I think about this one a lot. There appears to be little surviving documentation of this episode (some near-contemporary Usenet references are all I've ever found) but it forms a key part of the legendary history of the GPL and strong copyleft theory; the possibility that Steve Jobs called RMS directly (in some versions of the legend) makes it all the more colorful.
"Public outcry" is probably an exaggeration, with all respect to the authors of the footnote (probably specifically Bradley :).
- RF
On 06/22/2013 06:31 AM, Richard Fontana wrote:
This is a strange idea, but it is a kind of stronger copyleft than exists under MPL-like licenses.
If I may try to rephrase this. As a copyleft-next licensor, I'd say by the license: "This software is free software. You can count on its guarantees of freedom, no matter in what shape you receive it or from where. You can use it from or combine it with files under any open/free license, and open licenses alone. You can use it from Apache licensed or BSD files; and yeah, you can also take those separately and make them proprietary. Fine. But if you do the latter, you're not doing it in this project. And you're not doing it *with* this software or any part of it, together in some meaningful package."
I don't think this is the message sent by MPL. I think it is stronger.
Perhaps the paragraph above doesn't make sense as a license. I don't know. It makes sense to me, as project policy, as actual and/or intended practice. I've even had a few attempts to play with the license text for something like this. Thank you for considering this approach, personally I am very glad to see it.
copyleft-next@lists.fedorahosted.org
-
Engel Nyst -
Luis Villa -
Mike Linksvayer -
Richard Fontana -
Theodore Ts'o