Package licenses: Contemplations and considerations

Community
61

A bit of a follow-up on this discussion: I am pleased to see an increase in packages using “weak copyleft” licenses being used in the Julia community, eg EUPL and MPL (and these are just registered packages; a lot more unregistered packages are out there using these licenses.)

I think that it would be safe to recommend these licenses for scientific software as the default, especially for Julia. They are much more up to date than MIT, are weak copyleft (not “viral”), and have major players behind them.

62

My most recent experience with MPL is that it turns a discussion about if a project is derived work into a discussion about which specific files are derived work. Huge waste of time, if you ask me :sweat_smile:

63

Thank you for writing this up, and sharing the EUPL, I was not aware of this, and I am in fact inclined to start using this in all my projects! From reading the rest of the comments there appears to be some ambiguity surrounding relicensing. Where can I read more? If I e.g., want to relicense a larger project such as DynamicalSystems.jl is there anywhere I can get some information on what this means and whether it is achievable?

64

Depending on the particular licenses involved, it can get rather complex (e.g. requiring the assent of all other contributors). In most cases though, when going from a completely permissive license like MIT/2-clause BSD/Unlicense/WTFPL, to another license the process is simply:

  1. You update the license file
  2. The old code continues to be available under the old license
  3. The new code, and new releases, are available under the new license

This works because those permissive licenses place no limitations on sublicencing/what licenses the work may be incorporated in. One way of looking at it is that you create a new EUPL/etc. work and copy in a bunch of MIT/etc. licensed code — which is totally fine under those licenses.

When complexity does arise, it’s usually because the old license doesn’t allow for this, and so you need the assent of every copyright holder to essentially dual-license the existing codebase. This is simple when you’re the only author, but in a large project with many contributors, this can turn into a big hassle. This is also what complicates mixing work from different licenses.

Notably the EUPL adds an explicit license compatibility clause to simplify the process of combining works. For instance, you can create a combined work from an MPLv2/AGPL/GPL codebase and an EUPL codebase, and distribute the combined result as MPLv2/AGPL/GPL with the explicit blessing of the EUPL (no legal advice/speculation required). Some lawyers with the European Commission even went to the effort of creating a great big EUPL license compatibility table:

IANAL …but as modern licenses and legal traditions move towards common language, and thanks to the extensive writing on these topics by qualified jurists, I think I can state/repeat these things with a degree of confidence.

TLDR; Were you using MIT or another highly permissive license? Using a new license going forward is something you can just do.

65

I am impressed how much effort the EU put into documenting all these issues in relation to the EUPL. Hiring expert lawyers to answer the relevant questions and then making all that information public is a very nice move.

Also, if a legal question ends up in court within the EU (or countries that are its trade partners and want to be on its good side), I would assume that it has a high chance of working out as intended.

66

MPL is indeed a weak-copyleft, file-level licence. For EUPL-1.2, “weak copyleft” is only partly right: the official EUPL materials themselves use that language, but the better description is a moderately reciprocal / interoperable copyleft. Its baseline is share-alike for distributed derivatives; what softens the outcome is the compatibility mechanism, not the absence of copyleft at the core. “Not viral” is not really a legal category, and “more up to date than MIT” is rhetoric unless one specifies concrete features such as patent clauses or interoperability imo.

67

This is a rather interesting point, and my best understanding is that it really depends on your particular legal jurisdiction.

When “virality” is invoked, in the most severe form, you see the risk articulated that even dynamically linking to a GPL3 library means that your codebase must be released under GPL3. This is why you have license variations like this: GPL linking exception - Wikipedia.

It is this requirement in the FSF’s licenses (and a few other niche ones) that has frightened hobbyists and small business owners, and arguably caused damage to the open-source ecosystem (via the reputational damage to copyleft licences) than benefits.

Interestingly, this very requirement seems likely beyond the scope of what a license can require under EU law:

The EUPL puts this understanding of European copyright law in the license explicitly, and specifies the relevant jurisdiction and applicable law. This grounds interpretation in the EU legal framework.

