Evaluate BlueOak License

[bensternthal]

This issue tracks the legal evaluation of the BlueOak license https://blueoakcouncil.org/license/1.0.0

Tasks

Beta Give feedback

1. Update https://github.com/openjs-foundation/cross-project-council/edit/main/governance/IP_POLICY_GUIDANCE.md
2. Update https://ip-policy.openjsf.org/

[tobie]

What's the context for this? It's not an OSI-approved license and has very low usage.

[MylesBorins]

transitive dependencies in npm, and a variety of other JS projects, were relicensed (legally) as Blue Oak.

nodejs/node#49625

It is going to be very difficult to untangle this, much easier if OpenJS take a supportive position on the license

[tobie]

I'm going to repeat what I said in the Node issue itself: the first step would be to get the license approved by OSI. (The process is here: https://opensource.org/licenses/review-process/.)

OpenJSF shouldn't substitute itself to OSI's process. That would be setting a really bad precedent.

[MylesBorins]

OpenJSF shouldn't substitute itself to OSI's process. That would be setting a really bad precedent.

If the OpenJS position is that only OSI approved licenses are allowed, that would allow for clarity. What I'd like to see is clarity on what is / is not allowed

[MylesBorins]

FWIW I did a quick evaluation of other OpenJS Impact projects

Every single one of the projects rely on glob, the package that is dependent on packages licensed as blue-oak.

Appium, Node.js, and Electron all depend on version of glob that include a dependency with a blue oak license.

