Package licenses: Contemplations and considerations

Err, you indeed can’t just ignore the differences between licenses. I thought that went without saying?

I thought we were trying to engage with the substantive meat of licenses regarding the manner in which they can be combined with other works. To me at least this is a more interesting topic than whether you can selectively pretend certain license provisions don’t exist.


Aside: I think it also warrants comment that you also can’t just add MIT code to any other repository without consideration, because as the license states — copyright notice & permission notice need to be preserved. You can’t even move MIT code to another MIT repository just like that, because of the need to preserve the notice of copyright/authorship.

I’d personally amend

Code from neither MPL or GPL can be contributed directly — without consideration — as MIT licensed code to an MIT licensed repository

to

Code cannot can be contributed directly — without consideration — to a repository

Yes, exactly. My guidance is to focus on copyrights first and licenses second. Understand that the legal default is that you cannot use others’ copyrighted things, that others cannot use your copyrighted things, and that basically everything is copyrighted. If you can track the copyrights, you can track the licenses.

All OSI-approved licenses grant those capabilities, but with conditions. Be sure you can satisfy those terms. And be extra-sure once you collect others’ contributions under those licenses.

Licenses from codebase A — even when integrated into codebase B — cannot and do not affect others’ copyrights or even the licenses with which they contributed their code. There’s no “spooky action at a distance,” not even with viral licenses. But depending upon the individual conditions on use of A and B, you may not be able to simultaneously comply with the licenses of both, making the resulting combination a potential copyright violation. Notoriously, one possible way to fix a copyright violation with a bad combination of GPL and proprietary code is to release the proprietary code as open source (could be GPL, could even be a more lax license).

If there’s any question of whether someone is able to satisfy those terms, reasonable people will shy away from it.

4 Likes

People regularly fail to satisfy the terms of the MIT license, but I don’t think that reasonable people should shy away from it as a result :man_shrugging:.

As I see it, the key here isn’t being afraid of licensing and copyright and running away from anything that won’t fit on a napkin, but rather engaging with these complexities thoughtfully. By better understanding the legal environment we operate in, we can make informed decisions and leverage the strengths of various licenses to enhance collaboration and innovation in the open-source community without being paralyzed by fear of legal missteps.

1 Like

Believe it or not, I got involved here because I wanted to dispel some fear and misinformation about the combinations of copyleft licenses with MIT.

At the same time, personally, I still don’t like looking at or contributing to code that’s substantially more restrictive than MIT because I like to author and license my own code under MIT and want to avoid any potential allegations of plagiarism.

4 Likes

What are we, as a community, trying to optimize for when we “choose” a particular license?

I once got interested in whether there were better licenses than MIT for academic code, but quickly got bogged down in the mess of competing (or seemingly competing) interpretations about what things actually meant. The conclusion I eventually reached was that, in a vacuum I’d probably use MPL, but not out of any real understanding of the implications - just because I like and trust Mozilla.

But I also like and trust both @tecosaur and @mbauman, so what do I do when there’s a disagreement?

It’s clear to me that I will never be willing to spend the time / energy required to actually understand the implications, that even experts disagree about some nuances. If I ever thought that my code was commercializable, I’d probably hire a lawyer. Given this, I feel like I personally am not in a position to optimize for anything other than “lowest cognitive overhead possible”, which in this community is obviously MIT.

If the community ever decided it would be a good idea to move to MPL or even GPL, I’d happily make the switch.

15 Likes

A quick quip from me: while I do like being trusted (and liked :heart_eyes:) I don’t think anybody should just take anyone’s word here (Matt’s, Keno’s, Sukera’s, or mine) on these matters. Rather, read the licenses themselves and the lawyers/legal texts cited in the discussion. That’s where the actual subject matter/expertise lies :slight_smile:

(I do recognise that reading all that stuff is a fair bit of effort potentially)

1 Like

The only fundamental disagreements I’ve had here are:

  • How and when license violations take place: it’s almost uniformly in distribution — not mere usage — in nearly all OSI-approved licenses (but watch out for AGPL and the like).
  • How combining copyleft code might possibly affect existing code licensed under MIT (or other permissive license): it doesn’t, as long as you don’t completely intermingle the codebases to the point that you can’t tell who wrote what, you are clear about how subsequent contributions are licensed, and you don’t blur the edges. If it does at all is a question of the particular license and local copyright law and in how it’s intermingled and distributed.
6 Likes

This is simply not practical. Much as I enjoy the fantasy of “do your own research”, there are too many things to know in the world, and not enough hours in the day. If I read two lawyers that have differing opinions, or hell, even if they have the same opinion, I have to trust that they know what they’re talking about.

Above, someone noted that different judges / jurisdictions might have different opinions - are you also asking that I start reading legal opinions from the relevant courts? Or minutes from legislative sessions where the relevant copyright regimes were laid out? Do I need RSS feeds set to inform me when a new opinion comes out that might change the doctrine?

Without going to law school and spending a decade or so at a patent law firm, I am unlikely to be in a substantially different place epistemologically. So I’m just as happy to not do all that work and trust you and Matt :laughing:

6 Likes

I find it quite ironic that you then list two things that I think I agree with :laughing:.

If anything, I think the “biggest disagreements” are framing and emphasis.

1 Like