Once again using this as a springboard to bloviate, I think you make the start of an interesting point :face_with_tongue:. It’s very much not the case that licenses and copyright law go out of date (just look at the ongoing influence of the Berne convention), but I do think one can construct a meaningful chronology of open-source licenses, as our collective understandings of what the spirit of open-source software is, and how it collides with reality evolved.

If I were to begin to draw a brief sketch, it might look something like this:

  • 60s and 70s: a small number of people freely sharing code, with little to no thought about copyright/licensing
  • 1980: US copyright law is amended to consider code a literary work, and thus a form of IP
  • Ad-hoc licensing/personal copyright becomes the norm
  • The value and importance of sharing is seen and articulated by a few notable individuals (such as RMS)
  • 1989: The first version of the GPL is published, introducing copyleft
    • Programmers find the GPL long and confusing
  • Late 1980s: The MIT license is developed, it’s wonderfully simple
    • Programmers like the simplicity and conciseness
  • Late 90s and early 00s: Open-source goes commercial
    • Companies don’t like the GPL
    • Companies find it easy to use permissively-licensed code (e.g. MIT)
  • As software IP develops, it becomes apparent that an open-source project involves copyright, patent rights, and trademarks
  • 1998: Mozilla introduces the MPL, which specifies the governing jurisdiction for license interpretation
  • 1999: The Apache Software Foundation (ASF) develops the Apache v1 license,
  • 2004: The ASF releases Apache v2 after finding that v1 left to many practical legal concerns unspecified. The second version specifies patent and trademark rights, clear rules around redistribution, modification, and notice.
  • With the rise of GitHub, corporate support, and confusion around the GPL, permissive licenses are on the rise
  • In various projects, it becomes clear that permissive licenses aren’t sufficient to ensure that people/companies building on open-source work keep the spirit of sharing alive
  • Cloud computing arrives, and heralds Software as a Service (SaaS)
  • It becomes apparent that even “strong copyleft” (e.g. GPL) licenses aren’t enough to actually keep the spirit of sharing alive when you can just share the results of running code, never the program itself
  • 2007: The Affero GPL (AGPL) v3 license is developed by the FSF, that “closes the SaaS loophole”
  • In the background, there is a continuing push to use more common language in the law
  • 2012: Mozilla updates the MPL to v2, aiming to simplify the language and structure of the license, include patent protections, and make it more interoperable
  • 2017: The European Commission introduces version 1.2 of the EUPL

…as I was writing this, I simultaneously realised that this was becoming somewhat long, and that I was leaving a lot out. Let’s stop here though, so I can get to my dinner :sweat_smile:

While most software licenses shouldn’t reasonably be called “out of date” (with a few notable exceptions, such as MPLv1 assuming particular distribution methods), I do think there are very distinct lessons that have been learned over the past ~35 years about what’s important in an open-source license, and how to best go about reconciling the principles with reality.

Taking note of these lessons is what’s allowed for the development of licenses like the MPLv2 and EUPLv1.2, which have managed to incorporate patent rights, redistribution, modification, notice, interoperability, and jurisdiction, all in a license that’s both shorter and clearer than the original GPL.

68

(Just a quick chime in from a lurker to say that this is a wonderfully informative chronology – thanks @tecosaur!)

69

My biggest question about the EUPL that I have not seen answered yet is, does the EUPL v1.2 apply to non-EU jusidictions (e.g. the USA)? The license says that for non-member states, Beligan law is applicable, but what happens in a United States court? I don’t really see a judge applying Belgian law in that case. Would a second, US-focused, EUPL-compatible license be required?

edit: see Section 15 of the EUPL

70

It would be really interesting to hear from somebody with actual legal qualifications here (i.e. not me), but as I understand it there are essentially two relevant details:

  • As sovereign jurisdictions, courts outside the EU can come to their own decision about how they want to handle a contractual dispute, and there’s no possible license that can supersede this
  • Cross-border agreements are pretty common in our world with international commerce, and in practice, it seems pretty standard for countries to respect each other’s legal frameworks. Nuance abounds.

Regarding the USA, from a quick skim, I was able to come across https://www.fjc.gov/sites/default/files/materials/04/Proof%20of%20Foreign%20Law-A%20Guide%20for%20Judges.pdf, and you might find III.B of some interest:

