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

Theodore Tso tytso at mit.edu
Wed Jul 15 14:28:44 UTC 2026


On Tue, Jul 14, 2026 at 06:31:19PM -0500, Bradley M. Kühn wrote:
> 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):

It wasn't just you; I remember having this debate with Jeremy Allison,
for example.

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

As far as I'm concerned, FSF had every right to decide whether or not
libreadline was under GPL or LGPL.  One could argue that libreadline
had many more features than libedit and libeditline and so it was
deserving of GPL protection lest proprietary software could take
advantage of it.

What I objected to do with the FSF argument that the GPL infected
across shared library links, which made aboslutely no sense vis-a-vis
U.S. copyright law.  The argument seemed to be that as long as the GPL
and proprietary code was in the same address space copyright would
apply, even though no distribution was happening at that point.  (At
which point I would start asking whether GPL and proprietary code in
the same physical memory would also be a GPL violation, or the same
local area network, or in the same globally connected Internet, etc.)

> 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. 😀)
> 
> However, Ted does raise an interesting point: can anyone think of an
> example of a project that uses the LGPL in the way that I describe?
> 🤔 Maybe it's an exception to my “no weak copyleft” rule?

I don't think it's a just matter of whether a libary is reimplemented
with multiply different licenses, whether it's weak copyleft, strong
copyleft, or permissive.  It's also about whether we think there are
people who release libraries where they want that library to be *used*
regardless of whether it is proprietary or FOSS, but they want
improvements to the library to be contributed back the upstream
version of that library.  For example, this is why I made the
conscious choice to license libext2fs under the LGPL.

If you believe that clean room reimplementation means that the license
of libraries to matter much less, then the library case might be much
less interesting.

(There are multiple questions that this begs, such as whether the use
of LLM's as a copyright stripper counts as clean room, and whether you
need to reimplement *all* of the library, or just the subset of the
functionality that is needed by the program in question etc.  I'd also
add the related question if a human takes a code snippet from Stack
Overflow, and rename variables, and it's for something super basic,
such as say, an insertion sort, is copyright implicated, and does it
make a difference whether a human or a LLM does that adaption?)

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

If the library is really easy to reimplement, sure, copyright matters
a lot less.  While the vast majority of the abandonware on sourceforge
or github, and maybe a large part of CPAN or PyPI are pretty
simplisitic.  But I would argue that complex libraries do still exist
and that's precisely where a library author might want to strongly
encourage that improvements be contributed back and merged, and this
would become a virtuous circle making it even harder to be
reimplemented.

And in the case where that complex library is an interface to an
implementation which is changing over time (for example, when we add
new features to the ext4 file system, the libext2fs implementation
will be changed to match), and a reimplementation of that
functionality (for example in Grub) will be left behind, and it causes
problems for Grub users.

(It doesn't help that when I go out of my way to send patches to Grub
in one case it took almost **two years** before that change made it
out into a release and into distributions.  This is where if Grub used
a standard library, all a distro would need to do is to recompile Grub
and users would be good.  This is a case where the license
incompatibility between GPL 3 and LGPL 2 really bit users in the *ss.
Oh, well...)

> Finally, yes, I know that for-profit companies love non-copylefted
> code.  So what?  We've been kowtowing to "oh, Big Tech, please
> adopt our software and fund it!" for decades.  What has it gotten
> us?  A bunch of underfunded maintainers, and a precious few who
> are well funded but hopelessly overworked.

This is a real problem, but I'd argue the probleem exists for
copylefted code as well.  There are a number of GPL'ed code bases
(coreutils, emacs, etc) that are arguably underfunded.  The license
may not be the strong determinant about whether companies will fund
FOSS project or not, or whether there will be plenty of community
contributions.

In the cases where enthusiastic GPL enforcement via lawsuits has
spawed reimplemented software such as in Busybox and Toybox, one could
argue that a stronger copyleft, whether it by the license text or how
aggressively people decide to use lawsuits or not, the question of how
trivial it is to reimplement a software project such as Busybox is
probably far more determinative.  And has the stronger copyleft
enforcement really improved the number of contributions to Busybox?

						- Ted


More information about the next mailing list