4 ms·

At first glance it Blue Oak seems like a decent license, and the points he makes about MIT and BSD seem valid. My major issue with adopting a new license howev

At first glance it Blue Oak seems like a decent license, and the points he makes about MIT and BSD seem valid. My major issue with adopting a new license however is how well known it probably isn't, so there is not yet a clear legal consensus on it. In all software companies I've worked in there is a clear list of licenses that have been pre-approved and I can just log the inclusion of any open source using those licenses and everything is fine. However, if I want to use anything not already on the list it requires a manual approval process from the legal department, which is usually time consuming, and often just results in a 'no' because they are too risk averse to asses the licenses properly themselves, but are happy relying on the consensus that licenses like MIT and BSD are OK for commercial use. Edit to add: Also, while a lot of his crtisisms of MIT seem valid points about uncertainty 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. If I see an MIT license, I can basically know I can do whatever I want with it, provided I give attribution, and there is no warrenty. I'm not going to worry about being sued over someone's interpretation of "deal in the software" because AFAIK, that has never happened in the 40+ years the license has been in use. 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. The only really substantial point he makes is about variants under the same name, but the lesson here is to just do a diff on licenses to check it's in the standard form. 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.

kemitchell 8y ago
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.

kemitchell 8y ago

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.