On Sun, Jun 23, 2013 at 05:17:03PM -0700, Luis Villa wrote:
Like Ted, I'm not sure this ends up being
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".
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:
"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
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.