Consider Reverting To ISC License

[Kurt-von-Laven]

The Blue Oak Model License 1.0.0 has a few drawbacks that I am aware of:

• Patent holders may be deterred from contributing, and to my knowledge there is no precedent regarding how the license may be interpreted or whether it will be upheld in any jurisdiction, making it difficult to evaluate.
• To my knowledge, it hasn't undergone any sort of public review process such as OSI approval.
• It claims to be easy to understand, but FWIW I did not understand it after several readings, which is why I started researching it further. (I am pretty sure I did understand the ISC license on the first try, although that was many years ago.)

I don't have strong feelings about this; I just came across these discussions because LicenseFinder spotted the license change, and I was evaluating whether we should approve use of Blue Oak 1.0.0 dependencies in our projects.

[Kurt-von-Laven]

Having re-read the license again, the only way I could envision complying with the Notices section would be to convert our projects to closed-source:

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 https://blueoakcouncil.org/license/1.0.0.

As an open-source maintainer, I don't have the power to stop people from downloading individual files from our repositories on GitHub and can't reasonably ensure that they also download or view the license of a vendored dependency. Additionally, we follow GitHub's official guidance in using @vercel/ncc to minify our dependencies, so if we were to accept Blue Oak Model License 1.0.0, we would be in violation of its terms every time a third-party ran a GitHub Action of ours that depends on it.

[isaacs]

Necessary disclaimers, IANAL, and also I'm not a lawyer, and even if I was, I wouldn't be your lawyer unless you were paying me, so this is in no way legal advice.

As an open-source maintainer, I don't have the power to stop people from downloading individual files from our repositories on GitHub and can't reasonably ensure that they also download or view the license of a vendored dependency.

If you are shipping this software, you must ship it with the license. If someone downloads an individual file from your repository, and the license was available in that same repository, then you have made it available to them along with the software.

If you are vendoring this (or pretty much any OSS) library, and not vendoring the license along with it, in the same place, then yes, you are in violation of the license. MIT and BSD have similar provisions.

MIT:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

BSD-3-Clause:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

When in doubt, put the text of the license in the file itself as a comment, but I personally think that's a bit excessive. Everyone knows what the LICENSE.md file is for, and anyone who can fetch individual files from your repository knows how to view the license (assuming it's present).

Patent holders may be deterred from contributing, and to my knowledge there is no precedent regarding how the license may be interpreted or whether it will be upheld in any jurisdiction, making it difficult to evaluate.

Is that a bug or a feature? I'm not sure. I find software patents, on balance, morally objectionable. What little social good that they do (which is not zero, to be clear) is vastly outweighed by the harm they do. I am in favor of the disarmament of the intellectual property weapons wielded by megacorps in open source communities. If the use of Blue Oak dissuades patent holders from using my code, or makes them tread much more carefully in how they interact, I see that as a benefit.

To my knowledge, it hasn't undergone any sort of public review process such as OSI approval.

I don't care that it isn't OSI approved. It has undergone quite a bit of public discussion, by people who I trust to make legal decisions, including lawyers I've retained in the past and whose integrity and insight I trust implicitly, and their position is that it's good, so that's enough for me.

It claims to be easy to understand, but FWIW I did not understand it after several readings, which is why I started researching it further. (I am pretty sure I did understand the ISC license on the first try, although that was many years ago.)

True, it's not as simple as ISC. But it is still plainer english than most licenses, and addresses many of the points where ISC is a bit vague. I like it.

I understand that we might not all see eye to eye on these things, and reasonable people can disagree in good faith. As always, if BlueOak (or any license I choose) is a blocker for you, I am willing to offer a proprietary license with extremely flexible terms for a license fee equal to $50 per month per full time employee (or equivalent full time contractor/contributor). If this is of interest to you, let me know.

[Kurt-von-Laven]

Necessary disclaimers, IANAL, and also I'm not a lawyer, and even if I was, I wouldn't be your lawyer unless you were paying me, so this is in no way legal advice.

Yes, of course; IANAL either.

If you are shipping this software, you must ship it with the license. If someone downloads an individual file from your repository, and the license was available in that same repository, then you have made it available to them along with the software.

If you are vendoring this (or pretty much any OSS) library, and not vendoring the license along with it, in the same place, then yes, you are in violation of the license. MIT and BSD have similar provisions.

