I feel that Kyle E. Mitchell places an immense focus on the U.S. and neglects the situation in other countries to a certain degree. His MIT license explanation was fairly U.S.-centric, citing primarily U.S. sources (e.g. referring to the UCC, books published by U.S. publishers) and kept going on about the debate about contracts and licenses, which probably does not ravage quite that hard in Europe -- while the patent aspect can effectively be ignored over there because software patents don't exist.

I get it, Silicon Valley is important. But there's other places, too. I don't feel like they have been given enough attention in this new license.

Meanwhile, the Blue Oak license leaves unadressed the problem of European moral rights in copyright[1]. Similarly, the issue of someone simply not reading the terms and just taking the code, similar to EULAs, is left unexplained. The Blue Oak license assumes acceptance and agreement, which may not actually hold up in court and lead to a different result.

[1] cf. https://en.wikipedia.org/wiki/Authors%27_rights for an introduction

I place an immense focus on US law. It's the only law I'm qualified to practice.

We were able to incorporate indirect feedback from very competent UK counsel. Not as much as I'd like. For example, the inclusion of "condition" in No Liability makes no sense under US law, but reflects a technical distinction in some UK jurisdictions.

I'd like to draw in more input from counsel elsewhere, which is part of the reason we published versioned 1.0.0 from the get-go.

Does he have professional expertise in law outside of the US?

I think lawyers generally don't comment in their professional capacity on things they aren't experts on. Engineers could learn to do the same!

He may not but claims they were more than one lawyer involved in drafting it.

Perhaps they should have involved someone from our side of the pond into the discussions around it.

Sounds like an ad for this new Blue Oak licence. I don't have any problems with ads but I think the article should be a little more objective about the comparison.

Also that's a pretty bold title.

I would also have dismissed the article given how much it seems to advertise Blue Oak, but Mitchell is a good "argument from authority" on licenses.

More info on Blue Oak: https://writing.kemitchell.com/2019/03/07/Blue-Oak-Council.h...

Don't take a word I say "on authority".

Read the license. Read what others say about it. Read about the law. Apply your mind.

It isn’t listed as an Open Source licence which rules it out for most purposes. https://opensource.org/licenses/alphabetical

To be fair, it appears to have hit 1.0 just hours ago, so this may just mean that OSI doesn't know about it yet.

OSI generally requires that the license steward/author submits the license for review if they want it to be approved.

