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).