[License-review] For Approval – CERN Open Hardware Licence Version 2– Strongly Reciprocal (SPDX: CERN-OHL-S-2.0); CERN Open Hardware Licence Version 2– Weakly Reciprocal (SPDX: CERN-OHL-W-2.0); CERN Open Hardware Licence Version 2– Permissive (SPDX: CERN-OHL-P-2.0)

[Javier Serrano]

Hello Josh,

On 11/19/20 5:38 PM, Josh Berkus wrote:
> On 11/19/20 7:26 AM, Andrew Katz wrote:
>> Many thanks for your question. CERN-OHL *can* be applied to software at the option of the licensor, but that is not a requirement. The suite of licences was written with the ability to license software in mind, and some licensors will want the simplicity of having the entire design - hardware and software - available under the same licence. However, we also recognise that this can create problems, and we do not want to tempt people away from the software commons which have coalesced around well-recognised copyleft/reciprocal licences, particularly GPLv2 and GPLv3.
> 
> So this approach of "you aren't MEANT to use them for software, but you
> CAN use them for software" creates some fundamental problems, and I'm
> not convinced that those problems are surmountable.
> 
> For example, you've set up this intricate maze of Source, Covered
> Source, Available Components, and Complete Source that's really quite
> hard to decipher, at least for a software geek like me.  When I check
> your FAQ, it offers me zero help or interpretation on these for normal,
> standard software situations; 100% of the guidance is about either
> designs, 3rd-party design software, or the actual hardware.  Firmware is
> not mentioned at all; the word doesn't even appear.
> 
> There's also that this kind of dependencies among various kinds of
> source may be common, and understood, in the Open Hardware world (is
> it?), but in the OSS world the terminology is all new and very confusing.

When drafting a reciprocal licence which works for hardware, we needed 
to come up with new concepts. Available Components is, among other 
things, our way to tell licensees that they don't need to publish the 
recipe to make a resistor if they include one in their PCB design. I see 
this can create a bit of confusion because these are indeed new terms. 
Let me try to give you some context which hopefully clarifies things a bit.

The W (weakly reciprocal) and S (strongly reciprocal) variants of CERN 
OHL v2 are not compatible with GPL, for reasons we explain in [1]. They 
may have their own merits in a pure software situation (somebody 
mentioned containers) but I think it would not be wise to recommend a 
GPL-incompatible reciprocal licence for software in general. The P 
(permissive) variant does not have this issue.

CERN OHL v2 W and S variants do fill a gap in many projects where people 
have traditionally used GPL and LGPL, namely gateware (HDL/FPGA/ASIC) 
projects. Gateware is quite problematic from a licensing perspective, 
and this may be why (I think) so far there has been no adequate 
reciprocal licensing scheme for it. With the amount of free and 
open-source gateware out there, I think this is an important issue, and 
we tried to address it with CERN OHL v2.

Gateware behaves like software when run in a simulator. I would say 
gateware *is* software when run in a simulator. When it is used as a 
basis from which to generate an FPGA configuration bitstream, or to 
build an ASIC, gateware does not behave as software. It does not run. It 
*becomes* a circuit. The licensing situation is made even harder when 
one considers that most HDL designs are fed to a proprietary tool chain 
and take proprietary components from that chain into the designs 
themselves. Available Components is also our way to deal with that 
reality and still maintain the reciprocal nature of the W and S variants.

The gateware use case is a central one for us. The lack of adequate 
weakly and strongly reciprocal options for HDL was one of the main 
reasons to draft v2 of the licence. I may have been a bit sloppy with my 
wording in the FAQ. What I meant by software was non-gateware software. 
To the extent that gateware is software, as explained above, I think 
CERN OHL v2 is not only applicable, but a licence I would very much 
recommend.

I realise this thread is more on whether the three variants are 
compatible with the OSD, but I thought I'd throw in this bit of context 
in case it can be useful.

Cheers,

Javier


[1] 
https://ohwr.org/project/cernohl/wikis/faq#q-is-cern-ohl-s-compatible-with-gpl