In some cases, parties to a contractual agreement specify that the law of a certain country or state governs the interpretation of the contract as well as related disputes. Generally, courts will enforce choice of law clauses in contracts so long as a party provides sufficient notice of its intent to rely on foreign law.

What’s nice about the jurisdiction being made explicit in this way is that it effectively means that (assuming the court that would hypothetically hear the case recognises choice of law), you have a single version/interpretation of the license.

By contrast, when the relevant jurisdiction is unspecified, you effectively have a different version of the license in each jurisdiction (see the confusion around viral licensing mentioned in my previous message).

71

I read the linked piece. It is interesting, but it is an archived 2015 EUPL-portal article arguing for an interoperability-friendly reading of the Software Directive, not a court judgment. Even its own language is cautious (“it seems”, “in most cases”). The Directive and SAS v WPL do support the view that interfaces / functionality / interoperability deserve narrower copyright control than some maximalist accounts assume, but that still falls short of a settled rule that static or dynamic linking never triggers copyleft under EU law. Recent German litigation suggests the matter is very much not closed.

Thanks, this is a much stronger formulation because it identifies concrete features rather than just calling later licenses “more up to date.” I still think, however, that one should separate those dimensions more carefully. MPL’s file-level copyleft is quite different from EUPL’s broader reciprocal baseline plus compatibility mechanism, and “viral / non-viral” remains too imprecise to be very useful. So yes, there is a meaningful chronology of lessons learned — but not a single objective upgrade path from MIT to MPL/EUPL.

72

Sure. Fundamentally, virality is neither an explicit component of the EU copyright framework, nor something that has been well-tested in high courts. I’ve seen the German case you linked, but my understanding is that this is still being actively litagated (I notice the court order linked by ifross is a preliminary injunction).

What we do at least have from the post I linked is an analysis of virality in the EU copyright framework, by a lawyer who has specific expertise in software copyright in the EU. I can’t speak for the background of other people in this discussion, but that’s a much stronger level of expertise than I can bring to bear on this topic.

That aside, the EUPL is clear that it does not try to claim a “viral” influence over works it interacts with. To me, the fact that cases like the German one you linked exist vindicates the decision of the EUPL authors to be clear about how it interacts with other works without reaching into legally untested waters. The MPL is similarly clear, just via a different mechanism — saying that a larger work can still be distributed under the terms of the non-MPL components.

It is in this way that I find the discussion of “virality” meaningful, because in avoiding this legal quagmire that the GPL falls into, I think the MPL and EUPL do a better job allowing open-source developers to share and work with each other (and companies), and in this way are better general-purpose open-source licenses.

73

I think this is mostly right, but the last step is too strong.

An express choice-of-law clause is certainly better than silence if one wants a defined interpretive framework, and it looks like US courts often do give effect to such clauses. But that still does not produce a single globally uniform “version” of the license in any robust sense. The forum court must still decide how to handle the clause, apply its own procedure, and work through any ambiguity in the chosen foreign law. So EUPL’s applicable-law clause is a real virtue, but not a silver bullet. It does not look like the EUPL is really battle-tested in the US, does it?

74

This sort of can of worms is what I attempted to flag when I said “nuance abounds” :wink:.

There is no single, simple, and correct interpretation for how any license will be treated, no matter how straightforward a license is or isn’t, or what it specifies.

The EUPL improves this situation in the way I articulated, but my earlier comments about sovereign courts and nuance still very much apply.

75

I understand the appeal of MPL and EUPL, and there are real arguments in their favor: European fit, clarity, multilingual validity, and interoperability. But declaring EUPL the better “general-purpose open-source license” overstates the case.

There are equally legitimate reasons to prefer a strong copyleft license that is more battle-tested and offers more robust reciprocity. That is not somehow less “open source” in spirit; it simply reflects different priorities.

So this looks more like a preference for a particular trade-off profile than a general conclusion others should adopt.

76

It should be noted that the actual ruling does not speak to virality either - the judgement is rather about the defendant not providing notice that an GPL2/AGPL3.0 licensed piece of software was included at all, as well as not providing a to customers clearly visible license text & source code of that GPL2/AGPL3.0 code.

