A bit OT: after seeing in UK credit at 3600% APR, I got that the idea of “unconscionable contract” is really relative..
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.
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.
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:
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:
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:
Quoting GPL FAQ:
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).
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.
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) 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.
You might find Chapter 3 on Copyright, Contract, and Licensing in Open Source 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.
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.
What do you mean here? PkgTemplates.jl currently has "MIT" as its default fallback and the Reuse plugin I mentioned, which allows 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?
No, absolutely not, please don’t put your ideas in my mouth. Just
-
raise awareness and provide a practical guidance for package authors about a few suggested licenses,
-
dispel misunderstandings about licenses for package users
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.
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.
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 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.
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.
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, for example.
No, and I’ve used REUSE myself. 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.
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 lintas that checks that everything is represented inLicenses/ - 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?
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?
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. 