Why use the GPL over the LGPL on the web?

Overview

This library is released under version 3 of the GNU General Public License (GPL), with optional terms enabling usage in proprietary software. Compared to the GNU Lesser General Public License (LGPL), which is often used for libraries,

The strong copyleft of the GPL contributes to the sustainability of the work, in addition to keeping the library free and open-source.
The requirements of the GPL are simpler to understand and comply with in the context of front-end web development.
The technical realities of front-end development make the LGPL function similarly to the GPL anyway, as we'll see.

At first, the LGPL looks like a good choice to allow linking this library with proprietary software while keeping the library free and open-source ("copyleft for the library"). Permissive licenses such as BSD don't accomplish that. Upon deeper inspection, however, the requirements of the LGPL on the web turn out to be intricate. While the LGPL makes concessions to proprietary software developers, it does not map as naturally to the web as it does to desktop applications.

Requirements of the LGPL on the web

The requirements of the LGPL with respect to the modern web are technically nuanced. Section 4 of the license includes the "relinking requirement". It ensures that users have permission to use modified versions of the library in a combined work. Complying with this requirement of the LGPL is easy for free and open-source applications, but challenging for closed-source works:

Using tools such as Vite or Webpack to minify and bundle the library with proprietary applications (as in "static linking"), and then distributing those applications to others (browser delivery counts as distribution), is not permitted unless developers provide: (a) the source code of their applications, or an equivalent to linkable object files with complete build scripts as set out in Section 4d0; and (b) clear instructions for rebuilding and executing their applications with a modified version of the library as set out in Section 4e. We'll informally call the elements listed in the first item "linkable code", observing that the source code is also linkable code, and that the relinking instructions must accompany the linkable code.
Bundling the library with mobile apps based on WebViews, and then distributing those apps to others, is probably non-compliant unless their linkable code is made available. Mobile apps are cryptographically signed to prevent tampering. Thus, users cannot use modified versions of the library in such closed-source mobile apps without the cooperation of the developers. This is a variant of "tivoization" implemented in software. Moreover, developers cannot be expected to implement a custom mechanism just to dynamically load the library, as this task would be unrealistic and likely unrelated to their creative work. Furthermore, such custom mechanism may be unreliable and insufficient for compliance.
While inclusion by reference in a web page (as in "dynamic linking") may be compliant by the letter (that is, if you also comply with the other requirements of Section 4), just doing so, without sharing the linkable code, does not necessarily align with the spirit of free software because the meaningful exercise of the relinking permission presents technological barriers. There are significant technological and usability issues that make the relinking permission unrealistic, effectively removing it:
- Security policies of web browsers come into play, disallowing the modification of the library at runtime. Modified versions of the library will usually not operate properly, as required in Section 4d1 of the LGPL. Without access to the linkable code, users cannot use modified versions of the library in a combined work, except by means of specialized development tools.
- In addition, you must provide "Installation Information" as required in Section 4e of the LGPL, and as defined in Section 6 of the GPL (which the LGPL version 3 incorporates). Such information must include complete methods, procedures and keys for using modified versions of the library in the combined work. Furthermore, such information must suffice to ensure that the continued functioning of the modified object code is not prevented or interfered with solely because a modification has been made. Web browsers normally disallow such modifications at runtime due to security constraints.
- In the context of mobile AR (for instance, a user is in a museum holding a phone), the necessary steps are impractical. For example, on Android, this typically involves enabling developer mode, adb, debugging tools, and more, or third-party tools such as browser extensions or proxies. While skilled users can theoretically employ such methods, they are cumbersome and of little or no practical use in mobile AR.
- Even when loading the library externally, the necessity to provide Installation Information creates a compliance nightmare if the linkable code is not available. Our audience is mostly composed of artists and developers, and they are often not security hackers. And yet, it would be up to them to distribute a "hacker's manual" with instructions, while ensuring that those instructions are correct and can be reliably implemented with their applications across various platforms.
- The required steps are unrealistic for practical purposes, unless the linkable code is made available for self-hosting. A relinking permission not realistically exercised is merely theoretical. The problem is not one of dynamic linking per se, but rather one of relinking ability.
Applications need to be distributed under terms that: (a) allow user modification of the portions of the library contained in the application; and (b) allow reverse engineering for debugging such modifications. For proprietary software, this requirement can be addressed with a carve-out.

