Blue Oak Model License 1.0.0
blueoakcouncil.org
blueoakcouncil.org
At first glance it Blue Oak seems like a decent license, and the points the author makes about MIT [0] seem valid.
My major issue with adopting a new license however is how well known it probably isn't, so there is not yet a clear legal consensus on it.
In all software companies I've worked in there is a clear list of licenses that have been pre-approved and I can just log the inclusion of any open source using those licenses and everything is fine.
However, if I want to use anything not already on the list it requires a manual approval process from the legal department, which is usually time consuming, and often just results in a 'no' because they are too risk averse to asses the licenses properly themselves, but are happy relying on the consensus that licenses like MIT and BSD are OK for commercial use.
Also, while a lot of the authors crtisisms of MIT seem valid points about uncertainty I think there is a lot to be said for the long length of time it has stood and the general consensus on it's intentions. If I see an MIT license, I can basically know I can do whatever I want with it, provided I give attribution, and there is no warrenty. I'm not going to worry about being sued over someone's interpretation of "deal in the software" because AFAIK, that has never happened in the 40+ years the license has been in use. I think I'd actually feel more at risk using Blue Oak just because of the lack of commentary and consensus on it's terms. The only really substantial point he makes is about variants under the same name, but the lesson here is to just do a diff on licenses to check it's in the standard form. And anyway, doesn't the same problem apply to Blue Oak and in fact all licenses, if you don't do a diff on the license text someone could easily produce and use a variant without you noticing.
[0] - https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
Just curious, how did the MIT license (and similar) achieve legal consensus? Was it "bootstrapped"?
> However, if I want to use anything not already on the list it requires a manual approval process from the legal department, which is usually time consuming, and often just results in a 'no' because they are too risk averse to asses the licenses properly themselves
Similarly, how do licenses get approved in the first place?
If MIT et al. overcame these hurdles, how do new licenses do it? Just by being used, and through the passage of time?
The Uniform Commercial Code defines what "as is" entails. I link the California Code section in the blog post:
https://leginfo.legislature.ca.gov/faces/codes_displaySectio...
> compared to the MIT license where it uses 'person' which has a clear legal idea behind it
MIT uses "persons" for licensees, not licensors. "Person" is also ambiguous as used. I hope it includes legal entities!
> To me I have a lot more confidence in the MIT license or the BSD license because the legal verbiage is precise.
Did you get to this part of the post?
https://writing.kemitchell.com/2019/03/09/Deprecation-Notice...
See also this part of my line-by-line analysis of MIT:
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
> Did you get to this part of the post?
Why would I have read this? It is no way linked as part of the OP. If it was intended to or you are part of the team that helped resolve (in reading some of the links it appears you are) but there isn't reference to your reasoning within two obvious clicks of the license.
I agree with the conclusion of the line by line analysis and commentary you did, with the MIT/BSD x-clause being not what you wanted. I guess that leaves us with the obvious question: why isn't apache 2.0 what you wanted? or the CDDL? Is it just because it's 'hard to read' and people get it wrong? Where have you showed if an entity is releasing code to the wild and never intending to take on contributors that an MIT/BSD x-clause is the wrong thing to do?
I still don't feel like this is better than any of what's existing. This may be because while the license may be more sound for a contributor based arrangement this license site right now does not do a great job of showing a novice in the street how to do it right and any checklist to ensure that they haven't botched it. Where's the workflow to convert MIT/BSD x-clause to Blue Oak? If the only way to understand it is to dig into a bunch of random blog posts, I don't feel like that's such a large improvement. If more time is spent making a clear way to self serve a correct arrangement I would be more inclined to support this license if some of this supporting documentation existed to provide evidence on what the intent should be.
https://www.adamsdrafting.com/person/
For how Blue Oak improves over existing terms, see my write-up:
https://writing.kemitchell.com/2019/03/09/Deprecation-Notice...
Probably a bad idea, but roll with it. :)
Also, it's not maximally permissive per se. 0BSD, for one, permits you to distribute the software even if you, for some reason, do not want to include the original license text with it.
But these licenses are already well known so the fact that their names are not terrible explicit is less relevant today. A new license hoping to gain adoption should try and do better but "Blue Oak" is clearly worse. It is also not an institution that seems likely to establish a reputation for things beyond the license, unlike MIT, Mozilla or the EU.
https://www.apache.org/licenses/LICENSE-2.0#additional
There are jurisdictions where the whole issue is moot, since meaningful warranties simply can't be disclaimed. But disclaimer, exclusion, and limits on liability are enforceable in many jurisdictions, including the vast majority of the United States.
I wonder whether there are implications with other legal systems, such as law in countries of the european union, where also different legal traditions with regards to copyright exist.
I think I once saw an open source, copy-left license for the EU. But never one in the spirit of BSD/MIT/Apache.
Perhaps this was the EUPL¹. As someone who works for a company that has occasionally been forced to use it for a contract, I'm pretty sure people don't choose it. Every time it has come up in a talk about a project, you have to answer basic questions about it :/
> But never one in the spirit of BSD/MIT/Apache
Nor me, but I've seen people mention the idea a few times in conversations about patents normally.
1. https://en.wikipedia.org/wiki/European_Union_Public_Licence
But it is a minefield anyway, so just use the ISC license.
We had some very valuable, indirect feedback on Blue Oak from lawyers qualified elsewhere. But not enough. I'd be very interested in inviting specialists from other systems to comment, publicly and privately. Moral rights in their various forms. Differing rules on warranty and damages exclusion enforcement. Things I don't know to ask about.
As for licenses of European origin, someone already mentioned EUPL. I'd add https://opensource.org/licenses/CECILL-2.1. I'm likely forgetting at least one.
To end on a happy note, I'd point out that plainer language can actually help jurisdictional portability. Compare the copyright and patent sections of Blue Oak and Apache 2.0, for example. Apache 2.0 takes the typical US legal approach of listing out the exclusive rights of copyright holders, and the actions constituting infringement of a patent, under US copyright and patent statutes. Apache 2.0 does not specify US governing law, but speaks in terms of US law. Blue Oak doesn't list out statutory verbs. It identifies the sets, rather than their specific elements.
That said, “Blue Oak” is a terrible name and will cause even more hassle than “Apache” when dealing with non-technical folks.
Explaining to the CFO that we license <component> to customers under “Apache” terms to avoid internal legal issues for our customers is... hard.
It's been publicly announced 2 days ago, so court cases or in-depth review by other parties are unlikely to already have happened.
Hah! As if "all practical steps" were some kind of clear and concrete legal measure.
The entire point of a license is to make it clear to both sides what things are allowed under what circumstances.
Who is the arbiter of practicality? Who makes that call? Which actions qualify needs to be completely clear to both sides because the rightsholder needs an assurance that your license has teeth and the other side needs an assurance that your license isn't capricious.
More generally, I don't think violations will play out as you expect. We have experience with this kind of provision, under licenses like GPLv3, much more often under breach-termination provisions found in many kinds of contracts. Section 8 of GPLv3 may sound more precise for using legal dialect, but that language, like "cure" and "cease all violation", isn't really more precise. For example, to "cease" violating GPLv3, do I have to go back and fix my past transgressions? How? If not, why does the following paragraph say "cure"? Does "cure" apply to future violations? Or does "cure" just point back to "cessation" in the previous paragraph?
All of this is actually quite alright, because by the time the licensor and licensee are in direct communication, it's within their power to settle the matter on their own terms, and not necessarily those of the license. Obviously, the licensor is the arbiter of practicality, up to the point where they decide to bring a claim or not. But the broad terms of the excuse provision give the licensee leverage and breathing room. The language does what we want, which is put the licensor and licensee in an interactive process toward resolution, and not in pre-litigation mode.
There is nothing capricious about paving a path back to compliance, despite breach, in a public open source software license. Quite the opposite. The effect of the term is to prevent capricious claims for injunctions and money damages against licensees who may have unknowingly, or even perfectly innocently, violated it terms. That kind of mousetrap claim, and copyright trolling, are possible under MIT, BSD, and even Apache 2.0, which lack excuse rules for their attribution conditions.
This looks to me like a case of shooting the honest messenger. Blue Oak has made this kind of term more transparent, in plainer language, with less reliance on the (false) mystique of legalese. Now that you can read the term, and the clear expectation is that you can and will understand it for yourself, you see the actual mechanism. And it isn't perfect precision, total lack of ambiguity, or a quasi-mathematical formula. That doesn't exist in practical legal terms.
> Only the licenses on this list are Blue Oak certified.
(previously submitted to an earlier flagged submission)