LGPL that covers network-distributed use cases/web applications?

Question

Yes, another license question. I know.

I quite like using LGPL to cover my libraries, as I really don't care what users do with the library; however, I do care about the users sharing any improvements they have with the public.

And I was under the assumption that if a user does use my library:

1. The rest of the code isn't affected by the License.
2. If a user "distributes" their code with a modified version of the library, they need to make the source of the modified library available.

However, I've been recently made aware that LGPL's "distribution" (or rather, v3 uses the language "convey" but same difference) only covers cases where the software built with the LGPL'd bits is distributed directly to the end user (whether it be a compiled application or a simple tarball), NOT necessarily a case where the LGPL'd bit is used to provide a service over the network.

And given that most of my (npm) libraries are really geared towards web applications, it would mean that the "hey please make your modifications available" bit really wouldn't apply to people who use one of my libraries in their web app, which kinda ruins the whole point I went with LGPL.

And obviously, yes, the AGPL covers this specific use case; however, as I've said above, I really don't care what the users do with this library (i.e. the rest of the code that imports this library). I don't care if they commercialize it, license the rest of the code in restrictive terms, whatever. I just want the improvements to the software to be available to everybody.

I've seen discussions on HN where people have expressed similar needs, and they've discussed a potential "ALGPL"-like license (i.e. LGPL, but also covers the web app use case); however, there was no specific recommendations about such a license.

So my question is, does there exist a license where you basically let people do whatever with the code that imports your library, with copyleft just for the library (and doesn't affect the rest of the code) and a requirement to make available the changes/source code to the modified library and the modified library only?

As far as I can tell, none of the "popular" open source licenses cover this, and I really haven't seen much discussion about such a license.

(On browsing choosealicense.com, I have found "Open Software License" and "European Union Public License" which do cover the "network use counts as distribution" bit; however, I'm not an expert at reading legalese - I've tried - and there really isn't much online discussion about these licenses so I'm not sure whether these are appropriate for my use case and don't contain any "surprises")

Answer 1

There isn't a particularly good solution. I would give up on trying to achieve a network copyleft effect in your case.

• The AGPL-3.0 lets you define additional permissions per section 7. Indeed, the LGPL-3.0 is implemented as a set of additional permissions for the GPL-3.0. In principle, you could take the LGPL-3.0 and rewrite it to extend the AGPL-3.0 instead.

  But despite the LGPL-3.0 being implemented as a GPL-3.0 exception, it is not widely perceived as such – it is generally treated as a standalone license. Using the LGPL exception for a different base license would confuse people, and there would not be any valid SPDX identifier to describe this resulting license.

  This combination might also fail to achieve your license objective. The GPL/AGPL/LGPL have a set of conditions that apply when conveying the software. The AGPL does not change the concept of conveyance, but instead adds separate conditions in section 13 relating to remote network interaction with a modified version. In a web backend context, the usual GPL/AGPL/LGPL conditions about conveyance will not trigger, and the LGPL exceptions will not modify the AGPL section 13 conditions.

• Instead, you would likely have to create a novel set of additional permissions per AGPL-3.0 section 7 that use the LGPL-3.0 approach but also relax the section 13 conditions.

  For reference, the LGPL-3.0 takes the approach of defining the new concept of “Minimal Corresponding Source” as opposed to the GPL-3.0 concept of “Corresponding Source”, then adds more liberal terms that only require the Minimal Corresponding Source but not the entire Corresponding Source to be provided when conveying the software.

  Similarly, it would be possible to add an exception that offers alternative terms to section 13 of the AGPL-3.0 so that only the Minimal Corresponding Source would have to be provided.

  However, no such widely-recognized exception currently exists. It would have to be a new development. We as software developers are not really qualified to do that and are prone to creating “crayon licenses” that might have problems that are not obvious to us. Such an exception should instead be crafted by a lawyer who has experience with open source licensing.

  In a comment, there was a mention of an AGPL-3.0 exception for the Genode OS Framework. I think this exception is not drafted properly because it only provides an LGPL-style effect that relates to conveyance, but it doesn't address section 13 of the AGPL.

• There are various other licenses that include a “weak network copyleft” effect. For example, the Cryptographic Autonomy License (CAL) has a built-in Combined Work Exception. This license and exception is OSI-approved and has an SPDX identifier. However, the license contains terms that add limitations on managing user data with a software that falls under this license. Such terms might go against your licensing goals. In any case, it's a niche license without an established community, so downstream developers might not be willing to take the risk of using software under such a license.

Such ecosystem concerns are worth considering. As one of your licensing goals, you have stated that you want a reciprocal effect so that modifications can be integrated into an upstream project. However, another licensing goal likely is to promote adoption of your software.

To some degree, these factors are at odds with each other: reciprocal/copyleft licenses are less attractive to downstream developers and limit use. Unusual licenses might act as a deterrent, since a downstream developer wouldn't be sure about what conditions a license would entail. In fact, you voiced similar concerns about the OSL and EUPL.

Thus, it can be reasonable to decide that even though you would like a network copyleft effect, a more permissive license that does not involve network copyleft might be better for your project.

From the Software Freedom perspective, one might consider which license choice maximizes software freedom for end users. Network copyleft is good for end user's Software Freedom. Unusual license choices would hinder downstream use of the software, so that the software in question would never make it to end users – who would then be deprived of Software Freedom as well. In pseudo-math, this relationship could be described as

total license freedom = freedom for end users × freedom for downstream developers

The total freedom will approach zero if either end user or downstream developer freedom approaches zero.

For me personally, this means that I don't consider copyleft licenses appropriate in every circumstance – more permissive licenses or even proprietary software might have a larger positive effect for end users.

Answer 2

You wrote: "I have found ... the "European Union Public License" which do cover the "network use counts as distribution"; however, I'm not an expert at reading legalese - I've tried - and there really isn't much online discussion about this license".

You will find information on the EC-owned site www.joinup.eu (looking for the "EUPL collection") and free legal support through the joinup contact form.

The EUPL works like the LGPL in the case of combined work, adding that communication to the public or providing remote access to software functionalities is a form of distribution, like in the AGPL. But the EUPL is “more copyleft” than the LGPL because the list of compatible licenses is specified (it is not in the LGPL and may include proprietary licenses). For the EUPL, in case a compatible license can be applied to a combined work, the compatible license will prevail, but this is “Should the Licensee’s obligations under the Compatible Licence conflict with their obligations under the EUPL” therefore obligations that are not in conflict, like the coverage of SaaS and the obligation to provide the source code are persistent.