I’ve recently been giving more thoughts to the way I license my packages. While I don’t anticipate the choice becoming practically significant any times soon, I’ve realised that the topic probably deserves more consideration that I’ve previously given it. Why we need to think about licenses While m…

[image] stevengj: People have speculated about ways to get around the GPL with dynamic linking for decades now — none of the arguments here are new. And yet no one actually seems to be doing it in an actual product shipped with GPLed libraries (or if they are, it is well hidden). I don’t know…

Your focus here seems a bit sideways to me. The most important part isn’t the linking or whatever technology is used, really. The crux of any license is that it allows you to do something that would otherwise be a copyright violation. So the only time you could get in hot water in such a plugin c…

[image] gwr: no registry entry if not licensed among a set of acceptable licenses? Just for the record, that’s exactly the policy we have. All registered packages must have an OSI approved license . This is a hard rule.

[image] goerz: Just for the record, that’s exactly the policy we have. All registered packages must have an OSI approved license . This is a hard rule. That’s helpful, thank you. So, regarding tooling support, the author should probably receive a warning if non approved licenses are used? I wo…

[image] goerz: an OSI approved license That does need clarification: Do you believe a project must have a single license? To me this should be more general and thus plural where each license used has to satisfy the OSI approvement condition.

[image] gwr: So, regarding tooling support, the author should probably receive a warning if non approved licenses are used? The registration PR will be blocked by the bot with the message “Found no OSI-approved licenses”. This will play out like in New package: Gedai v0.1.0 by JuliaRegistrato…

[image] goerz: What the bot looks for is a LICENSE file (or maybe some other variations of the file name) in the same folder as the main Project.toml (the root of the repository, most of the time). This is a separate requirement from anything you might need for REUSE. That is maybe weaker. I…

REUSE does not use the LICENSE file in the repo root at all. GitHub does, in its UI (and ignores the REUSE stuff), and the Julia Registrator does. The Registrator assumes that what’s in the main LICENSE file is the license you are giving to the Julia General registry and its distribution mechanisms …

[image] goerz: REUSE does not use the LICENSE file in the repo root at all. GitHub does, in its UI (and ignores the REUSE stuff), and the Julia Registrator does. All I am saying is that it could be done a bit more sophisticated (even on GitHub). REUSE is agnostic with regard to a LICENSE file…

[image] GeorgeGkountouras: It would be absurd to turn a 3rd party proprietary program GPL because you released an extension to it. 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…

Package licenses: Contemplations and considerations

Community

stevengj April 29, 2026, 4:28pm 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

Topic		Replies	Views
Copyright and license of Julia packages General Usage question	37	1236	July 18, 2025
How are the intellectual property rights of Julia package developers protected? Community package	30	2083	March 16, 2024
GPL and virality Community faq , licenses , legal , gpl	39	9258	December 20, 2017
ModelingToolkit V11 Library Split and Licensing, Community Feedback Requested Community community , sciml , modelingtoolkit	131	4579	February 25, 2026
Is JULIA suitable for the development of proprietary derived-softwares? General Usage	31	5912	December 29, 2017

Package licenses: Contemplations and considerations

Related topics