Awesome news! Congratulations and thanks for pushing this work into the world!
Fantastic!!! Now I’m happy that we some issues with the files for PCB manufacturing. Hahaha
We are releasing our hardware using the V2 for sure
This is great news. Well done to everyone involved.
I know CERN is a paid for GitLab customer. It would be good if someone who runs the CERN instance could throw their support behind my push for hardware licences on GitLab https://gitlab.com/gitlab-org/gitlab/-/issues/118590
So it looks like the Permissive license is what you’d expect, similar in spirit to what the Apache 2.0 license seeks to accomplish for software.
The weakly reciprocal version seems similar in spirit to e.g. LGPL, allowing combination with non-open designs, and the strongly reciprocal seems similar to the GPL.
I’m happy to see the patent grant clauses in all of these. It might have been nice to have an attestation that the creator says that, to the best of their knowledge, no patents held by others would prevent you from taking advantage of the freedoms granted to you by this license. It probably wouldn’t have a lot of legal weight, but it would be nice to explicitly state that this is something we care about.
I’m disappointed that there is no requirement for the source files to be in an open format in any of these licenses. There is a weak requirement that source files be viewable using FOSS but only if the CAD software used is able to export to such a format. If something is Open Hardware then I should not be required to buy and run proprietary software in order to modify the source. That is not openness. Altium licenses are ~$9k last I checked.
One difference between the Weak and Strong licenses confuses me. From section 1.7 in the Strong version:
1.7 'Available Component' means any part, sub-assembly, library or
code which:
a) is licensed to You as Complete Source under a Compatible
Licence; or
b) is available, at the time a Product or the Source containing
it is first Conveyed, to You and any other prospective
licensees
i) as a physical part with sufficient rights and
information (including any configuration and
programming files and information about its
characteristics and interfaces) to enable it either to
be Made itself, or to be sourced and used to Make the
Product; or
ii) as part of the normal distribution of a tool used to
design or Make the Product.
The section is the same in the weak version with the only difference being that “as a physical part” is missing. Does anyone know the significance of this change?
Thanks Julian, I will contact somebody in CERN IT to see if they can discuss with Gitlab folks directly. In the meantime, could you edit your proposal to include v2?
There are things which belong more naturally in a certification programme such as OSHWA’s than in a licence text. This could be one of them. The licence tries to protect licensors as much as possible (see e.g. the disclaimer) from real or perceived legal risks which would make them hesitate in sharing their designs.
We want people to share. Today, unfortunately, the majority of designs (including most of our designs at CERN) is done with proprietary tools. The software world very wisely initiated the GNU project at (roughly) the same time as the GPL licence emerged. We have no GNU project, and some of us are doing our best to help FOSS tools achieve a level of quality and features comparable with the best proprietary offerings, but we need to be realistic. We are not there yet. From a practical perspective, we should not forget that the original licensor is not bound by the licence, so the effect you are suggesting could be tricky to achieve.
Also, please, when advocating for openness, let’s leave the monetary issues aside, or at least not give them a prominent place. There is nothing wrong with Altium employees being paid for their work (which is where most of the Altium licence money goes, I would guess), and in fact this is one of the issues that plagues the FOSS world: we have not found a way to properly reward FOSS developers for their work. The biggest issue with proprietary tools is that a company can one day decide that you will not be able to open and edit your files any more. This is due to the fact that the file formats are proprietary and undocumented. I haven’t checked Eagle lately, but someone told me that the latest versions don’t use their openly-documented XML-based format. KiCad developers could not keep you from seeing and editing your design, even if they wanted to. The GPL3+ licence in the KiCad code does that for you. In all fairness, I should say that money does play a role in the story in the end, because often proprietary companies will allow you to keep seeing your designs in exchange for more money, so you have a point, but I think in general we should focus more on freedom than money in our advocacy efforts, keeping in mind that at some point both may well meet. There is a free version of Eagle out there (last time I checked at least), and if money were the only argument then we should all be happy using it. That’s not the case for the reasons I give above. Freedom is the most fundamental reason. Sorry, I hope I don’t sound condescending. I am not only writing to you, but also to people who might read this and for whom this could be a useful perspective in their advocacy efforts.
Finally, I also think that this requirement for the original design to be done with a FOSS tool could better fit certification or label schemes such as OSHWA’s, which are complementary to the licensing front.
Yes, this is intended. See Faq · Wiki · Projects / CERN Open Hardware Licence · Open Hardware Repository
The rationale is the following: an -S or -W PCB design should not be required to disclose the recipe for e.g. how to make resistors out of metal and carbon. Resistors are available components. Inside an FPGA, though, we want to establish a difference: HDL code for all blocks used in a design should be published if any of them is under -S. -W blocks can be combined with proprietary ones though. To achieve this, in -S, non-physical blocks (such as HDL cores) do not qualify as Available Components and are therefore not excluded from the obligation to share the code. Let me know if this is not clear.
Thanks for your feedback and questions. Please do not hesitate to ask or suggest more. It is very useful for us to make sure that the licence is robust and the FAQ and rationale document answer the questions people may have.
We want people to share. Today, unfortunately, the majority of designs (including most of our designs at CERN) is done with proprietary tools. The software world very wisely initiated the GNU project at (roughly) the same time as the GPL licence emerged. We have no GNU project, and some of us are doing our best to help FOSS tools achieve a level of quality and features comparable with the best proprietary offerings, but we need to be realistic.
That is not the lesson we learned from FOSS. If people had been thinking like this back when the first Free Software licenses were written then we would not be where we are today. The whole idea of Free Software back then seemed unrealistic and unworkable to most. They did not write licenses based on what the world looked like in the present but what they wanted to the world to look like in the future. Being realistic is great when trying to predict the future. It is terrible when trying to change the future. It is exactly because so many people are using proprietary tools that it is so important to push against it.
We have another type of technology where a piece of data can be easily copied and shared with your friends but which your friends can’t legally open without paying a fee: It’s called DRM. This is equivalent in my mind to allowing DRM on something labeled as Open. The only difference here is that, even if you pay the required fee to access the data, none of that fee goes to the original creator of the work. At least with DRM you have some inkling of hope that paying the fee doesn’t only support your digital gatekeeper overlords.
Also, please, when advocating for openness, let’s leave the monetary issues aside, or at least not give them a prominent place. There is nothing wrong with Altium employees being paid for their work (which is where most of the Altium licence money goes, I would guess), and in fact this is one of the issues that plagues the FOSS world: we have not found a way to properly reward FOSS developers for their work.
Did I say that there’s something wrong with Altium paying their employees? The problem is that a license claiming to be an open license is creating a scenario where people are forced to use proprietary software if they want to play, which is bad enough, but this is compounded by the fact that the proprietary software isn’t affordable. You’re seriously asking me to leave money out of a discussion that is essentially about access to tools and knowledge? So it’s important that Altium employees get paid but it’s less important that other people have to pay them? Altium employees have to choose between making proprietary software and not being able to pay rent. This license is making other people choose between being able to hack on open hardware designs and not being able to pay rent. At the end of the day affordability and openness are both important factors that decide who is empowered and who is disempowered.
In all fairness, I should say that money does play a role in the story in the end, because often proprietary companies will allow you to keep seeing your designs in exchange for more money, so you have a point, but I think in general we should focus more on freedom than money in our advocacy efforts, keeping in mind that at some point both may well meet.
Are the issues of freedom and money separate in your mind? We are building out the commons every day, building alternatives to the proprietary, to the unsustainable, to capitalism. Our entire copyright regime was sabotaged by mega-corporations in order to make them more money. In order to put more power into the hands of the few to the detriment of the many. These are not separate issues. This is decentralization and democracy vs. Disney.
If you have to work for Disney to pay the rent then I do not blame you but I still will do what I can to ensure that Disney (or Altium) gets as little income as possible. The more capitalist the society, the more you vote with your dollars (or euros) and we should not be encouraging people to vote for more proprietary software. Not supporting specific corporations is not the same as being against workers receiving fair compensation.
It is true that we haven’t found a good scalable alternative for paying rent so FOSSH developers are still struggling more than they should. I am very aware, being such a developer myself, but
When we have enough free hardware,
At our call, hackers, at our call,
We’ll kick out those dirty capitalists
Ever more, hackers, ever more.
(Obligatory note that I am not a Stallman apologist. I just like the song)
Yes, this is intended. See Faq · Wiki · Projects / CERN Open Hardware Licence · Open Hardware Repository
The rationale is the following: an -S or -W PCB design should not be required to disclose the recipe for e.g. how to make resistors out of metal and carbon. Resistors are available components. Inside an FPGA, though, we want to establish a difference: HDL code for all blocks used in a design should be published if any of them is under -S. -W blocks can be combined with proprietary ones though. To achieve this, in -S, non-physical blocks (such as HDL cores) do not qualify as Available Components and are therefore not excluded from the obligation to share the code.
Wait what? From the FAQ:
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” in CERN-OHL-S and CERN-OHL-W (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.
but the HDL code is probably stored on that flash and loaded on boot? It was not clear to me at all when reading this license that you make a clear distinction between software and hardware and that HDL code falls into the hardware classification. From section 1.7:
1.7 'Available Component' means any part, sub-assembly, library or
code which:
a) is licensed to You as Complete Source under a Compatible
Licence; or
b) is available, at the time a Product or the Source containing
it is first Conveyed, to You and any other prospective
licensees
i) as a physical part with sufficient rights and
information (including any configuration and
>> programming files <<
and information about its
characteristics and interfaces) to enable it either to
be Made itself, or to be sourced and used to Make the
Product; or
ii) as part of the normal distribution of a tool used to
design or Make the Product.
So why can’t I provide the programming files for the FPGA on my hardware design? Obviously I can do that for the firmware for my microcontroller so what am I missing here? Where is the part of the license that specifies the difference between HDL and any other source code files?
Honestly, reading the part of the FAQ about how it’s allowed to have FPGA code that requires closed source libraries and that you can do this under a license called the Strong Open Hardware License is discouraging. I suggest that you rename it the Medium license instead and create an actual Strong license where you could just use the GPLv3 for any code required for the Product to work as intended, be it C code or HDL. Or if renaming to Medium is too late then maybe make a new one called Very Strong or Spicy Mint Flavor or something.
Finally, I also think that this requirement for the original design to be done with a FOSS tool could better fit certification or label schemes such as OSHWA’s, which are complementary to the licensing front.
This is not completely a terrible solution but it’s definitely worse than having it as a license option. Being able to quickly identify whether or not I want anything to do with a specific project is key. I can’t ask “is it open hardware” because no-one really agrees on the definition, but I also apparently can’t ask “Is it CERN-OHL-S?” or “Which license does this project use?”. So I guess my question is: With this solution, what question would I ask if this was implemented as a non-license label scheme?
I’d much prefer a single bit toggle switch be added to the 2.0 licenses. Creative Commons has three single-bit toggle switches and I think the target audience for a hardware license is going to have an easier time grokking slightly complicated license options. Would it be that difficult to add a “-OF” (open format) option to all three licenses?
One last question: What is the license of the license text?
Thank you for your quick previous response.
I am curious. Do you know any widely used FOSS licence which explicitly forbids licensing works which need a proprietary tool to view them and edit them?
No, the licence is not creating that scenario. If you choose to publish work developed using a proprietary tool, you are creating that scenario, not the licence. You could create a similarly constraining scenario licensing your schematics and layout under the GPL. There is nothing new with CERN OHL v2 in that respect.
An important part of the answer in the FAQ is left out of your quote. I have edited that FAQ entry to make it even more clear. You can of course choose, as the original licensor, to make your code also available under a FOSS licence, or under the CERN OHL v2. The same applies to the HDL which is used to generate a bitstream which configures an FPGA.
Of course, you can provide everything. The CERN OHL on the PCB does not force you to licence the contents (if any) of your FPGA’s config memory under CERN OHL, but it does not forbid it either. It’s up to you. In any case, if you ship a board with a configured FPGA, you need to make the bitstream available, i.e. people should be able to reproduce your work form scratch. In this case it would mean making the PCB and configuring the FPGA.
If you choose to license your FPGA design under CERN-OHL-S, no closed-source libraries are allowed. So you, as a licensor, can make a product that would fulfil your definition of “Very Strong” and you can even call it that if you want. With the licence, we give freedom to the licensor to figure out what makes more sense for any project. We want more people to share designs, but we are very aware that there are at least three major collaborative paradigms out there for open source hardware, so we provide the tools and you, as a licensor, decide.
I guess, today, you’d have to ask more than one question 
If somebody defines a label for this in the future, then you could ask a single question.
We’re just out of a more-than-5-year effort. We have done our best to make CERN OHL v2 useful for many people. The chances are very low that we re-open the drafting process in the coming months. We’d have to identify a serious bug, or a change in drafting required for acceptance/endoresement by OSI or the FSF which would not compromise our main goals with the licence. I will keep the idea in mind for the next time we go in drafting mode. Thanks.
Same as for GPL and many other licences: no licence, i.e. “all rights reserved”. I will add an FAQ entry about it when I get some time.
Thanks for your feedback.
To weigh into the debate about proprietary source files, and money. I think we all agree this is an important issue. I think that what side you come down on very much depends on the work you do.
I used to work at NIST doing measurements of the Universal Constant of Gravitation. One thing that always plagued me was that every instrument was a one-off. The principles of the instrument were published, but all of the fiddly engineering was left to rot on a hard drive and eventually lost. For this sort of pure academic equipment I wouldn’t care if the files were in SolidWorks or FreeCAD, I just want the designs so I can understand them and maybe build them. In the budget of such a project $10k on a license is not too significant.
Now I work on the openflexure project where the goal of the project is to make microscopes available to all. We are particularly interested in small companies across the world being able to build and adapt the microscope for their local needs. Here $10k for a licence is just not going to work. Everything is in OpenSCAD.
I would love all designs to be done in open software, but I think there are a lot of people who use proprietary software who would be open to opening their designs, but not to completely changing how they work to learn new software. Especially seeing as things like FreeCAD, while improving at breakneck pace, still are not a feature complete or stable enough for a lot of workflows. I think we want to encourage those people to join us, rather than demand that they are all in 100% or they are all out.
I think a certification scheme, or some sort of metric for how open a project is, is a good way to encourage open design software while still encouraging those who use proprietary software to make their designs open.
I fully agree Julian. I should clarify, in case what I wrote earlier was too long and confusing, that I think high prices of software are an important problem that should be solved, because they isolate a lot of people from the the sharing of designs. My contention was about the best arguments to use in our advocacy. If we focus too much on price in the short term, which is what sometimes happens, we make the case less effective against tools which are free-as-in-free-beer. Many companies can afford to sell at a loss or even give things away if that means that they will have some kind of lock-in which will ensure them revenue in the future. As an example, universities are full of labs where the software licences are given for free so that students, not wanting to learn another tool (a softer variant of lock-in), will buy licences when they start working in a company (and then true lock-in starts). Another example is big EDA vendors giving away licences to the trend-setting companies in OSHW, knowing that people will download their designs and will need the proprietary tools to open them. That’s why I think freedom is a better main argument in our advocacy, with affordability playing a complementary role. This is not a new idea at all, by the way. The FSF figured this out a long time ago.