# Package licenses: Contemplations and considerations

**URL:** <https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922>\
**Category:** Community\
**Tags:** package\
**Created:** [August 7, 2024, 2:59pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922 "2024-08-07T14:59:29Z")\
**Posts on this page:** 20\
**Page:** 6

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [April 27, 2026, 12:35pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/101 "2026-04-27T12:35:50Z")

</div>

> [@Tamas\_Papp](#):
>
> This, of course, did not stop the flow papers passing forward. I still remember one of them, a student wanted to know if trading 100 euros for x euros was an [unconscionable contract](https://en.wikipedia.org/wiki/Unconscionability) for various values of x, and tried to find a threshold by sending multiple questions forward with various x’s, effectively applying [bisection](https://en.wikipedia.org/wiki/Bisection_method). I think the lecturer kindly asked him to stop way before his preferred `rtol`.

A bit OT: after seeing in UK credit at 3600% APR, I got that the idea of “unconscionable contract” is really relative..

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 27, 2026, 12:59pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/102 "2026-04-27T12:59:46Z")

</div>

Note that it is a legal term in German/Austrian law and related legal systems (eg Hungarian). The UK is a common law system, something completely different. Concepts don’t just carry over from one to another.

This is a good example of how difficult it is to interpret simple legal questions for people not trained in law, which means law for a particular country and subfield. As scientists/programmers, our only practical recourse is to rely people who have this kind of training and did the relevant work, like the FSF in the US or the experts consulted for the EUPL by the European Commission.

---

<div class="post-metadata">

**Author:** ![gwr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gwr/32/33632_2.png) [@gwr](https://discourse.julialang.org/u/gwr)\
**Post date:** [April 27, 2026, 6:45pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/103 "2026-04-27T18:45:40Z")

</div>

> [@Tamas\_Papp](#):
>
> Note that it is a legal term in German/Austrian law and related legal systems (eg Hungarian). The UK is a common law system, something completely different. Concepts don’t just carry over from one to another.

One small caveat: I think the “unconscionable contract” example should not be framed as a German/Austrian-law term that does not carry over to the UK/common-law world. “Unconscionability” is itself a recognized common-law contract doctrine, especially in US and Canadian law, and the UK has related equitable concepts. German law has partly analogous concepts such as _Sittenwidrigkeit_ and _Wucher_ under § 138 BGB, but those are not completely identical.

So I would put the point slightly differently: similar fairness-control ideas exist in several legal systems, but their legal tests, terminology, and consequences differ. For international contracts and licenses, the relevant questions are governing law, forum, mandatory rules, and actual enforceability under the applicable system. That is exactly why it is sensible to rely on established licenses and specialist legal work rather than inventing clever edge-case interpretations ourselves.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [April 27, 2026, 11:48pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/104 "2026-04-27T23:48:40Z")

</div>

> [@GeorgeGkountouras](#):
>
> > [@Palli](#):
> >
> > I’m sure if I bundle say Microsoft Windows with my software, Microsoft will not be happy. …
> 
> Windows is proprietary, not (A)GPL. Why would copyright law apply on copyleft licenses

You can _run_ (A)GPL software on Windows, or with any proprietary software just not bundle together, to distribute/convey (objected to by Microsoft, _and_ the GPL, or rather the GPL ok with it if you provide the source, at least with the written offer to provide it, it apply to others too).

It’s not even obvious you’re allowed to run GPL/copyleft on Windows, except since it’s allowed by the explicit “system library exception” (on the GPL side) that would apply to Window:

> **[Frequently Asked Questions about the GNU Licenses
- GNU Project - Free...](https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException)**
>
> “GPL” stands for “General Public License”. The most widespread such license is the GNU General Public License, or GNU GPL for short. This can be further shortened to “GPL”, when it is understood that the GNU GPL is the one intended.

Also the GPL doesn’t care what you do in private. Even on a free operating system, like Linux, it’s not clear you can run proprietary there, except because it was declared so by Linus Torvalds:

> **[LicenseDB: linux-syscall-exception-gpl](https://scancode-licensedb.aboutcode.org/linux-syscall-exception-gpl.html)**

If I made a proprietary software to run (only) on Linux, it wouldn’t be obvious it wouldn’t become derived software of the kernel, i.e. become GPL/copyleft itself. This is also dynamic linking. Yes, explicitly allowed allowed in Europe/EU (i.e. copyright doesn’t apply to interfaces, making derived work there), it seems to me, but not clear in the US.

See also:

> **[GPL linking exception](https://en.wikipedia.org/wiki/GPL_linking_exception)**
>
> A GPL linking exception modifies the GNU General Public License (GPL) in a way that enables software projects which provide library code to be "linked to" the programs that use them, without applying the full terms of the GPL to the using program. Linking is the technical process of connecting code in a library to the using code, to produce a single executable file. It is performed either at compile time or run-time in order to produce functional machine-readable code. The Free Software Foundatio...

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [April 29, 2026, 11:15am UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/105 "2026-04-29T11:15:45Z")

</div>

> [@GeorgeGkountouras](#):
>
> Still not clear though. What if you use a bundled GPL library to compute a numerical result. You can also provide a `return 0` shim that is not bound by the GPL. Technically it’s not a derivative work. Sure, it returns the wrong result, but there’s no law or license that says your math has to be correct!

Quoting [GPL FAQ](https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKernelLinux):

> The fact that the user is expected to put the pieces together does not really change anything.

IANAL, but in your hypothetical, there probably would be some discussion of whether your users are expected to provide the GPLed thing (expected by a hypothetical reasonable layman? By the understanding and behavior of your actual users? By yourself, as evidenced by your internal communications? Have fun sifting through years of internal emails, lol).

Dynamic linking is so difficult because it can fundamentally happen on behalf of the end-user. Adversarial compatibility is a thing. Don’t forget the fun case of e.g. game-mods that distribute code under a “we don’t care, lol”-unlicense , and that only work when dynamically linked against both a proprietary game and some GPLed library, against perceived commercial or ideological interests of both game and GPLed component rightsholders.

That being said, I absolutely would not take the GPL FAQ as a gospel on dynamic linking. The FSF is mostly composed of good people, but it very much has an institutional interest in strong interpretations of copyright and the GPL that at times run counter to software freedom (their “copyleft” approach of turning copyright against itself is structurally at odds with adversarial compatibility).

---

<div class="post-metadata">

**Author:** ![GeorgeGkountouras](https://avatars.discourse-cdn.com/v4/letter/g/77aa72/32.png) [@GeorgeGkountouras](https://discourse.julialang.org/u/GeorgeGkountouras)\
**Post date:** [April 29, 2026, 11:49am UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/106 "2026-04-29T11:49:34Z")

</div>

As you said, FAQs are not legal opinions. They amount to “a website said it”, which isn’t that useful in court.

Also not a lawyer, but in my reading it’s enough to have a big button on the GUI that says “load GPL parts”. It doesn’t matter if the dynamic library is bundled in the program, an optional download in the installer, or they have to ask you to mail them a floppy. The end-user is doing the loading and anyone with a GPL claim would need to take them to court, which won’t happen in practice.

There are also exceptions that apply specifically for compatibility. For example, normally you aren’t allowed to reverse engineer a binary.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [April 29, 2026, 12:13pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/107 "2026-04-29T12:13:49Z")

</div>

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

So, it’s hard for me to take seriously the armchair lawyering that confidently discounts the opinions (and decades of [enforcement experience](https://www.gnu.org/philosophy/enforcing-gpl.html)) of the FSF’s legal counsel for its own license as biased and “just a website”. No one thinking the GPL is easy to circumvent (just link differently! I’m sure a judge will agree!) has put their money on the line.

---

<div class="post-metadata">

**Author:** ![gwr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gwr/32/33632_2.png) [@gwr](https://discourse.julialang.org/u/gwr)\
**Post date:** [April 29, 2026, 12:14pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/108 "2026-04-29T12:14:39Z")

</div>

> [@gwr](#):
>
> [Amanda Brock, ed., _Open Source Law, Policy and Practice_, 2nd ed., OUP 2022](https://academic.oup.com/book/44727).

You might find Chapter 3 on [Copyright, Contract, and Licensing in Open Source](https://academic.oup.com/book/44727/chapter/378965548) by P McCoy Smith interesting, which addresses the linking question among other questions in a more recent, lawyer-like fashion.

TLDR; the question regarding dynamic linking is far from settled.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 29, 2026, 12:53pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/109 "2026-04-29T12:53:42Z")

</div>

> [@GeorgeGkountouras](#):
>
> in my reading it’s enough to have a big button on the GUI that says “load GPL parts”

For the purposes of this discussion, this is a red herring. For the Julia community, the relevant questions is whether to stick to MIT as a default for packages, or restrict it a bit.

As interesting these legal questions are, since AFAICT no one has the relevant expertise for answering them here, for practical purposes it would be great to focus on the use case of package authors.

---

<div class="post-metadata">

**Author:** ![gwr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gwr/32/33632_2.png) [@gwr](https://discourse.julialang.org/u/gwr)\
**Post date:** [April 29, 2026, 1:01pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/110 "2026-04-29T13:01:12Z")

</div>

> [@Tamas\_Papp](#):
>
> For the Julia community, the relevant questions is whether to stick to MIT as a default for packages, or restrict it a bit.

What do you mean here? `PkgTemplates.jl` currently has `"MIT"` as its default fallback and the [`Reuse plugin`](https://github.com/JuliaCI/PkgTemplates.jl/pull/528) I mentioned, which allows [SPDX License Expressions](https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/) for four different kinds of deliverables (e.g., primary code, coding artifacts, documentation, documentation assets), will have `"MIT"` as fallback for primary code (which is the default for all other deliverables), as well.

Should this be “dictated”, e.g., no registry entry if not licensed among a set of acceptable licenses?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 29, 2026, 1:03pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/111 "2026-04-29T13:03:34Z")

</div>

> [@gwr](#):
>
> Should this be “dictated”, e.g., no registry entry if not licensed among a set of acceptable licenses?

No, absolutely not, please don’t put your ideas in my mouth. Just

1. raise awareness and provide a practical guidance for package _authors_ about a few suggested licenses,

2. dispel misunderstandings about licenses for package _users_

---

<div class="post-metadata">

**Author:** ![GeorgeGkountouras](https://avatars.discourse-cdn.com/v4/letter/g/77aa72/32.png) [@GeorgeGkountouras](https://discourse.julialang.org/u/GeorgeGkountouras)\
**Post date:** [April 29, 2026, 1:44pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/113 "2026-04-29T13:44:57Z")

</div>

> [@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 about “nobody is doing it openly”. In my domain (audio plugins), dynamic libraries are the default mode of distribution. It’s definitely assumed that those will be linked to proprietary hosts, but like in the game-mods example, nobody puts much thought into it. Thus, there are plenty of GPL “products” in the wild. It would be absurd to turn a 3rd party proprietary program GPL because you released an extension to it.

You might say that it’s different when it’s a proprietary library using a GPL library, but that still gets us into “it’s not settled”, rather than any clear guidance.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [April 29, 2026, 2:04pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/114 "2026-04-29T14:04:59Z")

</div>

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 case is if:

- You violate some plugin author’s copyright
- And you’re unable to satisfy the conditional terms (e.g., of the GPL)

In your example, my sense is that the proprietary vendors _aren’t_ infringing on plugin author copyrights because they’re simply not modifying/copying/distributing/touching them at all. It’s just fine for a _third person_ to combine them, because they’ve been granted rights to _use_ both. They can’t, of course, redistribute the proprietary program at all.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [April 29, 2026, 2:48pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/115 "2026-04-29T14:48:27Z")

</div>

> [@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](https://opensource.org/licenses). This is a hard rule.

---

<div class="post-metadata">

**Author:** ![gwr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gwr/32/33632_2.png) [@gwr](https://discourse.julialang.org/u/gwr)\
**Post date:** [April 29, 2026, 2:53pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/116 "2026-04-29T14:53:50Z")

</div>

> [@goerz](#):
>
> Just for the record, that’s exactly the policy we have. All registered packages must have an [OSI approved license](https://opensource.org/licenses). 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 would still tend to just warn them and not prevent them from using any license they want.

In the plugin I just proposed, my main interest is to support “legal hygiene”, e.g., it should be completely clear which license goes with what file in a project. This may be simple and done for a single license (as is often the case), but it must not be so necessarily.

Giving a warning should be very easy, as the REUSE plugin reads the `.json` files from SPDX License List Data and thus this should be very easy to add as a warning.

---

<div class="post-metadata">

**Author:** ![gwr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gwr/32/33632_2.png) [@gwr](https://discourse.julialang.org/u/gwr)\
**Post date:** [April 29, 2026, 3:06pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/117 "2026-04-29T15:06:48Z")

</div>

> [@goerz](#):
>
> an [OSI approved license](https://opensource.org/licenses)

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.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [April 29, 2026, 3:12pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/118 "2026-04-29T15:12:32Z")

</div>

> [@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 JuliaRegistrator · Pull Request #149535 · JuliaRegistries/General · GitHub](https://github.com/JuliaRegistries/General/pull/149535), for example.

> [@gwr](#):
>
> Do you believe a project must have a _single_ license?

No, and [I’ve used REUSE myself](https://github.com/JuliaQuantumControl/GRAPE.jl). It’s perfectly fine for the source code and, e.g. documentation material to be under different licenses. The point is that the _code_ that the registry redistributes through the packaging servers must have an OSI license. 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.

We do allow for dual-licensing, and we don’t place any restrictions on additional licenses for parts of the repository unrelated to redistribution through the registry.

---

<div class="post-metadata">

**Author:** ![gwr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gwr/32/33632_2.png) [@gwr](https://discourse.julialang.org/u/gwr)\
**Post date:** [April 29, 2026, 3:18pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/119 "2026-04-29T15:18:39Z")

</div>

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

In the plugin, I will put raw downloads from SPDX into the `Licenses/` directory and one might then even check with hash codes, whether a license file was modified (no need for templating standard SPDX license texts according to REUSE FAQ).

In the more general case of REUSE, the check could be stronger:

- lint all files using `reuse lint` as that checks that everything is represented in `Licenses/`
- check all files in `Licenses/`

A simple `LICENSE` file might is only compatible (imho) with REUSE if it becomes a text note pointing to `LICENSES/`, or comparable to a `## Licensing` section in `README.md`?

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [April 29, 2026, 3:28pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/120 "2026-04-29T15:28:00Z")

</div>

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 for all the files that get packaged. These are two separate systems for licensing. It’s up to you to make sure that there is no conflict between the “main” license you present to the registrator, and whatever licenses you specify for the various files in your repo. We can’t really automate that check.

Having complicated license setups like that is extremely rare. And, people that use REUSE are probably using very open and OSI-approved licenses anyway, so there really shouldn’t be a problem. Maybe you can put yourself into some legal corners of self-contradiction if you make this sufficiently complicated. But what is your scenario for who is going to take who to court over any of this?

---

<div class="post-metadata">

**Author:** ![gwr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gwr/32/33632_2.png) [@gwr](https://discourse.julialang.org/u/gwr)\
**Post date:** [April 29, 2026, 3:33pm UTC](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922/121 "2026-04-29T15:33:26Z")

</div>

> [@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. I thought about this and figured that I do not make the plugin more complicated in the first step. But it could easily serve that purpose as well, e.g., figure out if your SPDX License Expression just has a single license and then copy (or sym link?) it in the main directory (e.g., `Project.toml` directory). And it could simply not do this if the expression is more complicated.

Flexibility is key.

The plugin very likely seems “over engineered” at first sight. But I figured, you either fully support REUSE setups or you do not. 🙂

[Previous page](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922.md?page=5)

[Next page](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922.md?page=7)