Blue Oak Model License

It seems that most Rust projects are copycats of the rust lang and simply select MIT+Apache-2 as license. I'm guessing this is mostly because most of us are not lawyers and really don't want to spend much time on this, so we copy from people who we assume have carefully thought about this. But has anyone considered using the Blue Oak Model License (Blue Oak Model License 1.0.0) for their project(s)? If so, has anyone found a good reason to stick to MIT+Apache rather than select the Blue Oak License?

Personally, I'd be tempted to only use the Blue Oak license - after having read the following two blog posts:

But I'm curious about what other people here think.

Similar to most copyleft licenses I would be wary of introducing this into a corporate codebase.

Not because I don't think it would "work", but because jurists and lawyers are (as a group) careful and skittish people who like things going slow and not moving at all if possible (understandable given what they work with). So they found a couple of licences which work and they'll probably say no to any new licenses unless you can express a business need to the higher ups.

Are you thinking of cases in which a company is writing/publishing open source software? Or are you thinking of the case in which a company is allowing/restricting use of open source software with certain licenses?
In my case - I'm a free agent, so I can do what I want. I can (sort of) see that a company (when publishing open source) would not like this license, since it means they would no longer be able to first get a patent and then publish the code - the patent would lose it's meaning. But I think that's an unlikely scenario anyway - If you're thinking of patenting, then you probably don't want to make it open source anyway (and you cannot make it open source before you got the patent), right? Anyway in that case a CC0 license or Apache-2 might be more appropriate.
But what about the non-company case?

I'm not familiar with this one, but I believe Mozilla Public License (MPL) is a great choice for rust code. It is copy-left on file level, and will work with static linking (unlike LGPL). And static linking is pretty much required for rust. But I'm not a lawyer, so don't take my word for it.

1 Like

I looked at the MPL - Honestly, it makes my head hurt. One advantage of the Blue Oak one is its shortness, but people might have doubts about clarity? For instance it refers to "this software" - which could be a term that becomes slippery once a lawyer starts working with it ("these files" "this whole package of files as a package", "the compiled library or executable" (including its dependencies?).

In which case, allow me to introduce you to the 500 characters shorter MIT license. The drawback, of course, is the lack of patent exclusion. Though it could be argued the explicit list of permissions in MIT negates a patent claim. I assume that's what the Blue Oak folks had in mind: negate the rights of copyright instead of allowing the limitations of copyright.

I believe the Blue Oak one is most similar to the MIT license. I'm disappointed they did not offer a comparison (that I could find).

To me, especially without any backing court cases, like most open source licenses, it is just another legal theory.

Many years ago, the last time I took an interest in such things, this was critical...

Nowhere in its short text will you find the phrase “public domain”.

The definition of "public domain" was (is?) specifically reserved for U.S. governments #. As far as I know, the idea of a private citizen placing something in the "public domain" has never been tested in court. Were I in your shoes I would avoid any license that mentions that phrase.

# I have no idea how that works elsewhere.

1 Like

Thanks - will consider this.

Personally as a non-lawyer I don't really care about the license being short and easy to read. No matter the length of the license, I won't be able to understand its actual full legal implications. For example, the Unlicense is also short and easy to read and understand, but apparently according to the sites you linked it's bad and has "legal confusion". So I'd rather just use licenses that are "tried and tested" and let other people worry about it. This also has the benefit that developers looking at my code will be more likely to already be familiar with the license. At least for me, this is the first time hearing of this license.

For now, I'll stick to MPL-2.0 as my permissive license and AGPL-3.0-or-later as my copyleft license. If the Blue Oak Model license becomes widely used and recommended and I see a compelling case for preferring it over MPL, I might use it.


If it's not on the list, you need a reason to use it, not a reason not to use it.

The last thing we need in open source is more licenses making it hard to tell what we can use with what.


Thanks - that's a valid concern.

"Obvious" things in law often aren't, so I'd beware any layman's interpretation of what makes a good license.

You might be interested in as one lawyer's published opinion on licensing in general and various specific licenses.

(I've heard some people aren't a fan of the specific analysis in the book, but it's the best free-and-open resource on the subject I have to reference.)


iirc the CC0 license gets around the public domain issue by instead being a maximally broad copyright license. CC0 - Creative Commons

This is also why most public domain dedications are worded the way they are — roughly "to the full extent possible under the law, the author waives all copyright they would be entitled to over the released work and dedicates it to the public domain" — under most jurisdictions, public domain is not a thing the copyright holder can choose, whereas they can choose to abandon their copyright.

Though of course, IANAL. If you want to release copyright to something as much as possible, dual license it under your preferred public domain dedication OR a common permissive OSI approved license; then the user can choose whichever they are more comfortable using the work under. ("AND" means the user must comply with both licenses' terms. "OR" means the user may pick one and disregard the other.)

Plus IIRC the Creative Commons people recommend not using any CC licenses for code/software, including CC0.

Oh cool, I didn't realize that OSI had a category for this.

It would be nice if there were some sort of well-tested framework for "pick and choose" licensing (i.e. of the permissions/conditions/limitations as described by choosealicense), but that's not really compatible with the legal reality.

(My personal ideal license would probably be MPL-2.0 OR [MIT-0[1] only if distributed in executable form as part of a larger work]. I don't see any real benefit to license/attribution buried somewhere in an "OSS licenses" dialog with far too many copies of the same license text[2] for the scope of libraries I tend to work on.)

  1. MIT without the attribution requirement ↩︎

  2. Even if it would be legally permissable to provide one copy of each unique license text and list multiple attributions using the same license (the best I can tell, merging licenses is dubious when a unique © line is in the LICENSE file, and still somewhat questionable when not), it's unambiguously permissable to reproduce each license verbatim, even if it makes for a worse result. Lawyers will almost always prefer the long unambiguous option over a questionable option even if the latter might be morally preferable. (i.e. because attribution is clearer without pages of duplicate legal text between entries.) ↩︎


Thanks for all the comments + links. Still need to study this a bit more. In terms of permissiveness, I do like the MPL-2.0, but MPL-2.0 and Blue Oak seem to be equivalent in actual terms (and the language in the Blue Oak one then seems clearer, less slippery and less ambiguous). But community adoption (or non-usage or not-yet-usage) is also a factor.
One thing that strikes me in the MIT license, is that it is totally mute about patents. I'm not sure what to think of that.

It looks like the Fedora folks have rejected CC0.

The Creative Commons group specifically recommends not using their license agreements for software.

In 2021 Brian L. Frye of UA Little Rock makes a solid argument that CC0 is fragile partly because it is so very novel. Waiting for the courts to take an interest is prudent.

Still sticking with Apache 2 / MIT.

1 Like

Note that this is a "notice" license, not a "copyleft" / "reciprocal" license.

The website explicitly describes MIT and BSD 2 clause as "silver" tier examples of what they expect a copyright license to have (BSD 2 clause plus patent is "gold").

Personally, I am extremely fond of Kyle Mitchell's style of contract writing. It's very readable and makes you feel like you get the point of the legal jargon from the context.

1 Like

Here's a sample of his work: Discourse Standard Hosting Terms | Discourse - Civilized Discussion and

He also has a good blog talking about copyright issues, like this post: Where is the rule that makes vague license rules legal no-ops? — /dev/lawyer

Historically, the MIT license was written before defense against software patents was a common concern. Today, this is at least part of why many Rust packages are licensed as MIT OR Apache-2 — the Apache license addresses patent concerns, while the MIT license is very simple.

Afaik 0BSD is the software equivalent of CC0.