Add cern ohl v2

[julianstirling]

This PR contains all the commits from #854 adding the CERN-OHL v2 family of licenses. (See also the discussion in issue/fixes #853)

This remains a draft whilst we check and tweak the "how" field

Requirements

1. The license must have an SPDX identifier. If your license isn't registered with SPDX, please request that it be added.

• CERN-OHL-P-2.0
• CERN-OHL-S-2.0
• CERN-OHL-W-2.0

2. The license must be listed on one of the following approved lists of licenses:

• CERN-OHL-P-2.0
• CERN-OHL-S-2.0
• CERN-OHL-W-2.0

3. The license must be used in at least 1,000 public repositories. This may be documented, for example, with a GitHub code search.

As noted in #853, there are a considerable number of projects using the CERN-OHL family of licenses.

This requirement appears to be to show the license is notable enough for inclusion. As the Open Hardware community is still settling on how best to share hardware, this increases the number of platforms that need to be searched. We provide the following further considerations:

1. The CERN OHL family is recommended by the Open Source Hardware Association
2. The CERN OHL family is recommended by journals such as HardwareX and Journal of Open Hardware
3. Inclusion of CERN OHL as the first OSI approved hardware specific licenses was deemed newsworthy by a major tech news website

4. 3 notable projects using the license must be identified. These must have straightforward LICENSE files which serve as examples newcomers can follow and that could be detected by licensee if it knew about the license.

As discussed in #854 this PR updates the projects.

[j-sp]

FWIW, this project took special care to properly apply the guidelines to use the S variant of the license (see discussion). The guidelines are quite long. I will try to extract the main features for the how field of the YAML files.

[j-sp]

Some proposed changes here. In general, I like the way @nytpu used the note field to refer the the user guide of each variant. I just added a quick reference to the disclaimer of warranties which can be important for hardware, and the source location which ultimately can help the recipient of a piece of hardware find the design for that object. I also propose to avoid using the term "viral" which can have a negative connotation.

[mlinksva]

@j-sp your proposed changes look fine to me. I'd recommend shortening a bit by making the word "recommends" be link text (with the link being the one in the next sentence) and deleting the next sentence.

[j-sp]

Thanks @mlinksva, done. @julianstirling, tell me if there is anything else I can help with.

[julianstirling]

Thanks @j-sp I have added your commits to the PR. I think this should be ready once the checks complete.

[julianstirling]

I get lots of errors when I run locally but I fixed the specific one that seemed to fail on the CI

[julianstirling]

I think this is ready to go? 🎉

[mlinksva]

Two comments on the description, replicated across the 3 variants:

The CERN OHL was drafted with hardware in mind.

Make plural as there is no "the CERN OHL", and "with hardware in mind" is redundant, it's in the name. Maybe there's a way to address this and segue into below fix:

On top of licensing copyright like software and documentation licenses, it also licenses patents.

Is there another way to characterize the difference? Most software licenses of a similar vintage also license patents.

[j-sp]

Thanks @mlinksva. If we need to better characterize the difference with respect to other licenses, I'd go for a separate description for each variant. In the case of the S variant, I'd propose:

The strongly reciprocal variant of the CERN OHL v2 was drafted with hardware in mind, using language which hardware designers can easily relate to. It covers rights other than copyright, features two-way patent licensing and provides methods to ensure the recipient of a piece of hardware can find the original design files. It was carefully drafted to achieve a strongly-reciprocal effect even in cases where the use of proprietary design tools and components, quite frequent in hardware design, would make a strong copyleft software license not usable.

I realize this is very long. See https://youtu.be/6wvEgQ5iWoc?t=1490 for the rationale. Let me know if I should attempt to condense it, and to which extent.

[j-sp]

For the W variant, I'd propose:

The weakly-reciprocal variant of the CERN OHL v2 was drafted with hardware in mind, using language which hardware designers can easily relate to. It covers rights other than copyright, features two-way patent licensing and provides methods to ensure the recipient of a piece of hardware can find the original design files. It was carefully drafted to achieve a weakly-reciprocal effect for hardware, taking into account the specificities of typical hardware design tools and workflows.

[j-sp]

And for the P variant:

The permissive variant of the CERN OHL v2 was drafted with hardware in mind. It covers rights other than copyright, and features two-way patent licensing. It was carefully drafted to achieve an effect similar to that of permissive software licenses, using language hardware designers can unequivocally relate to.

[julianstirling]

@mlinksva, I am happy to add the text that @j-sp has suggested to each of the three licenses if we are all agreed.

On the point of if "with hardware in mind" is redundant... it largely is but it is also a point I think that is worth stressing and it is hard to stress well without redundancy. In the open hardware community we see many people new to the field applying software licenses to hardware, even ones with software in the name!

[waldyrious]

...drafted to achieve a strongly-reciprocal effect...

...drafted to achieve a weakly-reciprocal effect for hardware...

...drafted to achieve an effect similar to that of permissive software licenses...

If these new paragraphs are meant to replace the current description field, I'd like to point out that repeating the expressions "strongly reciprocal" and "weakly reciprocal" and "permissive" is not very useful, since those terms are already present at the start of each paragraph. I think the current wording is much clearer and more explicit:

