Deprecation Notice: MIT and BSD licenses
writing.kemitchell.com
writing.kemitchell.com
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 think lawyers generally don't comment in their professional capacity on things they aren't experts on. Engineers could learn to do the same!
Perhaps they should have involved someone from our side of the pond into the discussions around it.
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.
Also that's a pretty bold title.
More info on Blue Oak: https://writing.kemitchell.com/2019/03/07/Blue-Oak-Council.h...
Read the license. Read what others say about it. Read about the law. Apply your mind.
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
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.
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.
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.
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.
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.
For a different take see Mitchell's line by line analysis of MIT: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
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.
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.
(this is pretty much state of affairs in every company I worked for last 15 years)
> 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?
Reliability: No contributor can revoke this license.
Would this allow for a scenario where v1 was released under Blue Oak and v2 was released under a different, more restrictive license?