Dealing with license changes

[nomaed]

Companies often require to go through "licensing committee" to get an approval to use any 3rd party tool, for any need. That also includes any update to existing 3rd party code.
The reason that updates need to be re-evaluated is because licenses can sometimes change between versions.

I was trying to find whether there is information about license changes and semantic versioning but couldn't find anything.

So my question is this: Is it safe to assume that if only the Patch revision has been updated, the license should remain the same, since otherwise this can be considered a breaking change, even if not for the API?

Or, from the other side, if I want to update the license of a package I'm maintaining, if the new license is not 100% compatible with the old one, should I bump the Minor (or even Major) instead of Patch version number?

Thanks.

[floeschie]

I'm interested in this as well. I would like to change from dual licensing (GPL3+EULA) to LGPL, and I wonder if I can do this in a patch release.

[haacked]

Very interesting question!

One of the key goals of SemVer is to communicate the risk of changes to a package/library's API surface. A license change doesn't necessarily affect that. But it could change whether a consumer of the package should update or not.

I tend to lean towards the idea that if you change something so fundamental as the license, that you should consider the new thing a new package/library and avoid any version changes.

For example, suppose I've released the amazing "frobnicator 1.0.0" package on NPM. And in the next release, I change the license from MIT to GPL. In that case, I'd suggest that frobnicator 1.0.0 is the last release of frobnicator and I'd add a new "frobnicator-gpl" library.

I feel like this ties neatly into the idea that you can't retroactively revoke an OSS license. So frobnicator 1.0.0 will forever be available under the MIT license, but this new package line will from then on be GPL.

I am curious to hear what others think.

[shmuelie]

My gut instinct says major version change since it is, in a way breaking. But why not ask @migueldeicaza how they handled changing Mono licenses?

[haacked]

I think the reason you might want to change the major version is to prevent people accidentally upgrading to the latest version without understanding the extent of the change.

But if you think about it, a package identity should consist of three orthogonal things: license, version, and name. So I'd argue it's incumbent on package managers to handle this. The license changing is orthogonal to whether or not the API changes. I proposed a name change because I don't think most package managers handle license changes in a structured manner.

Imagine this scenario, you see that "frobnosticator" has a new release that goes from 1.0.0 to 2.0.0 because of the license change, but the API changes are only patch level changes. That last bit of information is pretty much lost by the version change.

Instead, perhaps we need to solidify the idea of a package identity. That could even be its own spec, where the semantic version is one part of it.

[LukeWinikates]

I think a new package would be the most respectful course of action, since that would prompt users to reexamine the dependency with great scrutiny.

I kind of think major version should be good enough in theory, but I'd be concerned that something so subtle would get overlooked, even if folks did start thinking of it as part of SemVer.

If there was a strong cross-package manager standard about documenting licenses, that might also be a big deal for surfacing license changes. I often have to manually research the licenses for projects, and then manually record them in LicenseFinder. It occasionally crosses my mind that if the license ever did change, there's not really a way I'd find out.

[tshak]

Very good question. This point resonates with me:

The license changing is orthogonal to whether or not the API changes.

The goal is to prevent the unintended acceptance of a new license. While a major version change may require a manual update, the developer still won't be notified that the license changed.

Ideally a package manager should maintain structured license information in the package metadata and prompt the developer when the license changes. Creating a new package and obsoleting the existing package is also a good idea in lieu of package managers handling this scenario properly. This issue should probably be considered out of scope for SemVer.

[shmuelie]

Could we make the license part of the version?

[haacked]

Could we make the license part of the version?

In this regard, I look to the single responsibility principle. The version isn't meant to convey the license in the same way it's not meant to convey a package name.

Instead, I'd look to creating a new standard that's built on existing standards. For the sake of discussion, let's call it Semantic Identity.

A semantic identity would consist of a version (SemVer), a name (we'd need to find or define the spec for that), and set of licenses (perhaps using SPDX).

I'd prefer that rather than giving SemVer double duty.

[jonorossi]

Instead, I'd look to creating a new standard that's built on existing standards. For the sake of discussion, let's call it Semantic Identity.

A semantic identity would consist of a version (SemVer), a name (we'd need to find or define the spec for that), and set of licenses (perhaps using SPDX).

Some background: SPDX is very often confused with just the SPDX canonical license list they standardised. The specification defines licenses as a lot more than a single string like "MIT", because licensing gets more complicated with derivative works and the accurate specification of copyright. Unfortunately all this complexity results in the need for a SPDX working group.

@haacked you established in this thread that a package's license is just an attribute of the package (whether a basic string like "MIT", a full SPDX file, or something like Debian's copyright file), which I completely agree with. What value then would a "package identity" containing a license have, rather than just letting package managers have a way to specify licensing and notify on relevant changes?

[FichteFoll]

@jonorossi package managers could interpret a package's SemIdent and handle name or license changes specificially, as well as version changes in general, but on the other hand they are not obligated to. Most package managers probbaly only interpret version changes and notify a user of an updated version, that they allow to be downloaded, but do not interpret license or name changes.

Whatever package managers decide to do with it, the available information should be standardised somewhere, which a "SemIdent" spec could solve.

[johnvpetersen]

This is more of a business issue than a legal issue. And yes, IMAL. From a business perspective, assuming you are trying to encourage uptake, it would make zero sense to relicense a patch under in incompatible scheme - i.e. something like Apache to GPL. It would be completely unworkable. From a legal perspective, if the code derives from a licensing scheme such that the old license would have to apply (like the GPL) - then it would be a non-issue. IMO, if a project is going to change licenses in a way that could be considered a breaking change, the correct thing to do is start a new project and maintain that going forward. Practically speaking, 99.999% of the projects out there don't really have the wherewithal to enforce their licensing anyway.

[alexandrtovmach]

This issue looks staled and will be closed in 10 days if there are no objections. Thanks everyone for contributions, you're amazing 🎆

[jub0bs]

Is there any consensus about this? A bit disappointing to see this issue closed without resolution...

[ljharb]

I'm skeptical of the initial claim; i've never heard of any companies having any kind of "licensing committee" - usually it's just that the legal department works with engineers and/or open source experts and comes up with a policy of approved licenses, and that's that.

Either way, I would always consider changing a license to be a breaking change, although adding one is not (because with multi-licensing, you can just pick anything, so as long as the previous license remains a choice then it's fine).

[trallnag]

I would always consider changing a license to be a breaking change

I don't agree if the new license is functionally equivalent. For example switching from ISC to MIT.

[ljharb]

That’s fair, but there are so few functionally equivalent license pairs :-)