Upon being asked about this by OSI President Simon Phipps, Kyle Mitchell responded that Blue Oak has no plans to seek approval (https://twitter.com/kemitchell/status/1104579340732264448). I would have found anything else surprising, given that last month Mitchell had this to say about the OSI (in the context of SSPL review):

> I've lost confidence in this body's ability to make rigorous decisions, or even facilitate focused debate, […]. So I've otherwise stopped responding, and focused my efforts where collective time and talent have hope of yielding practical results.

Source: http://lists.opensource.org/pipermail/license-review_lists.o... Context: https://opensource.org/LicenseReview022019

At first glance it Blue Oak seems like a decent license, and the points he makes about MIT and BSD 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.

Edit to add: Also, while a lot of his 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.

There is a chicken-and-egg problem with any new license, especially when the new terms aren't written for a specific, important release. But there's no improving the situation for future projects without new terms.

For what it's worth, Blue Oak Council didn't set out to write a model license. That fell out of our effort to compile a list of permissive licenses:

https://blueoakcouncil.org/list

https://blueoakcouncil.org/2019/03/06/model.html

That list was compiled in accordance with our mission, as 20% solution to cover 80% of needs for organizations, especially nonprofits, that can't find or afford specialist licensing counsel. Our list is also published as JSON data, for ready inclusion in automated compliance tooling:

https://www.npmjs.com/package/@blueoak/list

Everyone involved in Blue Oak so far also has programming experience, and many of us have contributed to standards and software for compliance. For example, I contributed documentation clarifications and validation code for license metadata in RubyGems and npm, and maintain a command-line utility for automated license audit of npm-based projects. Blue Oak's license list leverages SPDX license identifiers, same as many package metadata specifications.

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

I wish that were enough. Unfortunately, it's not.

There is a serious debate ongoing right now around the patent coverage of the old academic forms, and what that says about what "open source" means. Compare:

http://stlr.org/wp-content/uploads/sites/2/2018/10/Kappos-Ha...

http://stlr.org/wp-content/uploads/sites/2/2019/03/Lindberg....

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

That's natural and understandable. There will be early adopters and wait-and-see kinds of folks.

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

That's true, but there are mitigations. We've opted into at least two: submission to SPDX for a license ID, so folks can specify in standards-compliant metadata, as well as a permalink for the license text itself, like Apache 2.0.

Has the author ever heard of Blue Oak? The text was unclear on this point.

EDIT: Sorry, sarcasm got the better of me. However I do think Kyle Mitchell should have put this disclaimer at the start of his post instead of the end:

> I had a hand in drafting the Blue Oak license, and I’m executive director of Blue Oak Council, the license steward.

No license is perfect, but I do not apologize for promoting use of this one! Humility's no virtue here.

However, I made a conscious point to note my role before the call to action. I'm under no illusion that my word will be enough for everyone.

The headline is poor (and misleading), so I understand negative reactions to this.

But I enjoyed the opinionated nature of the post by someone who understands licensing, the clear descriptions of the problems with existing solutions, and that the author has done a lot of work to create something that he perceives addresses those problems.

> the author has done a lot of work to create something that he perceives addresses those problems

I was but one lawyer putting hard work into this project. I'm proud of my role, but can't stress enough that I was just one contributor.

> I was but one lawyer putting hard work into this project. I'm proud of my role, but can't stress enough that I was just one contributor.

Thank you! Your article made that clear, so apologies for my unclear wording.

The headline was misleading and the text would have been better by being up front that it was an advert (and the author really didn't need so many links to Blue Oak).

For a different take see Mitchell's line by line analysis of MIT: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...

The fact that MIT and BSD are decades-old licenses that don't address things like patents or that, generally, are not tightly-written legal documents isn't especially news.

I find it a little curious that Apache is pretty much mentioned just in passing (to point out that it's written in legalese) given that's mostly the preferred license for significant (as in corporate/foundation-backed) new projects wanting a permissive license. It feels a bit like critiquing a strawman.

Both Blue Oak and Apache are relatively modern permissive licenses, but they differ intentionally in design. In the short to medium term, I foresee that many projects will continue to choose Apache where contributions from large software patent holders are essential, because of Apache's complex rules on patent scope. At the same time, I think large software patent holders will prefer to receive code under the uncomplicated Blue Oak patent grant, even as they insist on Apache's mazelike compromise for outbound contributions.

Puppet, a freemium services FOSS model, switched licenses a bunch of times but settled on Apache. Depending on the use-case, there can be legal problems on customers' sides including certain projects in hardware, software, SaaS products or even just using them with onerous licenses like GPL3 and AGPL. The license's restrictions on use combined with the type of use makes all the difference.

Legal department flagged everything under MIT, BSD, Apache are OK to use. Not a word about Blue Oak in our guidelines

(this is pretty much state of affairs in every company I worked for last 15 years)

Buried at the very tail end of the article, is that the author cowrote Blue Oak:

> I had a hand in drafting the Blue Oak license, and I’m executive director of Blue Oak Council, the license steward.

In case, like me, you're wondering whence the mention of Blue Oak every single damn paragraph: this is an ad for Blue Oak.

Not that promoting Blue Oak is a problem. I am sure Bloa Uek is a great license! Blue Ook deserves fair attention. Blua I do feel Oak maybe, Blue would have been foak to mention blue at the oak, bluestead oak bottom?

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

  Reliability: No contributor can revoke this license.

What does this mean in practice? That once something is released with this license it cannot be revoked?

Would this allow for a scenario where v1 was released under Blue Oak and v2 was released under a different, more restrictive license?

Reporting as spam for Blue Oak