...applies to a complete design, so if a CERN-OHL-S-2.0 file is used in a project then the full project must be released under the CERN-OHL-S-2.0 (or a compatible license).

...applies to individual designs but does not spread to the entire project it is included in.

...allows people to take your code, relicense it and use it without any obligation to distribute the sources when they ship a product; however, it does have an attribution requirement.

I understand you are trying to condense the text, but I believe in this case the additional length might be worth the clarity that describing these properties explicitly brings.

[j-sp]

Thanks @waldyrious, I fully see your point. If clarity is key and space is not an issue, how about this for the S variant?

The strongly-reciprocal variant of the CERN OHL v2 was drafted with hardware in mind, using language which hardware designers can easily relate to. It covers rights other than copyright, features two-way patent licensing and provides methods to ensure the recipient of a piece of hardware can find the original design files. It was carefully drafted to achieve a strongly-reciprocal effect even in cases where the use of proprietary design tools and components, quite frequent in hardware design, would make a strong copyleft software license not usable (e.g. in HDL/FPGA design). This variant applies to a complete design, so if a CERN-OHL-S-2.0 file is used in a project then the full project must be released under the CERN-OHL-S-2.0 (or a compatible license).

[waldyrious]

I'm not a maintainer of this project, but IMHO I'd rather have the information explicitly stated, yeah. My only suggestion would be to connect the last sentence with what comes before, e.g.

This variant therefore applies to a complete design...

or

As such, this variant applies to a complete design...

(or some variant thereof). But that's a minor point — let's see what @mlinksva thinks about the overall expansion before bikeshedding the text :)

[mlinksva]

I'll review again when I have a block of free time later in the week -- the descriptions, and want to make sure I understand the permissions/conditions/limitations for each license are appropriate since these are relatively novel among the licenses we have cataloged.

My bias is brevity for the descriptions, and avoiding subjective statements like "carefully drafted" but feel free to bikeshed further if you feel like it. 😄 Many thanks for getting this PR into shape!

[j-sp]

Small refinements to the proposed texts, hopefully capturing the suggestions of @waldyrious and @mlinksva except for brevity. We should be able to shorten them if needed.

S variant:

The strongly-reciprocal variant of the CERN OHL v2 was drafted with hardware in mind, using language which hardware designers can easily relate to. It covers rights other than copyright, features two-way patent licensing and provides methods to ensure the recipient of a piece of hardware can find the original design files. It was drafted to achieve a strongly-reciprocal effect even in cases where the use of proprietary design tools and components, quite frequent in hardware design, would make a strong copyleft software license not usable (e.g. in HDL/FPGA design). This variant therefore applies to a complete design, so if a CERN-OHL-S-2.0 file is used in a project then the full project must be released under the CERN-OHL-S-2.0 (or a compatible license).

W variant:

The weakly-reciprocal variant of the CERN OHL v2 was drafted with hardware in mind, using language which hardware designers can easily relate to. It covers rights other than copyright, features two-way patent licensing and provides methods to ensure the recipient of a piece of hardware can find the original design files. It was drafted to achieve a weakly-reciprocal effect for hardware, taking into account the specificities of typical hardware design tools and workflows. It therefore applies to individual designs but does not spread to the entire project it is included in.

P variant:

The permissive variant of the CERN OHL v2 was drafted with hardware in mind. It covers rights other than copyright, and features two-way patent licensing. It was drafted to achieve an effect similar to that of permissive software licenses, using language hardware designers can unequivocally relate to. It therefore allows people to take your design, relicense it and use it without any obligation to distribute the sources when they ship a product; however, it does have an attribution requirement.

[julianstirling]

@mlinksva, sorry to pester. If you are happy with the wording above I'll move it into the PR. If your preferred workflow is me just to commit these changes and look again I can do that. I am just conscious that you might not want loads more commits whilst the language is tweaked.

[mlinksva]

The metadata looks ok, though I wonder if W variant's "external material" is really closer to same-license--file than same-license--library given that it may only be combined using the covered source's documented interfaces.

The text looks identical to the versions on the CERN site, which I imagine it is from. Not to address here, but noting there are some very small differences between that text and what is recorded in SPDX, particularly the capitalization of modifying in section 3 (all), the spelling of licen[cs]e in 7.1 (S and W, 6.1 in P), and in P the placement of You in 3.4. Might make sense to correct in SPDX.

[mlinksva]

The descriptions in the comment above are longer than any currently; I should add a test limiting to 500 characters, which is longer than any in the repository now. The ones in committed are closer. I don't really care about whether things are worked out in comments or commits, but I'll go ahead and make suggestions as a review.

[mlinksva]

Misc suggestions, not strongly attached to them.

[j-sp]

I agree about changing from same-license--file to same-license--library in the W variant. The spirit of the license text is more about interfaces than about files. This can cover cases where the proprietary bit is a small component in an otherwise larger W design, so the library metaphor would not really apply, but neither would the file one. I believe library is a closer match.

[mlinksva]

Thanks for all the pointers @j-sp. I think this is ready to merge and will do so soon, but feel free to propose further tweaks either before or after.

[j-sp]

Thanks @mlinksva, I just noticed an extra space after the comma in the file for the P variant of the licence: "A permissive license for hardware designs, with". All the rest looks good to me.

[julianstirling]

Great to see this merged! Thanks all!