5 ms·

I have never heard that either but I guess that impression might come from the first line of the MIT license: > Copyright (c) <year> <copyright holders> Where

I have never heard that either but I guess that impression might come from the first line of the MIT license: > Copyright (c) <year> <copyright holders> Where <copyright holders> is often filled as the company of the primary developer, e.g. "Facebook". What I often see (and use) to avoid this, is filling it in with "The <project> developers", e.g. "The React developers".

kemitchell 8y ago
In the blog post linked above, I make the point that > Copyright the Project developers conveys zero information. Of course contributors to a software project hold copyright in it. Who else should? But who are those contributors? The Blue Oak Model embraces the practical reality: When we want to know contributed to an open software project, we look to development files and revision-control data, not the license.
foldr 8y ago
Ah I see, good point. I think management of code copyright is inherently complicated and not something that a license template can really fix. You do need to keep track of who has copyright of the code.
- velcrovan 8y ago
  The link I provided does explain this, under the section “MIT and BSD don’t expect more contributors”, which reads in part: “MIT and BSD terms include a space for a single copyright notice, because they were written for releases from academic institutions that own all the copyrights in their employees’ work. What about other contributors to the project? They hold copyright in their contributions.” Apache 2.0 DOES address this issue in a complicated way, through the supplementary use of Contributor License Agreements. Other non-Apache projects like Fossil also require you to physically sign a CLA before contributing code to the project. Blue Oak handles this in a more straightforward way, by explicitly saying that, as a condition of the license, every contributor in turn allows any use of their code that would otherwise infringe their copyright or patent claims. Who is a contributor? Anyone who contributes code. No CLA needed.
  - kemitchell 8y ago
    I don't think contributing back on Blue Oak terms is a condition of the Blue Oak Model License, in the sense of https://www.apache.org/licenses/LICENSE-2.0#contributions https://www.apache.org/licenses/LICENSE-2.0#contributions. Rather, the Blue Oak Model clearly expresses the expectation that all contributors will do so. Expressing that expectation in writing can help make a legal case that submitting a contribution for inclusion in the public project implies a license under the same terms. But that's a distant second best to creating a written, public record of each contributor's affirmative intent to license their work under Blue Oak Terms. That evidence doesn't have to look like a "formal" CLA. It could be as simple as a public comment on the PR: > I license my contributions under Blue Oak Model 1.0.0. It could be as simple as having contributors add their names to a THANKS or AUTHORS or CREDITS file in the repo, under a note that everyone licenses BlueOak-1.0.0, with Git commit data showing each contributor added their own name.
  - foldr 8y ago
    I don't know what is meant by "space" here. It's a text file. There's nothing to stop someone listing multiple copyright holders in an MIT license. In general, having a long list of copyright holders is bad, because it makes it almost impossible in practice to verify that all of the copyright holders actually consent to release their code under the relevant license.
    - velcrovan 8y ago
      He’s not implying that the space in the file is somehow limited. He’s pointing towards the same problem you are guesturing at in your second paragraph: that “listing” copyright holders really only makes sense when there is only one of them. Any more than that and you raise the legal question: who exactly has copyright on which parts? When there is more than one copyright holder, you absolutely need language to address that in the license. MIT license has no such language. Apache 2.0 addresses it by requiring CLAs, per-file copyright and attribution notices, etc. Blue Oak addresses it by using terms that start with "Each contributor".
      - 8y ago

kemitchell 8y ago

In the blog post linked above, I make the point that > Copyright the Project developers conveys zero information. Of course contributors to a software project hold copyright in it. Who else should? But who are those contributors? The Blue Oak Model embraces the practical reality: When we want to know contributed to an open software project, we look to development files and revision-control data, not the license.

foldr 8y ago

Ah I see, good point. I think management of code copyright is inherently complicated and not something that a license template can really fix. You do need to keep track of who has copyright of the code.

velcrovan 8y ago
The link I provided does explain this, under the section “MIT and BSD don’t expect more contributors”, which reads in part: “MIT and BSD terms include a space for a single copyright notice, because they were written for releases from academic institutions that own all the copyrights in their employees’ work. What about other contributors to the project? They hold copyright in their contributions.” Apache 2.0 DOES address this issue in a complicated way, through the supplementary use of Contributor License Agreements. Other non-Apache projects like Fossil also require you to physically sign a CLA before contributing code to the project. Blue Oak handles this in a more straightforward way, by explicitly saying that, as a condition of the license, every contributor in turn allows any use of their code that would otherwise infringe their copyright or patent claims. Who is a contributor? Anyone who contributes code. No CLA needed.
- kemitchell 8y ago
  I don't think contributing back on Blue Oak terms is a condition of the Blue Oak Model License, in the sense of https://www.apache.org/licenses/LICENSE-2.0#contributions https://www.apache.org/licenses/LICENSE-2.0#contributions. Rather, the Blue Oak Model clearly expresses the expectation that all contributors will do so. Expressing that expectation in writing can help make a legal case that submitting a contribution for inclusion in the public project implies a license under the same terms. But that's a distant second best to creating a written, public record of each contributor's affirmative intent to license their work under Blue Oak Terms. That evidence doesn't have to look like a "formal" CLA. It could be as simple as a public comment on the PR: > I license my contributions under Blue Oak Model 1.0.0. It could be as simple as having contributors add their names to a THANKS or AUTHORS or CREDITS file in the repo, under a note that everyone licenses BlueOak-1.0.0, with Git commit data showing each contributor added their own name.
- foldr 8y ago
  I don't know what is meant by "space" here. It's a text file. There's nothing to stop someone listing multiple copyright holders in an MIT license. In general, having a long list of copyright holders is bad, because it makes it almost impossible in practice to verify that all of the copyright holders actually consent to release their code under the relevant license.
  - velcrovan 8y ago
    He’s not implying that the space in the file is somehow limited. He’s pointing towards the same problem you are guesturing at in your second paragraph: that “listing” copyright holders really only makes sense when there is only one of them. Any more than that and you raise the legal question: who exactly has copyright on which parts? When there is more than one copyright holder, you absolutely need language to address that in the license. MIT license has no such language. Apache 2.0 addresses it by requiring CLAs, per-file copyright and attribution notices, etc. Blue Oak addresses it by using terms that start with "Each contributor".
    - 8y ago