Unless the linkable code of the application is made available for self-hosting, exercising the right to use a modified version of the library with that application is impracticable. The technical requirements of the LGPL on the front-end are a lot more intricate than in desktop applications, where users can easily swap a shared library (.dll, .so, .dylib). If we want to grant users this permission, and if we want it to be exercised in a realistic way, then the linkable code of the application should be made available, and users should be able to self-host that application. Moreover, if self-hosting is desirable, then the availability of the entire source code is also desirable, because this is both more useful and more usual than just the availability of "linkable" JavaScript parts. Furthermore, if the source code is available, then users should also have permission to modify it. The GPL asserts that.

As mentioned before, compliance is easy for free and open-source applications. Example: if you distribute your application, and all its parts, under version 3 of the GPL, then you are compliant.

In a nutshell, version 3 of the LGPL supplements version 3 of the GPL with additional permissions. Meaningful exercise of those permissions on the front-end requires the linkable code of the application, because the relinking requirement does not map as naturally to the web as it does to desktop applications. Thus, we need a different approach. It turns out that we can supplement the GPL with different additional permissions.

Solutions for proprietary apps

If we want to allow this library to be linked to proprietary applications, then we should not require that users must be able to use modified versions of the library with those applications, because the relinking requirement prevents common use cases of the modern web (e.g., using bundlers and embedding the library in mobile apps, as explained above), and because exercising this right without access to the linkable code of those applications is unrealistic in our context. In addition, the relinking permission is not as useful as a more comprehensive permission covering the entire application, because the interactive 3D content belongs to the application, not to the library.

In order to allow linking to proprietary applications while keeping the library free and open-source, we can't use a permissive license such as BSD, for it lacks copyleft. We also don't need to use the LGPL. We can instead allow such linking in a more straightforward manner, like supplementing either the LGPL or the GPL with a special exception. Between these two licenses, the GPL asserts sharper boundaries and more permissions to end-users downstream (implying more requirements to developers). Moreover, here we can also address another issue, common in free and open-source software circles: sustainability. One way of funding free software is called selling exceptions.

Experience shows that monetizing proprietary and commercial use proves vital to the sustainability of this work. This can be accomplished with the GPL and its strong copyleft, which set clearer expectations than the LGPL does in our context (meaning: simpler to understand and comply with). Combining a GPL-licensed library with a proprietary work, and then distributing that combined work under a proprietary license, is not permitted — unless the copyright holders of the library allow such proprietary use by offering it under different terms in addition to the GPL. In this manner,

a) users who develop proprietary software help to fund the library and pay for an unencumbered, proprietary-friendly edition of it; and
b) users who develop free software help to spread the library and can use it free of charge under the GPL.

Supplementing the LGPL with a linking exception was also considered, but not implemented. If the exception was gratis, then we could address the compliance boundaries and requirements of the LGPL, but not the funding (permissive-ish model). If it was paid, then we could address the funding to an extent, but not the compliance boundaries and requirements for gratis users. If it was partly gratis and partly paid, then it was thought not to work any better than the GPL does. Other funding models were also considered, but not adopted at the time. Since any work licensed under version 3 of the LGPL can also be modified and propagated under the terms of version 3 of the GPL, this too indicates the same solution: release the library under the GPL.

At the end of the day, the chosen licensing model based on the GPL enables both free and proprietary usage, clarifies compliance, creates a channel for funding this work, and keeps the library free and open-source ("copyleft for the library").