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