In Open Source Semiconductor Core Licensing (pdf; summary) Eli Greenbaum considers when use of the semiconductor core designs under the GPL would make designs of chips and devices, and possibly physical objects based on those designs, trigger GPL requirements to distribute design for a derived work under the GPL.
It depends of course, but overall Greenbaum’s message for proprietary hardware is exactly the same as innumerable commentators’ messages for proprietary software:
- If you use any GPL work, be extremely careful to isolate that use in ways that minimize the chances one could successfully claim your larger work triggers GPL requirements;
- Excluding GPL work would be easier; if you want to incorporate open source works, consider only LGPL (I don’t understand why Greenbaum didn’t mention permissive licenses, but typically they’d be encouraged here).
The semiconductor industry has been moving further toward the use of independently developed cores to speed the creation of new devices and products. However, the need for robustly maintained and supported cores and the absence of clear rules and licenses appropriate for the industry’s structure and practice have stymied the development of an open source ecosystem, which might otherwise have been a natural outgrowth of the use of independently developed cores. The development of a context-specific open source license may be the simplest way to clarify the applicable legal rules and encourage the commercial use of open source cores.
That’s something like what John Ackermann wanted to show more generally for hardware designs in a paper I’ve written about before. Each leaves me unconvinced:
- If one wants copyleft terms, whether to protect a community or proprietary licensing revenue, use the GPL, which gives you plenty of room to aggressively enforce as and if you wish;
- If you don’t want copyleft terms, use a permissive license such as the Apache License 2.0 (some people understand this but still think version tweaked for hardware is necessary; I’m skeptical of that too).
Greenbaum does mention Ackermann’s paper and TAPR license and other “open hardware” licenses I previously discussed in a footnote:
While “open hardware” licenses do exist, they do not take account of many of the complexities of the semiconductor device manufacturing process. For example, the TAPR Open Hardware License does not address the use of technology libraries, the incorporation of soft cores in a device design, or the use of independent contractors for part s of the design
I think this highlights a difference of perspective. “Open hardware” people inclined toward copyleft want licenses which even more clearly than the GPL impose copyleft obligations on entities that build on copylefted designs. Greenbaum doesn’t even sketch what a license he’d consider appropriate for the industry would look like, but I’m doubtful that a license tailored to enabling some open collaboration but protecting revenues in industry-specific ways would be considered free or open by many people, or be used much.
I suspect the reason open hardware has only begun taking off recently (and will be huge soon) and open semiconductor design not yet (though for both broad and narrow categories people have been working on it for well over a decade) has almost nothing to do with the applicability of widely used licenses (which are far from ideal even for software, but network effects rule) and everything to do with design and production technologies that make peer production a useful addition.
Although I think the conclusion is weak (or perhaps merely begs for a follow-up explaining the case), Greenbaum’s paper is well worth reading, in particular section VI. Distribution of Physical Devices, which makes the case the GPL applies to such based on copyright, contract, and copyright-like restrictions and patent. These are all really important issues for info/innovation/commons governance to grapple with going forward. My hope is that existing license stewards take this to heart (e.g., do serious investigations of how GPLv3+ and Apache 2.0 can be best used for designs, and take what is learned and what the relevant communities say when in the fullness of time the next versions of those licenses are developed; the best contribution Creative Commons can probably make is to increase compatibility with software licenses and disrecommend direct use of CC licenses for designs as it has done for software) and that newer communities not operate in an isolated manner when it comes to commons governance.
[…] Of the dystopian stories, Solís is probably most dystopian, Eddie most humorous, and Betteridge overall best executed. Żyła needs a bit of development — the trend posited is incongruous and unexplained — but maybe due to an unknown factor to be suggested by fictional future freakonomics, or perhaps I just missed it. Melin ends with some hope, but annoys me for contemporary reasons — why would the recipient of a body part artificially grown with “open” methods be constrained in the disposition of that part by a “Creative Commons license” on those methods? Another reason to discourage use of CC licenses for hardware design. […]
[…] incompatible terms are GPLv2-only and EPL. But software is suffusing everything, including hardware design, cultural/scientific/documentation works, and data. I hope to see major progress toward eliminating […]
[…] that try to make the case for new hardware design licenses, and as far as I can tell they both fail. But, as far as I know no FLOSS establishment institution has proclaimed the correctness of using […]
[…] Perhaps some potential licensor will be reassured, but I consider this unnecessary and slightly harmful, replicating the main deficiency of CC0. The explicit exclusion makes it harder to see an implied license. This is especially troublesome when CC licenses are used in fields in which patents can serve as a barrier. Software is one, for which CC has long disrecommended use of CC licenses largely because software is already well-covered by licenses with which CC licenses are mostly incompatible with; the explicit patent exclusion in the CC 4.0 licenses makes them even less suitable. Hardware design is another such field, but one with fragmented licensing, including use of CC licenses. CC should now explicitly disrecommend using CC licenses for hardware designs and declare CC-BY-SA-4.0 one-way compatible with GPLv3+ so that projects using one of the CC-BY-SA licenses for hardware designs have a clear path to a more appropriate license. […]