I haven't looked into at large or incubation projects but I'm sure this is going to be pervasive within OpenJS as well as the ecosystem at large (a recent example from angular.

So I do want to point out that if OpenJS wants to take a position that it does not allow the blue oak license, specifically as it isn't OSI approved, we are going to have a fairly extensive ecosystem problem due to glob. I want to be clear that I do not think that licensing or legal opinions should be made based on this kind of adoption, but I did want to show that this isn't specifically an npm problem.

[mhdawson]

@bensternthal how long do we think it might take to get a legal opinion from our OpenJS lawyers on BlueOak and the risk given the current situation.

While Blueoak is not on the OSI approved list is it on other lists like the Fedora allowed licences list - https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ so it might be an ok licence, and a path forward might be to for the OpenJS Foundation to propose it for OSI approval with an exception until that approval happens.

[mcollina]

@mhdawson that looks the best possible outcome, but I just want to hear what our lawyers would say on the topic. Then, it's up to the Board to approve it.

We have a meeting early next week.

[tobie]

I would argue that this is not a legal issue. The Blue Oak license has been written by three of the top open source lawyers in the world, I'm fairly convinced they know what they're doing.

This is a community issue.

Standing behind a commonly accepted open source definition and license review process is critical, particularly with all of the current policymaker attention on open source.

---

If Fedora has put it on its allow-list and there's a number of high profile JS dependencies using it, getting it approved shouldn't be too difficult.

I did it for a client for the MIT-0 license a while back. Here's what it looked like:

• Initial conversation prior to making the request: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-April/021754.html
• The request itself: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-May/004856.html
• Recommendation to the Board from the License Committee: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-August/004915.html
• Board minutes: https://wiki.opensource.org/bin/Main/OSI%20Board%20of%20Directors/Board%20minutes/2020/2020-08-14/
• Notice of approval from the board: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-August/004917.html
• Here's the license page: https://opensource.org/license/mit-0/

I submitted it May 15, 2020. It got approved August 14, 2020, so right under 3 months.

The process isn't a huge deal. Someone just needs to step up and do it.

My understanding from @MylesBorins's comment is the license has been in Node since March, so the urgency is relative. I'm also noticing from @UlisesGascon's comment on the same thread that there are other transitive dependencies with similar issues. Maybe we should looking at making a generic policy for dependencies, rather than handling this as a one-off.

[tobie]

@MylesBorins wrote:

I want to be clear that I do not think that licensing or legal opinions should be made based on this kind of adoption, but I did want to show that this isn't specifically an npm problem.

Actually, adoption is an important criteria of the legacy license approval request (which is arguably the right pick for this license):

Identify what projects are already using the license.
[…]
Provide any additional information that the submitter believes would be helpful for license review. For example, approval of the license by Debian, the FSF or the Fedora Project would be relevant to the review process.

[tobie]

I want to take a step back, here, and roll back some of my comments.

The IP Policy is quite clear about what the process is in a situation like this one:

If an alternative inbound or outbound license is required for compliance with the license for an
Upstream Project or is otherwise required to achieve the OpenJS Foundation’s, or an individual
Project’s, objectives, the Board may approve the use of an alternative license for inbound or
outbound contributions on an exception basis. Please email info@openjsf.org to obtain exception
approval.

The Board is sovereign to make those decisions and the CPC really shouldn't have been involved. It's a different matter altogether for the OpenJS Board to decide what level of IP risk it is OK with in the dependencies of its projects, and for the CPC to be "evaluating" a license. Clearly we are in the former situation here, not the latter, as I was initially led to believe.

Although I do think that OSI certification should be pursued if the Blue Oak license is getting broad adoption, I no longer believe the board's decision should be contingent to that process being started nor that anyone involved in the Node project should feel responsible or compelled to get that process started.

Imho, this issue should be closed and the Node project should get Board approval directly through the foundation as per the IP policy and without involving the CPC.

Sincere apologies for the stress I must have caused to some of you.

[ljharb]

There are many board decisions where CPC input is valuable, and I don't think it'd be ideal to imply that it's somehow wrong for anyone to seek the CPC's input on what ultimately is a Board decision.

[bensternthal]

Apologies if I created churn with this issue. I did want to capture that I was reaching out to our legal council for advice on this one.

[tobie]

There are many board decisions where CPC input is valuable, and I don't think it'd be ideal to imply that it's somehow wrong for anyone to seek the CPC's input on what ultimately is a Board decision.

Right, I agree. I do think that there's a significant difference for this particular case as to whether this is a one-off decision made by the Board or an official, publicly documented policy from the Foundation with CPC input.

[tobie]

Apologies if I created churn with this issue. I did want to capture that I was reaching out to our legal council for advice on this one.

All good. More context and a less ambiguous title would have been helpful. Regardless, I jumped the gun.

[mcollina]

The recommendation we got from the OpenJS lawyer is that if it seems that there is no reason it shouldn't be approved, we could accept the contribution conditional on their submitting their license for approval, and then swap out the code if the approval is not given by OSI.

This seems a pretty reasonable approach.

[MylesBorins]

@mcollina who is submitting the license for approval? The contribution itself is not coming as Blue Oak, it is a transitive dependency. The developer who has licensed their code as Blue Oak is not involved in the Node.js or npm project at all.

IMHO it would be great if the OpenJS foundation could help with stewarding the Blue Oak license through the OSI process, especially considering the breadth of adoption we are seeing due to the widespread usage of glob.

[mcollina]

Technically it's vendored via npm and it's part of the npm source code.

[MylesBorins]

Pointing back to this comment

Other OpenJS projects are impacted, and more will be in the future. I'd be happy to have an internal conversation about what we are capable of doing here, but I'd much prefer this to be a collaboration rather than putting the onus entirely on npm. This is an ecosystem problem, not an npm problem.

[tobie]

I detailed all steps in the process, offered a example for each step based on a similar license that I had submitted in the past (and that had been approved), gave a timeline, and offered to mentor (for free) whoever was going to lead this (as part of my volunteer role as OpenJSF representative to OSI). I don't think it's fair to say that this is putting the onus entirely on NPM.

Frankly the time commitment is small given the broad adoption you're mentioning and the fact that it already has been recognized by Fedora. I'd do it pro bono if NPM was a nonprofit, but it's not. It wouldn't be fair to my other clients, to the maintainers of those dependencies, or to other practitioners for me to do this work for free for Microsoft. So mentoring through my volunteer OSI role in the foundation is the best I can offer.

[ljharb]

As a community issue, if glob is using a non-OSS license, then either that license needs to become OSI-approved, making it "open source", or the community needs to migrate off of glob to something else. The latter would mean that in the meantime, each affected project would need to downgrade their glob version to one that's actually Open Source, including npm.

[MylesBorins]

@rginn I'd like to request that the board consider make an exception for the blue oak license for dependencies of OpenJS projects. If we can get a single sign off for Blue Oak dependencies, which should not be controversial for a permissive license, we will be covered for all potential issues without expanding the scope to OpenJS projects adopting Blue Oak itself.

Going to another organization and taking the license through an approval process is a large task and not one I feel comfortable committing to.

[rginn]

I support this license exception recommendation. We will put this on our Board agenda for our September meeting on Monday, Sept 18. Note: this will also need to go through our Member Legal Counsel, which we will schedule for review.

[tobie]

I'd like to request that the board consider make an exception for the blue oak license for dependencies of OpenJS projects.

As mentioned, requesting board approval for an exception is the required path forward regardless of whether or not the license is taken through the OSI process.

Going to another organization and taking the license through an approval process is a large task and not one I feel comfortable committing to.

Also as mentioned I'm happy to mentor you (or someone else from the community) through the process. It's fairly straightforward given the context. It would be a shame to start setting precedent here.

[jsumners]

I support this license exception recommendation. We will put this on our Board agenda for our September meeting on Monday, Sept 18. Note: this will also need to go through our Member Legal Counsel, which we will schedule for review.

Is there a place to read the result of the discussion?

[mcollina]

The discussion happened in the private section, and given how long it took we did not have a public section. Passing this license exception requires a meeting of the foundation member legal counsel. It'll be scheduled in the coming weeks (roughly after @rginn is back in the states in October).

[rginn]

The Blue Oak License has been submitted to OSI for consideration as an OSI-approved license. http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2023-November/005441.html

We appreciate the support of the license authors for this submission that will help the JavaScript ecosystem. Special thanks to Luis Villa @tieguy for his collaboration with OpenJS and OSI, and for a thoughtfully prepared submission at our request.

You can subscribe to the OSI License-review list to track the progress. https://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org

I also will keep you updated in this issue.

[jsumners]

Thank you for the update. I look forward to seeing it included.

[lukeed]

Update: Blue Oak is OSI approved as of Jan 19, 2024

[tobie]

Thanks to all involved making this happen, with special thanks to @tieguy for taking the license through OSI's process.

[tobie]

This still needs Board approval, which my understanding is that it should happen shortly. We should keep this open until then.

[bensternthal]

The board has approved the Blue Oak Model License 1.0.0.

[tobie]

Congrats all!

[rginn]

Thanks again Luis Villa and Stefano Maffulli for your time and support!

[bensternthal]

Closing, all docs updated.