Oh, I’m under no illusions around this (hence my addendum at the end). I just still don’t think I should be trusted on principle here :slight_smile:

There are also some really great succinct resources around this these days, one of which I linked in the original “some resources” section but that I’ll mention again:

…and then books etc. for those who want to waste spend even more time getting into the weeds, like myself :stuck_out_tongue:

2 Likes

Also the JLA licensing assistant from the EU! Built by actual lawyers!

1 Like

Yeah, that’s precisely it. Managing and understanding multiple licenses and combinations thereof — especially within a single repo — takes care. With Julia especially, it’s quite easy to grab some simple function you need from the ecosystem (or even future-Julia) and just plop it in.

If both repos are using the same license, then getting this right is as easy as adding that extra copyright notice — it’s almost like any other contribution from another author. You already have the rest of the license and know you (and your downstream users) are satisfying those terms.

But if you’re using some other license, then you’d additionally need to include the license itself and ensure you’re satisfying those terms, while simultaneously ensuring that the combination doesn’t make it more complicated for others to use or continue contributing. Doing this carefully is hard. Or you simply choose to forgo this possibility entirely.

4 Likes

This made me realize a potential problem with the MIT license, the condition:

License and copyright notice

i.e.

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

unlike for Boost (or Unlicense):

unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.

So for science, source-code distribution, not a problem, or until you compile a binary (and exclude the source).

I had been thinking previously why does Rust dual-license all code as MIT AND Apache 2.0. It seemed the latter is redundant, but I think it may be important for compiled code distribution.

When compiling Julia code you can fulfill the MIT condition, it just seems more tedious vs for other languages, given we have more (because smaller) packages, unless there are tools that help.

As I keep on peeking at articles about software copyright online, there are a few pages I’ve come across recently that I think might be of (some) general interest.

  1. The EUPL is currently a somewhat niche license (in terms of overall popularity, arguably it’s created by the largest institution to write a software license to date). Coming across How to use the EUPL | Joinup, I was interested to see this bit (under "Why did the European Commission create the EUPL):

    It is the default licence applied to all EC produced software (Decision C(2021) 8759) and is a licence that all national open software repositories connected to the Interoperable Europe Portal - in force as from April 11 2024 - must propose (Interoperable Europe Act, article 8.4)

    Given this, I suspect we’ll be seeing a fair bit more of it in the coming years.

  2. The REUSE licensing model makes an argument for per-file license information, even when not required

  3. A blog post linked from a REUSE FAQ that goes into depth on what’s a good way to add file-level copyright statements, and why. Some key points:

    • Even if attribution isn’t explicitly required by a license, it’s required by copyright law in many jurisdictions [no reference provided, but I’d like to see one]

    • As already mentioned in this thread, the attribution requirement of licenses should not be overlooked

      list the copyright holders and/or authors – especially in jurisdictions which recognise moral rights (e.g. most of EU) it is important to keep the names of authors, if they are listed

      I imagine along these lines there’s widespread casual MIT copyright violation across the Julia ecosystem where code has been copied without attribution :stuck_out_tongue:

    • Adding “all rights reserved” anywhere is a bad habit in some projects.

    • Regularly bumping the copyright years in all files of a project isn’t a great idea.

redacted.

It’s a really just a fundamental requirement in being able to do your bookkeeping — how else can you possibly know (or potentially prove) who was responsible for licensing the content to you in the first place, regardless of the license? It’s at the core of what I’ve been trying to communicate throughout this thread — it’s all about copyrights. And everything meaningful is copyrighted by default, even if it’s missing the © notice.

1 Like

What? No. The blog post you link is misinformed.

(Someone vandalized the first sentence of the Wikipedia page FTR.)

Yup, and this seems like a point worth repeating based on how much it’s overlooked in practice.

Hey, that’s this thread :wink: (plus a little sprinkling of patent rights).

Mmm, since 1989/2000 (Berne convention, US/final Buenos Aires signatory).

Really? It seems fairly well-reasoned to me, and justified by the Wikipedia article you link:

It indicates that the copyright holder reserves, or holds for their own use, all the rights provided by copyright law, such as distribution, performance, and creation of derivative works; that is, they have not waived any such right. Copyright law in most countries no longer requires such notices, but the phrase persists.

So, saying “all rights reserved” is at the very least:

  1. Redundant post-Berne
  2. Incompatible with open-source licensing*

To elaborate on (2), the licenses we’re discussing are all about waiving rights around “distribution, performance, and creation of derivative works” in particular ways. Having an open-source license and saying “all rights reserved” is thus at best confusing and obsolete, and at likely flat-out contradictory.

* The only OSI-approved license I’m aware of is that contains “all rights reserved” are the BSD licenses, which were written pre-US Berne. The Boost license FAQ expressly says “Do not include ‘All rights reserved’ anywhere.”.

I agree with (1), a copyright notice is likely unnecessary. I disagree with (2). “All rights reserved” doesn’t contradict with any license, it just asserts copyright. The same copyright which makes it possible to license something in the first place. There’s no contradiction: the holder of copyright reserves all rights for themselves, and, based on those rights, licenses the work for use/copying by others. That’s my interpretation, at least, IANAL.

FWIW, Golang includes the notice at the top of their source files, and I suppose they had time to run this by Google’s lawyers by now:

PS: IMO, it’s not good to rely on the Berne convention too much. It’s just international law.