Hello,
On 19-04-13 16:27, Richard Fontana wrote:
> Anyway, as I recall, I said to Mike that perhaps drafting
an
> Affero-ish variant of copyleft-next might produce insights
into how
> to draft what I've previously been thinking of as the
vanilla
> version. I have also previously and separately wondered
whether an
> Affero-ish copyleft-next ought to be MPL-like in its
approach to the
> copyleft boundary issue. This is all related to
suggestions, made at
> times by Michael Meeks and by Bradley Kuhn, that a "Lesser
AGPL" may
> be useful.
I'm not sure exactly where the boundaries are with either
GPL or LGPL
when dealing with web applications (which is where you'd
expect
developers to pick the AGPL), so I would certainly welcome
a license
where this is clearer.
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.
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).
How do you envision the boundaries of an AGPL or Lesser
AGPL variant
of copyleft-next?
[1] Some examples (though there are many more):
mediagoblin: https://gitorious.org/mediagoblin/mediagoblin/blobs/master/setup.py
musicbrainz: https://github.com/metabrainz/musicbrainz-server/blob/master/Makefile.PL
pump.io: https://github.com/e14n/pump.io/blob/master/package.json
[2] Embedded javascript examples:
mediagoblin: https://gitorious.org/mediagoblin/mediagoblin/trees/master/extlib
musicbrainz:
https://github.com/metabrainz/musicbrainz-server/tree/master/root/static/lib
pump.io: https://github.com/e14n/pump.io/tree/master/public/javascript/libs
(note there are solutions like bower and fanstatic which
avoid this, but they
don't seem to be very popular yet).