... | @@ -141,14 +141,57 @@ Product. |
... | @@ -141,14 +141,57 @@ Product. |
|
|
|
|
|
#### Q: I find the section on patents a bit confusing. Can you explain to me in plain words what you are trying to achieve?
|
|
#### Q: I find the section on patents a bit confusing. Can you explain to me in plain words what you are trying to achieve?
|
|
|
|
|
|
|
|
The idea is the following: when I give you a set of design files
|
|
|
|
licensed under CERN OHL, I am promising you that I will not sue you for
|
|
|
|
infringing any of my patents when you use that design for all purposes
|
|
|
|
CERN OHL allows (studying, modifying, making hardware, selling it...).
|
|
|
|
This is meant to reassure you as a Licensee and therefore favour
|
|
|
|
adoption of designs licensed under the CERN OHL. Conversely, if you sue
|
|
|
|
me for patent infringement in that particular design, you will loose all
|
|
|
|
the rights I granted you in the licence. This two-way section on patents
|
|
|
|
is intended to provide for a much reassuring environment when it comes
|
|
|
|
to sharing hardware designs.
|
|
|
|
|
|
-----
|
|
-----
|
|
|
|
|
|
## Questions about practical use of the licence
|
|
## Questions about practical use of the licence
|
|
|
|
|
|
#### Q: What are all these suffixes?
|
|
#### Q: What are all these suffixes?
|
|
|
|
|
|
|
|
In the software domain, there are three generally acknowledged licensing
|
|
|
|
regimes for free and open source software: permissive, weak copyleft and
|
|
|
|
strong copyleft. There are tastes and use cases for each option, and the
|
|
|
|
same happens in hardware. We use the word "reciprocal" instead of
|
|
|
|
"copyleft" because the underlying rights in our case are not restricted
|
|
|
|
to copyright. So, when you use the licence, you need to add a Notice to
|
|
|
|
your designs with one of the three following suffixes: S, L or P:
|
|
|
|
|
|
|
|
- CERN-OHL2-S is a strongly reciprocal licence. For example, if you
|
|
|
|
release HDL files under CERN-OHL2-S and then somebody uses those
|
|
|
|
files in their FPGA, when they distribute the bitstream (either
|
|
|
|
putting it online or shipping a product with it) they need to make
|
|
|
|
the rest of the HDL design available under CERN-OHL2-S as well.
|
|
|
|
- CERN-OHL2-L is a weakly reciprocal licence. For the example above,
|
|
|
|
if you release your part of the design under CERN-OHL2-L, somebody
|
|
|
|
who distributes a bitstream which includes your part does not need
|
|
|
|
to distribute the rest of the design files as well.
|
|
|
|
- CERN-OHL2-P is a permissive licence. It allows people to take your
|
|
|
|
code, relicense it and use it without any obligation to distribute
|
|
|
|
the sources when they ship a product.
|
|
|
|
|
|
#### Q: How should I handle Notices?
|
|
#### Q: How should I handle Notices?
|
|
|
|
|
|
|
|
In general, it is good to keep notices in the design files as simple as
|
|
|
|
possible. For example, in your circuit schematics you can have in each
|
|
|
|
page a little square with a notice inside saying "Copyright XYZ, 2018
|
|
|
|
Licensed under CERN-OHL2-S". In the layout, you could have a similar box
|
|
|
|
in one of the documentation layers. Then, for more involved notices, you
|
|
|
|
can use a NOTICE text file in the top directory of the project. One
|
|
|
|
example of such more involved notices would be one where you specify
|
|
|
|
that you would like the final product to display the Source Location
|
|
|
|
(e.g. a URL) on it or its
|
|
|
|
packaging.
|
|
|
|
|
|
-----
|
|
-----
|
|
|
|
|
|
## Questions about Termination
|
|
## Questions about Termination
|
... | | ... | |