[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)

[Florian Weimer]

* Pamela Chestek:

> I am reading a problem with OSD 9 for the Strong Reciprocal version only.
>
> It starts with Section 4 which says "You may Make Products and/or Convey 
> them, provided that You ... provide each recipient with a copy of the 
> Complete Source .... That Complete Source /*is*/ Covered Source ...." 
> (emphasis added).
>
> The problem is that Complete Source includes source that may be an 
> independent component under a different license. Complete Source 
> (section 1.8) is "the set of all Source necessary to Make a Product 
> ...." To Make (section 1.6) means "to create or configure something, 
> whether by manufacture, assembly, compiling, loading, or applying 
> Covered Source to another Product or otherwise." If I use a proprietary 
> complier then that is Making, and the code for the compiler is part of 
> the Complete Source, which according to section 4 is also Covered 
> Source, i.e., it must be licensed under the CERN-OHL-S-2.0 license. This 
> reach-through to militate a specific license for software that is not a 
> derivative work in my opinion violates OSD 9 (although I'd be curious 
> whether others agree - keeping in mind that is the complaint about 
> licenses like SSPL).

SSPL had the problem that the requirement also applied to the
operational environment, which contains things like network interface
cards, switches, load balancers, and so on—things that run code for
which corresponding source code is usually not readily available.  To
me, it looked like it was designed to create legal uncertainty,
similar to many uses of the AGPL in totally inappropriate contexts (as
“the GPL variant for an open-core business model”).  I think the
Strong Reciprocal version does not exhibit this because there is a
clear and not particularly onerous path towards compliance (unless the
software is written in a language that only has proprietary
implementations, in which case we are in uncertain areas again).  The
fact that you can do Something and that Something may make it
non-obvious whether you are still compliant is not a problem with the
license, in my opinion.  (Any progam under a strong copyleft license
that offers a plug-in system or a scripting capability raises similar
issues, for example.)

To me, the more appropriate comparison is the Open Motif license,
which has this clause:

| The rights granted under this license are limited solely to
| distribution and sublicensing of the Contribution(s) on, with, or
| for operating systems which are themselves Open Source programs.

<http://www.opengroup.org/openmotif/license/>

Historically, this was rejected as an open-source license.  I don't
know why, and the recent discussion about it did not entirely convince
me that there is actually a case for rejection.  To me, this looks
like a historical oddity, but that seems to be an isolated opinion.
But if one rejects the Open Motif license, I think one would have to
reject the Strong Reciprocal variant as described above, too.

But going back one step: For an open *hardware* license, this “open
stack” requirement can actually be rather onerous, given that
availability of design tools is still limited.  The license itself has
some weasel words under 1.7 (b) that seem to acknowledge this.  So I
need to take back in part what I wrote earlier—in the context of
hardware, the need for proprietary build tools creates uncertainty
that appears comparable to the effect of the SSPL.