Files
hpr-knowledge-base/hpr_transcripts/hpr2809.txt

236 lines
16 KiB
Plaintext
Raw Normal View History

Episode: 2809
Title: HPR2809: The Blue Oak Model License and Its One Big Gotcha
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2809/hpr2809.mp3
Transcribed: 2025-10-19 17:06:42
---
This is HPR Episode 2,800 and I'm titled The Blue Oak Model Isons, and it's one big
gotcha.
It is hosted by first time host Jol-D and is about 21 minutes long, and carries a clean
flag.
The summary is introducing and emitting a new and elegant permissive software license.
This episode of HPR is brought to you by archive.org.
It's universal access to all knowledge by heading over to archive.org forward slash donate.
Hi, this is Jol.
This is my first ever episode of Hacker Public Radio, and I found out about Hacker Public
Radio at least two years ago.
Believe it or not, through the banner ads on the Overcast Podcast app on iOS, so whoever's
idea was to have those ads, you got at least one listener out of them, and it took me
a little while to catch on to the multiple author aspect of this network, but once I did
I was intrigued, and I've been meaning to record an episode for at least a year now,
and I have a lot of ideas, and I finally decided to make an episode about a new permissive
open source license that was just released this month.
But maybe now that I'm recording one, the floodgates will open, or we'll see.
I have a small children and a day job, and I'm a perfectionist, so it's sometimes hard
to make myself do things that I know won't turn out right, and this recording will not
turn out right.
I do have a nickname or a handle, I'm often Velcro Van online, it doesn't mean anything.
I just like the sound of it, and it's almost always available as a user name, but since
my real name is on almost everything I do, I'm Joel D on Twitter and Mastodon, and Reddit
and many other places, so I figure I might as well just use my name Joel here, or Joel D,
or Joel Duik.
So I'm talking today about the new permissive open source license, it's called the Blue
Oak Model License 1.0.0.
And you probably know this in licensing in open source or free software, there's a big
difference, and I'm not going to go into that, and you probably know about it anyways,
or it's another episode topic.
But there's the idea of copy left, where you release your source code, and under a license
that binds people who use it to also release their, any changes they make to the software
as open source, or as free software as well.
And then there's the permissive license, which is basically a license that gives maximum
permission for users of your software and your source code to use it, however they want
and release their changes back to you or not, it's up to them, it's very permissive.
And so this license that I'm about to talk about falls under that permissive category.
It's the, and I should add that I'm not a lawyer, so you can't take any advice here as
coming from an expert.
But the, this license that I'm about to talk about was written by a council of lawyers
who are also in, as far as I can see, every case also developers themselves.
So that's a, that's great when you have legal expertise married with industry, know-how,
and practical knowledge.
For myself, I've kind of settled on using for permissive license, the free software foundation
recommends the Apache 2.0 license, specifically because it protects licensees from the author
coming back at them with patent infringement claims.
And so this, this license does as well.
And maybe your eyes are about to glaze over and you don't want to hear a lot of legalese,
but I'm actually going to read the license for you because it's very short and very clear.
And it seems to cover almost all the bases except for one important base, which I'll talk
about later on.
So here is the text of the Blue Oak Model License and see if this doesn't appeal to you for,
for your project.
It begins section one purpose.
This license gives everyone as much permission to work with this software as possible, while
protecting contributors from liability.
Section acceptance.
In order to receive this license, you must agree to its rules.
The rules of this license are both obligations under that agreement and conditions to your
license.
You must not do anything with this software that triggers a rule that you cannot or will
not follow.
Copyright.
Each contributor licenses you to do everything with this software that would otherwise infringe
that contributor's copyright in it.
Notices.
You must ensure that everyone who gets a copy of any part of this software from you with
or without changes also gets the text of this license or a link to.
And then they give you URL at blueocouncil.org.
Excuse.
If anyone notifies you in writing that you have not complied with notices, section above,
you can keep your license by taking all practical steps to comply within 30 days after the notice.
If you do not do so, your license ends immediately.
Patent.
Each contributor licenses you to do everything with this software that would otherwise infringe
any patent claims they can license or become able to license.
Reliability.
No contributor can revoke this license.
No liability.
As far as the law allows, this software comes as is without any warranty or condition and
no contributor will be able to license, I'm sorry, will be able to, will be liable to
anyone for any damages related to this software or this license under any kind of legal claim.
And that's it.
I think it's about 250 words.
It's pretty short and sweet.
There's not a lot of legal language in there.
I'm sorry, not a lot of legal jargon.
The language is all very legal.
And that's it.
It's very understandable and also legally robust.
And that's my opinion based on reading it as well as reading the discussion and comments
and arguments in favor of it by one of its authors.
And there's really only one issue with it as far as I can say, but as I mentioned, I'll
get back to that.
So a lot of, you're probably very familiar.
A lot of GitHub repos and repositories and projects use.
They're going to use a permissive license.
They use the BSD license or some, there's the variance of the three clause variant, the
two clause variant, or they'll use the MIT license.
And one of the authors of this license wrote a blog post kind of introducing this blue
oak license as well as explaining the problems with MIT and BSD licenses.
And I just kind of want to note some of those, which they kind of ran true to me.
He has a blog post called The Deprecation Notice, MIT and BSD.
It's time to retire 30-year-old academic licenses.
I'll put a link to this in the show notes, and I won't read every point he makes in
here because I don't necessarily agree with all of them.
But there's a good set of them here that do seem to be obvious.
The first one being the one that the Free Software Foundation has already identified, which
is that MIT and BSD licenses don't address the patent issue.
So if you use open source or free software licensed under one of those two older licenses,
it is conceivable that the copyright holder can then patent some of that technology and
then come after you for infringing on patents in that software.
Even though they've given you a pretty permissive license, patents are from what I understand
are covered under a different body of law in most countries.
So because the license doesn't address patent rights, then that's a danger to you.
And kind of the idea with a permissive license is you want people to feel safe doing just
about everything they might want to do with the software.
You want adoption.
You're not really obviously going for compensation or even credit in most cases.
But you want them to feel safe.
So if you don't protect them from the patent issue and you never know, software can be sold
or acquired by large faceless corporations that are not always on board with the altruistic
spirit of free software.
So that's a problem with MIT and BSD.
They don't address patents.
The blue oak clause for patents is short and sweet and it says simply that each contributor
licenses you to do everything with the software that would otherwise infring any patent claims
they can license or become able to license.
And it also says that this no contributor can revoke this license.
So right away, if you're looking at using blue oak model license software, you can feel
pretty secure from that issue.
Apache 2.0 does address the patent issue, which is why the free software foundation recommends
it.
A problem with MIT and BSD, there's confusion about what exactly they are.
Are they a license or are they a contract?
They don't say.
But licenses and contracts are dealt with, again, it's kind of like patents as far as from
what I understand.
They're separate bodies of law associated with each of those.
So when somebody wants to enforce a license that can result in confusion, this, again,
this is a point in Kyle's post about this, the weakness.
But the blue oak model licenses way of solving this is to make clear that this is a license
and a contract.
And so it says the rules of this license, this is the blue oak license, again, are both
obligations under that agreement and conditions to your license.
So that makes things somewhat clear.
Another problem with MIT and BSD licenses and, frankly, lots of other permissive licenses
is that there's really no path to forgiveness if there's no grace period, if the license
is violated.
And I can illustrate that again by pointing out the solution in the blue oak model license,
which is to give everyone who breaks the license 30 days after being notified to comply
with it.
And the virtue of this approach is that, again, it's about a permissive license is about
helping users and even companies that might consider using your code to feel safe in doing
so that it's not going to come back to bite them.
If you license your software under the MIT or BSD licenses or similar licenses, and
for example, later sell your software or company to another company, that company may search
for infringing companies and just sue them right out of the blue.
I believe Kyle has noted that this has happened in the past.
And so, anyway, I don't have a lot of expertise in that, but it makes sense to me that if you're
going to protect people from legal traps, just like with the patent clause, you want to
give them a grace period to say, if you do violate this license, you've got 30 days, you
make it right, you're good, you're fine.
There's not going to be a possibility of a SNAP lawsuit from the holder of the copyright.
Hope that makes sense.
One last problem with the MIT and BSD licenses is they kind of assume that there's only one
copyright holder.
They kind of assume that the copyright holder is either a single person or an institution
that all of the contributors work for.
So, it's kind of unclear how the copyright of all the individual contributors should
be treated or handled or whether they're even handled by the license when those contributors
are separate people working for other companies or working for themselves.
The Blue Oak Model License addresses this with language that says each contributor, so
each contributor licenses you to do everything with this software that would otherwise infringe
that contributor's copyright in it, same with the patent rights.
And so, you might ask the question, what makes you a contributor from my uneducated perspective?
If you offer up any source code to the maintainers of an open source project, you're a contributor.
You don't have to necessarily sign anything.
And you're already covered under the license at that point, since you were using the software
if you were going to be writing additions or changes to it, so that makes you a contributor.
So, the Blue Oak Model License is very clear about how, about the fact that each contributor
has his or her own copyright in the software that they contribute and that each separate
contributor is separately authorizing everyone to do anything with that software that might
otherwise violate their copyright, so that's simple, clear, and understandable.
There's only one problem with this license that I have found, and it may be kind of a big
one depending on what your perspective is or what your particular project is, and that
is that as written, the Blue Oak Model License does not offer any kind of protection for
giving the original contributor's attribution or credit for the work that they did.
So if I wrote software and released the source code under the Blue Oak Model License, it,
as I read it, it would be perfectly legal for you to take that software and remove any
mention of my name and simply re-release it under the same license.
You would have fulfilled the terms of the license which require you to include the license itself.
But you would have succeeded in erasing me from my own invention potentially.
And that's, you know, that is what that is. I actually emailed one of the members of the council
about this issue, and his response was basically, yeah, we wanted it.
It kind of comes out of the approach that they took in building it, which was that the Blue
Oak Model License was basically a, the unit set of all the best features of all the permissive
licenses out there, written as simply and robustly as possible, and a credit requirement for
contributors simply just didn't make that cut apparently. I don't know any other way to put it.
So that I think is a concern. I think even the most permissive licenses other than, you know,
attempting to put something in the public domain still allow you to, you know, try and retain
some kind of a copyright notice or something. So shortly after that email exchange,
the terms of use for the license itself, the Blue Oak Model License itself were changed
to allow you to make changes to the license as long as you remove any mention of Blue Oak from,
from your new tweaked license. So I did write my own tweaked version of this license for a particular
project that I have in mind and in which I require credit to be given to particular contributors
in the, to the project. And that is, that project is a website that I've been working on for 20 years
called the local yarn. And I'm not going to get into that now, but I will put a link to the
modified license in the show notes as well. I don't know what to call it, so for now I'm calling it
the local yarn license. And I would like to give credit to the excellent members of the Blue
Committee. But again, the term, their permission or terms that they give for their license say that
if you make changes to the license, you have to remove all mention of Blue Oak and Blue Oak Council as
well. So I'm mentioning them in this podcast and I figure, you know, it's probably not going to leave
the room. And one of the members of the council did say, you know, it's okay to mention us. Just
don't, just don't put our name on the, on the actual license itself that you create.
And of course, I'm not a lawyer, so I've got to have to accept responsibility for any changes I
make as, as will you. But, you know, maybe take a look and, and see what you think of, of my changes.
And that's all I have to say about this. It's a lot of legalese and it's not as fun
as talking about programming. And I do have some fun programming episodes in mind, but I just wanted
to hit record and get this out there. So thanks for listening and keep your stick on the ice.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out how
easy it really is. HECCA Public Radio was founded by the Digital Dove Pound and the Infonomicon
Computer Club. And it's part of the binary revolution at binrev.com. If you have comments on
today's show, please email the host directly, leave a comment on the website or record a follow-up
episode yourself. Unless otherwise status, today's show is released on the Creative Commons
Attribution ShareLight 3.0 license.