MIT:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

BSD-3-Clause:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Personally, I agree with your sensible interpretation of the notice requirements of Blue Oak, and we meet all those standards already, so compliance with this interpretation would not be an issue. I would even hazard a guess that you had already spoken specifically with the license authors about this topic, and that they also agree with our interpretation. My problem is that if I were to use any software with such a license, I would have to trust that an arbitrary court of law in an arbitrary country with limited software engineering expertise will also agree with our interpretation. I find the wording of the MIT and BSD-3-Clause licenses on this topic less subjective, because they are worded in terms of what I must do and what is in my control. I have greater confidence those licenses will be interpreted in the manner I expect because they each have large bodies of case law at this point. Obviously different organizations have different levels of appetite for legal risk, but as an open-source developer contributing software for free, mine is very low.

When in doubt, put the text of the license in the file itself as a comment, but I personally think that's a bit excessive. Everyone knows what the LICENSE.md file is for, and anyone who can fetch individual files from your repository knows how to view the license (assuming it's present).

Putting the text of the license itself in the file as a comment would address the case where someone downloads individual files, but not the case where they use our GitHub Action and receive only the minified output of ncc. Regardless, if I were to take that approach, I would be maintaining a fork of any Blue Oak licensed software we use or looking for some tool that automatically copies license texts into files. In any case, such an approach would significantly raise the cost of adoption.

Patent holders may be deterred from contributing, and to my knowledge there is no precedent regarding how the license may be interpreted or whether it will be upheld in any jurisdiction, making it difficult to evaluate.

Is that a bug or a feature? I'm not sure. I find software patents, on balance, morally objectionable. What little social good that they do (which is not zero, to be clear) is vastly outweighed by the harm they do. I am in favor of the disarmament of the intellectual property weapons wielded by megacorps in open source communities. If the use of Blue Oak dissuades patent holders from using my code, or makes them tread much more carefully in how they interact, I see that as a benefit.

Here again, personally, I agree with your values 100%. I am not aware of a reason why patent holders specifically would be deterred from using Blue Oak code however, merely from contributing anything back to it. The concern as I understand it is the potential for the loss of one contributor's patent rights on the basis of another contributor's contribution. The license states:

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.

Contrast Apache 2.0, which clarifies that each contributor can only grant rights to their own patent:

Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.

I feel reasonably confident that courts would be unlikely to hold the view that one contributor could grant another contributor's patent rights away by infringing on a patent they don't hold. (After all, one might say that would be patently absurd.) I am slightly less certain however that an arbitrary court wouldn't interpret the license itself to be purporting such a claim (e.g., in the event that some licensor(s) and/or licensee(s) had advocated such an interpretation). At that point, I would have to delve a lot deeper to understand what might happen. To hazard a guess though, depending on the jurisdiction, the judge might then be obligated to strike the patent clause entirely, have greater leeway to interpret it as they see fit, or have either the power or obligation to strike down the license entirely and deem it unenforceable in that jurisdiction. This is simply something I came across while researching the license and did not factor significantly into my decision not to adopt Blue Oak software.

To my knowledge, it hasn't undergone any sort of public review process such as OSI approval.

I don't care that it isn't OSI approved. It has undergone quite a bit of public discussion, by people who I trust to make legal decisions, including lawyers I've retained in the past and whose integrity and insight I trust implicitly, and their position is that it's good, so that's enough for me.

That's good to hear that Blue Oak has been publicly reviewed. Do you happen to know where such a discussion took place? That might be a more appropriate venue for my feedback.

I understand that we might not all see eye to eye on these things, and reasonable people can disagree in good faith. As always, if BlueOak (or any license I choose) is a blocker for you, I am willing to offer a proprietary license with extremely flexible terms for a license fee equal to $50 per month per full time employee (or equivalent full time contractor/contributor). If this is of interest to you, let me know.

I appreciate the offer, but as I make no money from software development, I cannot afford such an arrangement. We do not and have never used any Blue Oak software, so ScribeMD/docker-cache is currently sitting on a ticking time bomb until a security vulnerability affects cacache v17.0.4, the last version of cacache that does not include a Blue Oak license in its dependency tree. At that point, if the security vulnerability were a credible concern, I would be forced to deprecate docker-cache if we could not find an alternative dependency tree to satisfy our needs.