Hacker News Reader

Comment by paxys | Hacker News Reader

> 171 words every programmer should understand

Except there really isn't any agreement on some of the finer details of the license, no matter how much you want to study and understand it. Does the license text have to be included in only the source code or the compiled software? What if the source code of the derived software isn't made public? What is "substantial portions" of the software? Can a MIT project be relicensed? What is the point of any of these clauses then?

While it is a great license, I wish something closer to just public domain would have become the OSS default, since that is what 99% of developers want anyways.

View on HN

> Can a MIT project be relicensed?

Among more sophisticated users I don't think there's disagreement on this point. The answer is "no", if by "relicense" you mean "remove the MIT license and put in something else". You can never legitimately remove the MIT license from a file unless you're the copyright holder or their authorized agent.

Where there's less than total agreement is whether the MIT license may be subsumed by another license — e.g. the Apache License 2.0 — when an MIT licensed work is bundled within a package. Can you claim that the complete package is available "under the Apache License 2.0", omitting the fact that the licenses are actually polyglot?

The answer to that question seems to be "everybody does that" and "in practice, the legal risk seems to approach zero", but in theory should two licenses ever prove to have incompatible provisions then things could get sticky in a court case.

I was involved with a group of open licensing lawyers that ended up publishing a "model" permissive license: https://blueoakcouncil.org/license/1.0.0

It's not everything anyone ever wanted, but we think it's a lot closer.

I like the way this license is much clearer about rights and obligations. From the standpoint of software developers being able to grok it, it looks like a strong improvement on the MIT and BSD families.

If you are serious about adoption, I suggest providing an official header to embed in files. Something simple like this:

   // Licensed under https://blueoakcouncil.org/license/1.0.0

Also "instructions on how to use this license in your software project" would be helpful. (Paste the text of the license into a file named "LICENSE", "LICENSE.md", or similar. Add the header as a comment to every file...)

Thanks. We didn't originally set out to write a new license, but when we did, we put real time and thought into it. It's nice to see that appreciated.

We've shied away from declaring one "right" way to use the license, because norms, conventions, and expectations vary so much across development communities. What's right and normal for, say, Maven artifacts would seem a bit strange in, say, an npm package or a C library.

I too like the license, and wouldn't mind using it. Have you considered submitting it for approval to the OSI and FSF?

Everyone involved in the drafting has been through the OSI license process---or some ever-changing version of it---before. Last we discussed, nobody wanted to do that process again, even for an uncontroversial permissive license.

Personally, I don't care what OSI says. If someone else wants to go and ask them about it, more power to them.

Reply on news.ycombinator.com