5 ms·

Interesting that it's both patented and under LGPLv3/GPLv3 (unclear which applies), seems like a way to avoid non-FOSS/proprietary implementations although I wo

by f_devd 4y ago

Interesting that it's both patented and under LGPLv3/GPLv3 (unclear which applies), seems like a way to avoid non-FOSS/proprietary implementations although I would think releasing it as regular GPLv3 would already serve as prior art under patent law, IANAL but would love to know.

pclmulqdq 4y ago
OSH licenses for FPGA code are a total mess. I am working on some hardware that I plan to open source very soon, but figuring out what license to use is extremely difficult. My options seem to be: * Start with CC-BY-NC that pretty clearly disallows commercial use in any way and punt on the question (or allow commercial users to pay a nominal fee for a commercial license) * 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) * CERN OHLv2 license of some kind, which seems to give up its copyleft provisions on things that don't involve giving stuff to a customer * MIT/BSD A lot of folks in hardware are not particularly interested in going for the MIT/BSD route because of the commercial nature of IP cores. It essentially allows a random firm to repackage your IP and sell it as their own (usually for a shit load of money - hardware licenses are often 5-6 figures).
- sitkack 4y ago
  You could look at MPL? https://www.mozilla.org/en-US/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.
  - pclmulqdq 4y ago
    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 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.
- roblabla 4y ago
  > (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-Taint https://www.phoronix.com/news/Linux-59-Proprietary-Shim-Tain...
- aylons 4y ago
  CERN has published specific licenses for FPGA development, reviewed by lawyers and used by actual developers: https://ohwr.org/project/cernohl/wikis/home 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.
  - pclmulqdq 4y ago
    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.
- pavon 4y ago
  > 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.
- colinsane 4y ago
  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).
  - pclmulqdq 4y ago
    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.
ooterness 4y ago
Lead developer here. The license is LGPLv3; sorry for any confusion. The Aerospace Corporation specifically wanted a weak copyleft license for SatCat5. i.e., If you use it as-is in a larger design, great; if you modify it, please make those improvements available to the wider community. A full GPL license would have imposed copyleft obligations on the rest of the end-user design, and we felt that was too much of a barrier for industry adoption. Our intent is to capture improvements to SatCat5 itself and only those improvements. Others here have mentioned that terms like "compilation unit" are ambiguous at best in an FPGA or ASIC design, and I fully agree. Sadly, there just weren't a lot of widely-known, weak-copyleft options when we were making that decision in mid-2019. The good news is this isn't set in stone and it can be changed. CERN-OHL-W 2.0 wasn't around when we first published this in 2019, but I'll take a close look and see if that's a better fit.

by f_devd 4y ago

pclmulqdq 4y ago

OSH licenses for FPGA code are a total mess. I am working on some hardware that I plan to open source very soon, but figuring out what license to use is extremely difficult. My options seem to be: * Start with CC-BY-NC that pretty clearly disallows commercial use in any way and punt on the question (or allow commercial users to pay a nominal fee for a commercial license) * 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) * CERN OHLv2 license of some kind, which seems to give up its copyleft provisions on things that don't involve giving stuff to a customer * MIT/BSD A lot of folks in hardware are not particularly interested in going for the MIT/BSD route because of the commercial nature of IP cores. It essentially allows a random firm to repackage your IP and sell it as their own (usually for a shit load of money - hardware licenses are often 5-6 figures).

sitkack 4y ago
You could look at MPL? https://www.mozilla.org/en-US/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.
- pclmulqdq 4y ago
  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 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.
roblabla 4y ago
> (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-Taint https://www.phoronix.com/news/Linux-59-Proprietary-Shim-Tain...
aylons 4y ago
CERN has published specific licenses for FPGA development, reviewed by lawyers and used by actual developers: https://ohwr.org/project/cernohl/wikis/home 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.
- pclmulqdq 4y ago
  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.
pavon 4y ago
> 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.
colinsane 4y ago
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).
- pclmulqdq 4y ago
  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.

ooterness 4y ago

Lead developer here. The license is LGPLv3; sorry for any confusion. The Aerospace Corporation specifically wanted a weak copyleft license for SatCat5. i.e., If you use it as-is in a larger design, great; if you modify it, please make those improvements available to the wider community. A full GPL license would have imposed copyleft obligations on the rest of the end-user design, and we felt that was too much of a barrier for industry adoption. Our intent is to capture improvements to SatCat5 itself and only those improvements. Others here have mentioned that terms like "compilation unit" are ambiguous at best in an FPGA or ASIC design, and I fully agree. Sadly, there just weren't a lot of widely-known, weak-copyleft options when we were making that decision in mid-2019. The good news is this isn't set in stone and it can be changed. CERN-OHL-W 2.0 wasn't around when we first published this in 2019, but I'll take a close look and see if that's a better fit.