|
|
This page is a container serving as a basis for communication during the
|
|
|
CERN OHL v2 drafting process. It has the [draft
|
|
|
text](https://www.ohwr.org/5993)
|
|
|
attached, as well as an embryo of the Frequently Asked Questions which
|
|
|
will accompany the release. There is also an [explanatory
|
|
|
document](https://www.ohwr.org/5994)
|
|
|
to provide some context for our decisions and make understanding of the
|
|
|
draft text easier.
|
|
|
drafting process of the next version of CERN OHL. Our current choice is
|
|
|
to split the licence in three:
|
|
|
|
|
|
# Frequently Asked Questions about CERN OHL v2
|
|
|
- A permissive licence called CERN-OHL-P (see draft)
|
|
|
- A weakly reciprocal licence called CERN-OHL-L (see draft)
|
|
|
- A strongly reciprocal licence called CERN-OHL-S (see draft)
|
|
|
|
|
|
There was a demand for a permissive option in CERN OHL, and including it
|
|
|
as an exception in the main licence text proved a bit cumbersome. Once
|
|
|
we decided to split P, it also made sense to split L and S. Below, we
|
|
|
try to anticipate some questions and provide answers. There is also a
|
|
|
rationale document which further explains our intentions and the
|
|
|
mechanisms we have put in place to fulfil them in the licence texts.
|
|
|
Therefore, there are in total five documents you can use in the process
|
|
|
of contributing feedback to this drafting process: the three licence
|
|
|
drafts, this FAQ and the rationale document.
|
|
|
|
|
|
In the FAQ below, we use the term "CERN OHL" when we refer generically
|
|
|
to the three licences.
|
|
|
|
|
|
# Frequently Asked Questions about CERN OHL
|
|
|
|
|
|
|
|
|
-----
|
|
|
|
|
|
## CERN OHL v2 general questions
|
|
|
## CERN OHL general questions
|
|
|
|
|
|
#### Q: What does CERN OHL v2 try to achieve?
|
|
|
#### Q: What does CERN OHL try to achieve?
|
|
|
|
|
|
A: The CERN Open Hardware Licence aims at providing a solid legal basis
|
|
|
for the sharing of hardware designs. In version 2, we intend to give
|
|
|
for the sharing of hardware designs. In this release, we intend to give
|
|
|
Licensors different options for the sharing mechanism: strongly
|
|
|
reciprocal, weakly reciprocal and permissive.
|
|
|
|
|
|
#### Q: What is the scope of CERN OHL v2?
|
|
|
#### Q: What is the scope of CERN OHL?
|
|
|
|
|
|
A: The licence is meant to cover Open Source Hardware (OSHW) designs. It
|
|
|
has no concern with proprietary developments. When we drafted it, we
|
|
|
also made sure it can be used for free and open source software, even if
|
|
|
that is not its main aim,
|
|
|
that is not its main aim.
|
|
|
|
|
|
#### Q: What are the rights the licence rests upon?
|
|
|
|
|
|
A: The licence text makes no assumptions about the rights that will be
|
|
|
invoked to sustain it. These may include but are not limited to
|
|
|
copyright, patents, design rights, and database rights.
|
|
|
A: The licence texts make no assumptions about the rights that will be
|
|
|
invoked to sustain them. These may include but are not limited to
|
|
|
copyright, patents, design rights and database rights.
|
|
|
|
|
|
#### Q: Why is CERN doing this?
|
|
|
|
... | ... | @@ -57,8 +69,8 @@ Circuits (ASICs) using proprietary tools with proprietary libraries |
|
|
which are an integral part of the final design. Something similar
|
|
|
happens with the design of Field Programmable Gate Arrays (FPGAs). These
|
|
|
realities need to be taken into account in the drafting of the licence
|
|
|
if we don't want a strong copyleft licence which can only apply in an
|
|
|
extremely reduced number of cases. Finally, it is important for a
|
|
|
if we don't want a strongly reciprocal licence which can only apply in
|
|
|
an extremely reduced number of cases. Finally, it is important for a
|
|
|
licence to contain text that practitioners can easily relate to. The
|
|
|
CERN OHL strives to use clear terms and definitions that have easily
|
|
|
recognisable and intuitive meanings for hardware designers.
|
... | ... | @@ -79,9 +91,9 @@ CERN OHL which count as consideration. |
|
|
|
|
|
#### Q: Who has the right to enforce this licence?
|
|
|
|
|
|
A: In open source software licences, it is the rights holders (typically
|
|
|
copyright holders) who are able to enforce the licence against
|
|
|
infringers. People who receive the code, unless they are also
|
|
|
A: In free and open source software licences, it is the rights holders
|
|
|
(typically copyright holders) who are able to enforce the licence
|
|
|
against infringers. People who receive the code, unless they are also
|
|
|
contributors, cannot (for example, if you receive GPL code and want
|
|
|
access to the source code, you have to find a rights holder in the code,
|
|
|
and get them to complain about the non-conformance). You are not able to
|
... | ... | @@ -98,18 +110,18 @@ version. |
|
|
|
|
|
## Questions about hardware licensing
|
|
|
|
|
|
#### Q: Copyright does not cover hardware. How do you implement strongly reciprocal licensing in CERN OHL v2?
|
|
|
#### Q: Copyright does not cover hardware. How do you implement strongly reciprocal licensing in CERN-OHL-S?
|
|
|
|
|
|
A: Roughly speaking, the hardware equivalent of a binary object in the
|
|
|
free and open-source software world would be a tangible object made
|
|
|
thanks to design files licensed under an OSHW licence. So implementing a
|
|
|
reciprocal licence involves solving the challenge of ensuring that the
|
|
|
recipient of a piece of hardware gets access to the original design
|
|
|
files. CERN OHL v2 provides two mechanisms to ensure that:
|
|
|
files. CERN-OHL-S provides two mechanisms to ensure that:
|
|
|
|
|
|
- The licence explicitly asks a Licensee to provide an easy way to
|
|
|
access the design Source to recipients of products when (s)he makes
|
|
|
and distributes products based on CERN OHL licensed designs.
|
|
|
and distributes products based on CERN-OHL-S licensed designs.
|
|
|
- For cases in which a tangible piece of hardware changes hands many
|
|
|
times before reaching the final recipient, it is impossible to
|
|
|
enforce the obligations above without making the licence text much
|
... | ... | @@ -117,7 +129,7 @@ files. CERN OHL v2 provides two mechanisms to ensure that: |
|
|
The original designer though, can make it much more likely for the
|
|
|
recipient to get access to the design files by including a URL or
|
|
|
similar in the design, in a place where it will result in a visible
|
|
|
imprinted label in the final object. The CERN OHL requests that
|
|
|
imprinted label in the final object. The CERN-OHL-S requests that
|
|
|
downstream Licensees respect that Notice and modify it accordingly
|
|
|
if they modify the design files. It also requires that they make the
|
|
|
Complete Source for the Product available to the recipient of any
|
... | ... | @@ -131,26 +143,28 @@ files. CERN OHL v2 provides two mechanisms to ensure that: |
|
|
|
|
|
#### Q: My PCB is made of ICs, which are made of plastic, metal and a chip, which is itself made of silicon. How far do I need to go in terms of providing the source designs for all this?
|
|
|
|
|
|
A: The ICs in your design qualify as "Available Components" in the three
|
|
|
variants of the licence. Therefore, you can reference them (as when you
|
|
|
draw a symbol for them in a schematic) without any need to distribute
|
|
|
their associated sources. In this case the IC may be a custom design
|
|
|
also licensed under CERN OHL, but that is an independent decision of its
|
|
|
A: The ICs in your design qualify as "Available Components" in
|
|
|
CERN-OHL-S and CERN-OHL-L. Therefore, you can reference them (as when
|
|
|
you draw a symbol for them in a schematic) without any need to
|
|
|
distribute their associated sources. In this case the IC may be a custom
|
|
|
design also licensed under CERN OHL, but that is an independent decision
|
|
|
of its
|
|
|
Licensor.
|
|
|
|
|
|
-----
|
|
|
|
|
|
## Questions about software
|
|
|
|
|
|
#### Q: A CERN OHL licensed design contains a processor running code. What are the implications on the code of using CERN OHL v2 for the hardware?
|
|
|
#### Q: A CERN OHL licensed design contains a processor running code. What are the implications on the code of using CERN OHL for the hardware?
|
|
|
|
|
|
A: The CERN OHL license does not extend to the code running in that
|
|
|
processor. The processor falls under the definition of "Available
|
|
|
Component". So does the flash (or other) memory chip that may host the
|
|
|
code prior to power-up. The CERN OHL has no concern with the contents of
|
|
|
that flash. You could of course choose to licence that code under a Free
|
|
|
and Open Source licence, e.g. GPL, but that is independent of your
|
|
|
choice of licensing for the board as a hardware
|
|
|
Component" in CERN-OHL-S and CERN-OHL-L (the two cases where there could
|
|
|
be a potential issue). So does the flash (or other) memory chip that may
|
|
|
host the code prior to power-up. The CERN OHL has no concern with the
|
|
|
contents of that flash. You could of course choose to licence that code
|
|
|
under a Free and Open Source licence, e.g. GPL, but that is independent
|
|
|
of your choice of licensing for the board as a hardware
|
|
|
design.
|
|
|
|
|
|
-----
|
... | ... | |