3 ms·
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 t
by 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 agoI 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.