There is a chicken-and-egg problem with any new license, especially when the new terms aren't written for a specific, important release. But there's no improvi

There is a chicken-and-egg problem with any new license, especially when the new terms aren't written for a specific, important release. But there's no improving the situation for future projects without new terms. 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/list https://blueoakcouncil.org/2019/03/06/model.html 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 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-Harrington-Truth-About-OSS-FRAND.pdf http://stlr.org/wp-content/uploads/sites/2/2018/10/Kappos-Ha... http://stlr.org/wp-content/uploads/sites/2/2019/03/Lindberg.pdf 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.