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.

133

This relevant video was just posted by Louis Rossman: https://www.youtube.com/watch?v=jIbpQtoz6hs

Citing the summary from the consumer rights wiki here:

Cease and desist against the OrcaSlicer-bambulab re-enablement project

In April 2026, Bambu Lab sent a cease and desist communication to the developer of a third-party OrcaSlicer fork that had restored direct printer control after the Authorization Control System rollout. The project was wiped from public view the same day it appeared, and the developer published a summary of Bambu Lab’s allegations but not the letter itself, citing Bambu Lab’s refusal to authorize publication.[26]

What OrcaSlicer is

OrcaSlicer is a free, open-source slicer: a program that converts a 3D model file into the layer-by-layer instructions (G-code) a 3D printer needs to produce the physical object. It is maintained by the developer SoftFever and draws from Bambu Lab’s Bambu Studio, which is itself a fork of Prusa Research’s PrusaSlicer.[27] OrcaSlicer is widely used by owners of Bambu Lab printers as an alternative to Bambu Studio.[27][28]

What changed in January 2025

The Authorization Control System announced on January 16, 2025 gated print initiation, motion control, fan and hotend temperature control, AMS configuration, calibrations, remote video, and firmware upgrade behind a Bambu-issued authentication path. Owners who installed the new firmware could no longer send print jobs from third-party slicers directly over the local network; they had to route those jobs through a new closed-source middleware, Bambu Connect.[2] SoftFever was not given API keys for Bambu Connect and stated publicly that direct print sending from OrcaSlicer would not be supported going forward.[21]

The OrcaSlicer-bambulab fork

On April 23, 2026, the developer Pawel Jarczak (GitHub user jarczakpawel) made public a fork named OrcaSlicer-bambulab at github.com/jarczakpawel/OrcaSlicer-bambulab. The fork restored the ability to send print jobs from OrcaSlicer directly to Bambu Lab printers without routing through Bambu Connect.[28] According to Jarczak’s own description, the fork worked by reaching the printer through a Linux-side workflow Bambu Lab had not yet disabled, and was built on publicly available Bambu Studio source code combined with the developer’s own integration layer; it did not redistribute Bambu Lab’s proprietary networking plugin binaries.[26][29]

The cease and desist

Bambu Lab contacted Jarczak directly and demanded removal of the fork. According to Jarczak’s own first-person account, Bambu Lab “referred to legal materials and stated that a cease and desist letter had been prepared”, and alleged that the implementation “impersonated Bambu Studio, bypassed their authorization controls, violated their Terms of Use, involved ‘reverse engineering’, and could allow modified forks to send arbitrary commands to printers.”[26] Jarczak rejected the reverse-engineering characterization, stating that his work was based on publicly available Bambu Studio source code, which Bambu Lab releases under the AGPL-3.0 license.[26][29] Jarczak disputed the broader characterization and asked for specifics: the exact files or commits at issue, and the exact legal or contractual basis. He reports receiving “further broad accusations” instead of that specificity.[26] Bambu Lab refused consent for publication of the correspondence itself, and Jarczak elected to honor that refusal while retaining the letter.[26] The repository was wiped the same day it appeared.[26][28] Jarczak removed the contents voluntarily and stated this was a practical decision, not an admission that the legal or technical allegations were correct.[26] XDA Developers reported that Bambu Lab had not responded to its request for comment as of publication.[28] 3Druck independently confirmed the same set of allegations, citing Jarczak’s GitHub statement.[29]

The publicly documented allegations track Bambu Lab’s Terms of Service and an “authorization bypass” framing.[1][26] Because the letter itself was not made public, no primary source confirms which specific statute, if any, Bambu Lab invoked; neither Jarczak’s account nor the secondary reporting names a specific statute, including the DMCA §1201 anti-circumvention provision, as part of Bambu Lab’s claim. The upstream OrcaSlicer maintainer SoftFever was not named in the cease and desist, has issued no public statement on the fork or the letter, and the upstream repository remains active.[27]

Consumer-rights significance

Bambu Lab printer owners had paid for hardware that, at the time of purchase, allowed third-party slicers to send print jobs directly over their own local network. The January 2025 firmware update removed that capability for owners who installed the update.[2] When an independent developer rebuilt the lost capability on top of source code Bambu Lab itself publishes, the company’s response was a private legal threat rather than a technical or contractual remedy that the affected owners could read or contest.[26] The developer took the project down and stated he had “no interest in maintaining a prolonged dispute”.[2