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

Greenbaum concludes:

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
process.

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.