For example, the Plaintiff’s license terms were not made available to the purchaser of the program via Azure, nor was a corresponding offer made. Furthermore, the machine-readable source code of the Plaintiff’s programs was not made available, nor was its availability at least offered in accordance with the license.

So the ruling isn’t as related to viral copyleft as that blogpost makes it sound, it’s rather about simply not meeting even the undisputed requirements by the AGPL license (which isn’t even contested by the defendant).

77

There I see:

linked to GPL-2.0-licensed libraries from the open-source provider via an #include command. The court considered this to be a “derivative work” and prohibited distributing such vulnerability tests unless they were licensed under GPL 2.0.

#include to me implies static linking. I think nobody seriously considers static linking doesn’t apply to GPL, i.e. wouldn’t mean derived work (why wouldn’t it? the court case only proves sloppiness, companies trying to do whatever, or intentionally see what they get away with). So that matter is actually “closed”?! But you’re right the dynamic linking case may not be closed matter, and it’s more interesting to me if any court case has decided on such, for GPL or AGPL, or any other license. Stallman would want that to apply too, if not the GPL falls apart (though he explicitly allows you to do whatever in private dynamic linking or static, just not convey/distribute in either case, without complying with the licenses).

It seems to me dynamic linking should also be derived work, or why not? It’s a technical detail, and I’m sure if I bundle say Microsoft Windows with my software, Microsoft will not be happy. I think it’s settled, I can’t bundle, and dynamically link, any proprietary software, so why wouldn’t it also apply to copyleft?

free to [..] use them privately, without ever releasing them. This applies to organizations (including companies), too

E.g. running software on your private server e.g. in a company is ok linking whatever to GPL (and even statically), but not for the AGPL, this “network loophole” is what it’s meant to close. It was explicitly made to do that, i.e. then argues implicitly, it’s not private work any more.

This view is what the intention of the GPL is, and also seems to be the most common view. It’s not the only view though.

78

Is it better? Even that is controversial; not better according to the FSF:

Rejection of Choice of Law Clauses

Some have asked us to address the difficulties of internationalization by including, or permitting the inclusion of, a choice of law provision. We maintain that this is the wrong approach. Free software licenses should not contain choice of law clauses, for both legal and pragmatic reasons. Choice of law clauses are creatures of contract, but the substantive rights granted by the GPL are defined under applicable local copyright law.

I didn’t fully read this journal (note though the PDF is in English not Czech as stated), since I don’t know or care too much if the GPL is a contract (in my country):

GPL - “Viral” License or “Viral” Contract

.. While in the United States GPL is considered by some a unilateral software license, pursuant to
many national regulations outside U.S., including those of Czech republic and
Slovakia, GPL is a contract. Such a fairly unimportant difference may lead to
interesting legal questions regarding validity and enforceability of GPL around the
globe.

79

It all depends on what the authors/contributors want from the license.

MIT/BSD is perfect if the answer is “nearly nothing”. But I am under the impression that most people want more, and choose the MIT/BSD out of habit, observed customs of the Julia ecosystem, or fear that anything stricter would restrict usage.

An unfortunate pattern with MIT-type licenses is a company taking the existing software (of which they may be the original authors) and continuing it as closed source (in the sense that updates will not be released openly). Much to the dismay of users and previous contributors, who nevertheless cannot do anything about it (other than maintain an open version in parallel, which the closed version can freely cherrypick updates from).

I am not sure that everyone is aware of this. Most people realize this after an MIT-licensed library they were using suddenly grows a “premium” version. MPL/EUPL are answers for this.

80

Yes, that’s the point of copyleft. But MPL is a pretty weak copyleft — you can combine MPL code with proprietary enhancements as long as you put the latter in separate files. So even the original MPL-covered files could theoretically become useless in a free fork because they are filled with calls to proprietary_foo(...) functions and data structures defined in separate files. That’s why the GPL is written as it is.

The EUPL has a compatibility clause that allows you to relicense under MPL or several other licenses (including GPL), which means that it effectively has the same loophole.

I’m not saying that this will often happen in practice — even with MIT-licensed code, there are often incentives favoring continued development of the free/open-source version, and MPL adds further incentives. Just that people should be aware of what their licenses do and do not do.