[Resubmitting this comment I made against a previous flagged article]

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...

> there is not yet a clear legal consensus on it.

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 MIT license goes back to 1988. A simpler time in so far as the open source community was significantly smaller. It was attached to an important piece of software, X11. It spread organically as more and more *nix systems were deployed over the decades. Compatibility with GPL didn't hurt.

I'd date what we now call "MIT" back further, to X10R3 in February of 1986. That's based on secondary sources. I'd love direct evidence if it's out there. Preferably a verified copy of the license to keep in my office. ;-)

IANAL, but I really dislike this license as a legal document. In the effort in making it clear it feels like there are more points to argue compared to what for instance the MIT license does which clearly defined what 'as is' entails. Contributor and everyone are not defined either, compared to the MIT license where it uses 'person' which has a clear legal idea behind it. To me I have a lot more confidence in the MIT license or the BSD license because the legal verbiage is precise. I know they had a mission but this seems to be nebulous and feels like there is too much room for creative interpretation.

> for instance the MIT license does which clearly defined what 'as is' entails

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...

I agreed. 'As is' is a well defined legal term, as well as person including legal entities (hence my use of the term legal idea). The same as person in the legal sense where a person can be an individual or corporation or other invention that can be assigned property.

> 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.

The magic words "as is" are defined by statute, but I'm not aware of any general rule of construction reading "person" as you describe. Contracts frequently define "Person" or "Entity" to cover both natural and legal entities/persons, because the law does not. See:

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...

My feeling is that if they're going for maximum clarity and minimum ambiguity it would have been better to use a descriptive name like "Maximally Permissive License" rather than "Blue Oak" which tells me nothing.

There's really nothing that names like "MIT License", "BSD License", "European Union Public License", "GNU General Public License", "Apache License, version 2.0",or "Mozilla Public License" tell me except the organization behind the license and the fact it's a license. "Blue Oak Model License" conveys about the same information.

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.

If these licenses weren't already well known I might hear "MIT License" and recognize MIT as a well established and prestigious institution and assume the license therefore has some legitimacy. I might also guess that as an academic institution the license won't be focused on protecting commercial interests as much as sharing knowledge, though I couldn't be certain about that. Similarly for the other established institutions. "General Public License" is quite general, but I could guess it's intended for general purpose use rather than a specific project and that it is public rather than private or commercial.

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.

Legal theory of operation for warranty disclaimers and damages exclusions---the ALL CAPS bits of old licenses---remains mostly speculation, especially with contract-license ambiguity. But most studied opinions I'm aware of, including my own, doubt that 0BSD, Unlicense, and other terms without terms-notice rules ensure meaningful protection. For evidence of a view even more skeptical than Blue Oak's, see section 8 of Apache 2.0:

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.

For license name I think distinctive is more important than descriptive. It's not like you can really rely on the name telling anything useful anyways

Established licenses are named in a way that would tell me more even if they weren't established. Given that they are established a new license faces more of an uphill struggle and an informative name would help in my opinion.

Blue Oak is the steward of the license. It seems like they're going for an FSF-style organization for permissive licenses.

Probably a bad idea, but roll with it. :)

Free Software Foundation is a good example of the sort of name that would be more informative. Naming is hard but I still try and call my functions things like ValidateNoDuplicates() rather than WhiteAsh().

Most open source licenses seem to be phrased based on US legal terms. The US legal system differs a lot from other parts of the world, such as civil law systems as practiced many others.

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.

You're right about open source licenses. As a rule, they're US-centric, which is not what I'd prefer, were I all-knowing and every-qualified. But I'm just a US lawyer.

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.

Well, take the ISC license (works everywhere where they ratified the Berne convention) and remove most of of the warranties and you have a EU license. Most of the EU countries lack laws about merchantability and fitness for a particular purpose, or at least lacks the need to be explicit about it (either because a "software provided "as is" without any warranties" will be enough to disclaim all warranties, or because you can't disclaim some warranties). Just make sure it works in your jurisdiction. Any international questions will, iirc, be governed by whatever the UN deal is called which is a bit more lax about implied warranties that UCC in the US.

But it is a minefield anyway, so just use the ISC license.

> I think I once saw an open source, copy-left license for the EU.

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

The https://en.wikipedia.org/wiki/Open_Government_Licence is a permissive license designed and used by a country that is for at least two weeks more an EU member.

I guess my main question is... is this needed? Has there actually been a case where the MIT license was inadequate for it's purpose in a real-world scenario?

MIT doesn't have explicit patent grant clause.

I mean, explicitly, beyond "companies are upset about hypothetical problems". Has there ever actually been a problem? Say, has anyone ever been sued for patent infringement upon using MIT licensed software?

Fun fact: there is also no express patent license in GPLv2. There have been lawsuits on that. I know because I was the lawyer who filed one of them. So...yeah, this problem is not hypothetical.

You should hire lawyers to improve your contracts before the ambiguity in your old ones cause lawsuits.

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.

I was always under the impression that BSD or MIT + patents was Apache2?

use Apache-2.0 then. It's longer in text but people are already using it and know what the terms mean. The point of the whole exercise is to use a small set of well-known licenses and keep things out of the hands of lawyers (which is admittedly the opposite of what Blue Oak wants)

React

Looks good (IANAL!), though I guess it will need "official" stamps of approval from OSI, DFSG, spdx etc. before people start taking a serious look at it.

has this been examined by a lawyer? Has this been tested in court? What's the stance of fsf and open source on this?

It has been written by lawyers.

It's been publicly announced 2 days ago, so court cases or in-depth review by other parties are unlikely to already have happened.

I addition to what other have said, how does it compare to more modern simple permissive licenses, such as https://en.wikipedia.org/wiki/ISC_license ?

The attribution relaxation in this is a nice step forward for trivial bits of code. I've seen too many Javascript applications that use 100+ small MIT-licensed dependencies, so the copyright statements end up being a significant portion of the minified code!

I'm actually a little disturbed that attribution is removed. What's the point then? People generally don't write software for free so that they can't even get basic credit.

Writing code that is helpful to and/or maintained by other people. Attribution does seem like a rather low bar, but I would understand if not everybody cares.

I see it covering the same use case as CC0, which is trivial bits of code that benefit mostly from mass adoption. In the case of this license it would be useful for code fitting that description which also may be covered by patents.

Just use MIT/ISC/BSD for sanity, or Apache if you want to grant patent rights.

> If anyone notifies you in writing that you have not complied with Notices, you can keep your license by taking all practical steps

Hah! As if "all practical steps" were some kind of clear and concrete legal measure.

What do you propose?

Something well defined for starters. Ideally something measurable without deferring to subjectivity.

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.

You've given me qualities of an ideal proposal, but no actual proposal. I suspect because that level of perfection cannot exist. If there were a superior alternative to drop in, we would drop it in!

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.

So... how does one get BLUE OAK CERTIFIED? https://blueoakcouncil.org/trademarks

See https://blueoakcouncil.org/list

> Only the licenses on this list are Blue Oak certified.

Probably by paying the lawyers that created Blue Oak their fee(s) :)

IANAL but doesn't unclear but known quantity count for much more than clear concise, but untested, in legal circles?

(previously submitted to an earlier flagged submission)