Hacker News Reader

CERN has published specific licenses for FPGA development, reviewed by lawyers and used by actual developers:

https://ohwr.org/project/cernohl/wikis/home

It takes your concerns in consideration, and much more. For FPGA the CERN-OHL-W is the usual one.

I addressed my concerns about the CERN license already. In particular the definition of "Convey" doesn't seem to apply unless you provide a product of some sort to a customer of some sort or release your source code as open-source. Hosted products and commercial use for internal purposes are arguably not covered under the copyleft parts of the license.

It does seem to be the least bad option, though, for most things.

> (FPGA and ASIC tools allow you to sequester the open source block in its own "compilation unit" and compiling that unit separately from the main system, only connecting the wires at the last steps)

The whole "compilation unit" stuff kind of reminds of the whole debacle with Nvidia (and many other linux driver vendors) creating a "generic" closed source driver, and a thin, useless, open source "shim" layer that connected the closed source driver to the GPL symbols of the kernel.

Needless to say, nobody was amused by this. It never went to court, but the linux kernel put various technical restrictions in place to prevent those shims from working. See these notes from kernel 5.9[0].

[0]: https://www.phoronix.com/news/Linux-59-Proprietary-Shim-Tain...

> GPL or LGPL - both of which are unclear how they apply in the case of ASIC and FPGA designs, particularly when you consider weird corner cases like partial reconfiguration (FPGA and ASIC tools allow you to sequester the open source block in its own "compilation unit" and compiling that unit separately from the main system, only connecting the wires at the last steps)

If the goal is to write a "pure" license (that only grants rights, and doesn't restrict any you already have without the license) and not a contract (eg EULA) it isn't really possible for there to be much clarity here. Because then the license only applies to derivative works (and exact copies), and the boundaries of that is entirely up to the courts to decide, not the license. Even for software, most of the common knowledge about where those boundaries occur (say when linking) hasn't been tested in court. All we know for certain are the things the license explicitly allows (like using system libraries).

The courts already threw us a curve ball by saying that APIs were eligible for copyright, and implementing them was a derivative work (albeit, usually one covered by fair use). I wouldn't be surprised if they threw some more.

You could look at MPL? https://www.mozilla.org/en-US/MPL/

I agree that hardware should have stronger copyleft requirements than code.

MIT/BSD has a place where you have a consortium or an org encouraging the ecosystem to maintain compatibility. The gain is that the ecosystem is compatible with a spec, so the whole is more important than each individual entity.

I just read the MPL, and if you look at the CERN license, you can see some of the problems with licenses like GPL and MPL.

In the software-oriented licenses, the lawyers who wrote them are very diligent to define things very clearly in software-specific terms, and then stop before defining those terms. It lets them keep the contract shorter and allow those definitions to change over time. For the GPL, this means taking the definition of "linking" for granted, and in the MPL, the definition of "larger work" pretty clearly seems to apply to only software:

A "Larger Work" is a work that "...combines Covered Software with other material, in a separate file or files, that is not Covered Software." In software land, this is fine because you distribute software in the form of files, but if you are distributing the Covered software as a piece of silicon, it's unclear whether that is a "larger work" or not, because the other material is not in a separate file at the point of distribution.

Here's the CERN "strongly reciprocal" license for reference, showing the difference between the software- and hardware-specific language:

https://spdx.org/licenses/CERN-OHL-S-2.0.html

The CERN license, by the way, has the opposite problem for FPGA code - it defines things in terms that really apply to physical stuff.

do you need to provide a license? who’s your target audience (end users and contributors) and how do you imagine their workflows looking?

you hint that maybe you don’t want commercial use of this thing: if you expect the person who `git clone`s your repository to be the same person that builds/assembles the product, you might also consider the option of just not providing any license. “code/build plans are freely accessible at some authoritative website/repo” might be license enough for anyone directly consuming the product, and a lack of license may be enough to scare away commercial use by any business which would adhere to your license in the first place.

nailing down a license would be most relevant if you want to facilitate some kind of cottage industry, or want to invite collaborators who don’t trust you and might be wary that you’ll turn around and commercialize their contributions against their desires (i find working in low-trust environments to be exhausting, but sometimes the benefits do outweigh the costs there).

That's a good point. I don't mind transformative commercialization, personally, but I do mind direct resale. The current application space is wide enough that there are a lot of forms of that, and none of the off-the-shelf licenses give that to me.

By the way, the application is a custom trusted enclave for the cloud inside an FPGA, which essentially means a bunch of processors with some custom cryptographic accelerators and application-specific programming.

I think I'm going to only end up releasing a few packageable subsets of it that do fit well with one of these licenses, like the processor core, for now. I probably won't be accepting contributions either way.