Do we still need weak copyleft? (was Re: Exceptions to copyleft-next)

[Daniel P. Berrangé]

On Tue, Jul 14, 2026 at 06:31:19PM -0700, Bradley M. Kühn wrote:
> First, to answer Ted's question from myself (Richard already answered
> from his perspective upthread): I was thinking of the whole class
> of weak copylefts from “very weak” to “somewhat weak” (i.e., MPL,
> EPL, LGPL, and the Classpath Exception² too).
> 
> Folks will be surprised to learn that these days — at least until we
> release copyleft-next 1.0 — LGPLv2.1 is my favorite copyleft license,
> for various reasons.  I like it more than GPLv[23] now. 🤭
> 
> Nevertheless, it's unclear to me about the library thing.  glibc
> needed LGPLv2.1 because there were *so many* libc implementations
> that there was no chance that anyone was going to use a GPLv2'd C
> library with so many other options available (which remained true for
> decades — the number of times libc has been reimplemented … 🤦 … but
> that's OT. 😀)
> 
> While there was a period of time when I was a paid representative of
> the FSF and avoided saying so publicly, (and Ted will probably like
> to learn this, as he and I debated this long ago when I
> worked for FSF): IMO, FSF *erred* (& continues to err) by insisting
> libreadline stay GPLvN-or-later rather than moving to
> LGPLv2.1-or-later after libedit caught up.
> 
> What I'm wondering, though, is, given what's happening in computing,
> as development cycles becoming shorter and shorter (for various
> reasons, including but not limited to LLM-gen-AI assistance),
> re-implementing an API from scratch is a lot easier than it once was.

LLMs re-implementing an project from scratch is a neat trick, but whether
that makes it any more useful to do in practice remains far from obvious.

A successful OSS project is about more than just the code. The expert
knowledge and relationships between the community of maintainers and
contributors is key, as well as all the other parts the go into the
operation of the project. Forking an OSS project is not something to be
taken lightly. While LLMs can make pulling a "clean room" trick easier,
I don't think that significantly alters the cost/benefi tradeoff when
considering forking a project. It strikes me that many people who try
the LLM clean room trick will just end up learning the hard way that
a successful project is about more than just the code.

IOW, I don't think the ability to more easily re-impl a project should
be a major factor in deciding licensing preferences.



I've created and maintained several C libraries under the LGPL, with
the rationale that I want them used as widely as possible. While I can
understand the POV that if I had made it GPL, it would encourage some
applications to be GPL too, I question how strong that effect would be
in practice.

By making the libs accessible to all apps via use of LGPL, we have
had usage from proprietary apps, and many of those app developers have
made significant contributions to the OSS library they depend on. That
IMHO has been a bigger net win for the project over the long term.


In terms of the broad changes in computing and software architectures,
the role for the LGPL (as written )looks to be increasingly squeezed.
I don't think that means weak copyleft is obsolete, just that the LGPL's
specific expression of weak copyleft is not an ideal fit anymore.


The use of traditional shared libraries appears an increasingly niche
concept. In modern computing (micro)services communicating over sockets
are everywhere, from low level OS components using DBus RPC APIs, to
high level apps using HTTP(S) REST APIs.

Where an application does link to a library, that library is increasingly
just a dumb stub to marshal data into RPC call. The "interesting" logic
is all in the server and you can use a strong GPL or AGPL license for
that part, as it has no impact on license choices for apps consuming it
as a client.


On the client side, if the project ships client libraries, is a weak
copyleft like the LGPL useful ? IMHO if you used GPL for the client
part, apps that don't want to be GPL-compatible will rewrite the
client RPC marshalling code in a license that suits them better. This
was generally pretty easy even without LLMs around. That could be an
argument for using the LGPL for the client part, so it remains copyleft
while removing the incentive for rewrites under a permissive license...

...except this then comes up against the new language ecosystems and
softare distribution mechanisms where static linking is back in
fashion. Most notably for Rust and Golang, most things gets static
linked and thus the application code can be said to be subject to
the LGPL terms. This rather defeats the supposed benefit of the
LGPL over the GPL for a library written in Rust/Golang.


Overall I would still have a preference for the entire of my code
bases to be copyleft (open to either weak or strong depending on
the context) rather permissive, but IMHO as written the GPL vs LGPL
distinction is less useful than it needs to be.

If starting my library projects again I might be inclined to make
use of something like the LGPL-3.0 linking exception, which explicitly
permits static linking without the app bcoming subject to the library
license, as a way to make it more viable in the Rust/Go-like ecosystems
where static linking is the norm.


As a more general conceptual point, given that they are the same family,
I have always found it awkward that the GPL and LGPL are completely
separate documents, especially given their huge length.

I don't know the history of why they were written this way, but for ease
of developer understanding, I would prefer to see one core text for the
strong copyleft license, and a standard concise exception that could be
applied to suit the "weak copyleft" scenario.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|