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