Package licenses: Contemplations and considerations

Community
122

No one claims that, if the 3rd party isn’t the one distributing the GPL extension.

Suppose a 2nd party (you) takes GPL code from a 1st party (me), and uses it to write a dynamically linked plug-in for a proprietary program by a 3rd party. Depending on the details, I (1st party) could argue that you (2nd party) are violating my GPL terms by distributing it in your plug-in (since nothing else grants you permission to re-distribute work derived from my code). I have no claim against the 3rd party, however, unless they bundle your extension with their program and distribute them together.

(And if you distribute a GPL plugin that you wrote entirely yourself, then you are being somewhat self-contradictory in your license terms and you probably should add a clarification, but it’s somewhat academic since as the copyright holder you are free to violate your own terms.)

PS. This is all very déjà vu for me … I remember seeing almost identical arguments back on Slashdot and similar forums nearly 30 years ago. And yet we still don’t see any major entity/corporation distributing proprietary software along with GPLed dynamic libraries. (Of course, you will find GPL violations by random individuals and tiny volunteer projects on a regular basis. But mostly those aren’t worth hiring lawyers over.)

123

I would not frame this mainly as “who is going to take whom to court?” The main issue is not litigation paranoia, but precise and portable license metadata.

Take the Linux kernel. A well-known, non-exotic open source example has the SPDX expression:

GPL-2.0-only WITH Linux-syscall-note

That already combines an OSI-approved license with an exception. It is not some artificial corner case; it is Linux. A REUSE-aware plugin can handle this mechanically: recognize GPL-2.0-only and Linux-syscall-note, copy the corresponding texts into LICENSES/, and emit the correct SPDX expression in headers or REUSE.toml.

Most Julia packages will of course use simple licenses such as MIT, BSD-3-Clause, Apache-2.0, MPL-2.0, GPL, or AGPL. But supporting SPDX expressions is still the right abstraction. It avoids hard-coding the false model “one project = one license = one root LICENSE file.”

A single root LICENSE file is often sufficient for humans in simple cases, but it is a weak carrier of metadata when code is copied, vendored, split out, generated, or audited. GitHub contributor graphs and repository history also do not necessarily travel with copied files. Per-file SPDX headers are much more robust.

PkgTemplates.jl itself illustrates the practical issue nicely. This is not meant as criticism; it is the normal GitHub workflow. The project history and contributor graph contain attribution information, but the individual files do not systematically carry that context. If code is copied, vendored, split out, or mirrored elsewhere, that GitHub-side context may be lost. REUSE-style per-file metadata is not legal paranoia; it is a simple way to make licensing and copyright information more portable.

So my scenario is not primarily “A sues B.” My scenario is: code moves, and the license and copyright information should remain clear. REUSE is a boring, machine-readable solution to that boring but real problem.

124

See also this long thread from last year (which you participated in) about the pros and cons of per-file copyright notices (in any format): Copyright and license of Julia packages - #19 by stevengj

125

Which con against having these headers survives “the tool does it for me”?

Also note that you can simply assign metadata on a per file or per naming-pattern level in a REUSE.toml? (see for example this template).

126

You have to learn and use yet another tool.

127

Not much to learn, if you already know how to use PkgTemplates.jl:

128

I’m pretty on board with REUSE! Not just because “code gets moved around and license information might be lost”, but also because e.g. the MIT license is not actually appropriate for non-code, e.g., the .md files or images in the documentation: those should be creative commons licensed (assuming your intent is comparable to MIT on the “code” side)

I also accept that adding REUSE is something that people only do either because they’re license nerds who are procrastinating a bit, or something that’s forced by regulation, i.e. funding / project manager / institutional requirements.

For Julia packages, the current state of things is that the package must have a “main” LICENSE. That license should cover as much as possible, if not all of the source code in the src directory.

Registration requires that this LICENSE is OSI approved.

You can do whatever licensing you want with REUSE on top of that. You should specify in your README how the “main” LICENSE interacts with the finer-grained individual licenses. Obviously, it’s up to you to make sure that your fine-grained licensing gives the registry permission to redistribute your package. Those fine-grained licenses probably should be OSI-certified, but we don’t check that, or anything else related to fine-grained licensing, in any automated way.

There’s a hypothetical world where the registration bot detects REUSE, skips the check for the main LICENSE files and instead checks that all files it wants to redistribute are under a license that permits that. Someone would have to implement and maintain the tooling around that. I’m not sure there’s going to be much appetite for that unless REUSE becomes much more popular / widely required than it is now.

As far as package generators go, I’m not sure how much value there is in duplicating functionality that is probably better covered by REUSE’s own tooling. You can simply run reuse after generating a project to adopt fine-grained licensing, if that’s what you want or need.

129

This is the default template for a ## Licensing section to README.md (you can point to your own template file, of course):

## Licensing

Copyright © {{{YEAR}}} {{{AUTHORS}}}

The source code in this project is licensed under `{{{PRIMARY_LICENSE}}}`. Documentation,
generated project metadata, and documentation assets may use separate license expressions.

This project follows the [REUSE specification](https://reuse.software/spec/) for copyright
and licensing information. The authoritative license texts are stored in `LICENSES/`.
Copyright and license information for individual files is provided via SPDX headers and,
where applicable, via `REUSE.toml`.

To verify compliance, run:

`reuse lint`

PRIMARY_LICENSE will most often be a single SPDX license. And I believe a switch to attempt setting up a single LICENSE file additionally, if that is wanted (and possible), might indeed be helpful.

Last I checked, REUSE’s own tooling did not set up headers for files, check and copy license texts according to a given license expression, write a REUSE.toml by itself, add headers to code templates (testing, benchmark, src), add a licensing section to README.md or integrate itself into the project’s CI? Those are boring tasks—let the tool do it for you.

130

Yes, we don’t see people attempting it. The flip side of that is that nobody got taken to court over it in 25 years of audio plugins.

Purists will also claim that you cannot distribute GPL code in the App Store, because you need to link system libraries. Guess what, it happens anyway.

131

When the copyright holder complains, it gets taken down.

If the copyright holder doesn’t complain, the license is moot. As I said above, you can easily find GPL violations in small-scale volunteer projects (typically due to simple misunderstanding) where no one bothers to enforce it. But there have been plenty of GPL enforcements against companies, and from what I’ve heard the company almost invariably gives in rather than taking it to court. (This has happened a few times in my own experience with FFTW.)

132

That’s from so long ago (2010) it may as well be prehistoric, and the issue was never really about linking against system libraries. It’s really that the store TOSes typically add restrictions that are in conflict with the GPL, but those restrictions have loosened (somewhat) over the years and GPL v3 explicitly addresses this point.