An idea

[Richard Fontana]

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

[Mike Linksvayer]

On Fri, Jun 21, 2013 at 8:31 PM, Richard Fontana
<fontana(a)sharpeleven.org&gt; 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

[Theodore Ts'o]

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

[Richard Fontana]

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

[Luis Villa]

On Fri, Jun 21, 2013 at 8:31 PM, Richard Fontana
<fontana(a)sharpeleven.org&gt; 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

[Richard Fontana]

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

[Richard Fontana]

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

[Theodore Ts'o]

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

[Theodore Ts'o]

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

[Richard Fontana]

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

[Engel Nyst]

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.