 I'm a lawyer. I've spent quite a long time over the past few months working with CERN, helping to draft a new version of the CERN hardware licence, so the core team has been me, Javier Serrano, who's sitting over there, and Miriam Ayas as well. The idea is that CERNO HL has always been intended to be a licence that can licence open hardware, but the latest version is the suite of licences, and I will explain that in a little greater detail shortly. So, to put this into context a bit, the project started with the release of the first licence in March 2011, and that was followed fairly rapidly by versions 1.1 and 1.2 in 2013. Then there was a bit of a hiatus because we realised that the licence really wasn't working particularly well for some use cases, and in particular those use cases were silicon, things like FPGAs and ASICs. So we put quite a lot of effort into writing some additional portions of the licence, which were mainly in the form of exceptions, to deal with those, and they worked pretty well. But what we ended up with, it really wasn't very elegant, it was very crufty, it wasn't very easy to read, and so that was the beta one that was released in 2017. More recently we decided we'd just rip the whole thing up and start all over again, and we hope that we've come up with something that is significantly more elegant. So the major purpose behind the licence is to create copy left for hardware, and I use the word copy left in a relatively loose sense, some people prefer the term reciprocal. Copy left implies that it's purely copyright based. The licence obviously doesn't pinch on copyright but it pinches on other intellectual property rights as well, such as patent, trademark, and various design rights and so on. So when I use the word copy left I'm using it fairly loosely, but it's the reciprocal nature of the licence that's the important thing. It's also designed to cover a very broad range of hardware designs. Initially it was conceived to deal with electronic circuits, but then it was realised that it was a much, much broader range of hardware than that. We're looking to cover everything from at one end mechanical devices, for example. Obviously electronic circuitry and then as I mentioned, into silicon in terms of things like FPGAs and ASICs. The idea is to create a hardware commons, a commons of hardware designs that are easily interoperable and interconnectable to each other, and we want to try to make it easy to understand. That's a fairly difficult set of criteria to fulfil. So the specific challenges that we have are first of all the scope of the copy left, and I talk about that a little bit more later. We want to try to make it compatible with other licences that people typically use as well. This is all part of the idea of maintaining the commons and trying to have as many designs that can interoperate as possible. A specific issue that we have is particularly in the world of hardware there are much fewer mature tool chains available to us than there are in the world of software, and this is particularly true as far as FPGAs and ASICs are concerned. And then there's also those practicalities of working with FPGAs and ASICs as well. So specific issues that we addressed, the original version had gendered language in, that's now gone. We've tried to simplify some of the terminology so that we try to use terms that are very easily accessible, like make, for example, rather than instantiate, which was a term that we used in a previous version. We've borrowed terms from other licences, or stolen, depending on which way you look at it, that people will be familiar with already. So there are bits in there that look very GPLV-free, like the word convey is an example of that. Some of the notice provisions look very similar to some of the notice provisions that you might see in Apache, for example. So we've tried to take some of the best concepts that we've seen in other licences and tried to incorporate those. We've put a troll dissuasion clause in there. I'm not going to go into detail about how that works, but essentially it says that if you have a dispute under this licence, then job one is to try to bring the person that you've got to dispute with into compliance and not to try to shake them down for cash. It's a contract rather than a bare licence. The reasoning behind that is that bare licences simply don't work in many jurisdictions, so we just wanted to reflect the reality of that. And it now comes in three variants. So there's the strong variant, which is broadly equivalent to the original CERN open hardware licence, and then there's a weaker variant and also a permissive variant, and I'll explain a little bit more about the distinction between those later. And interestingly enough, it now works for software as well. And part of the logic behind that is that when we've approached organisations like the FSF and the OSI before and asked them to have a look at the licence, they've been a bit reluctant to do so because it's not a software licence. So the theory is that if we can persuade some of you people to use it as a software licence, then we'll have a stronger argument to say to them, okay, it's called a hardware licence, but actually people are using it for software. So let's talk about the scope of the licence. This is the extent to which the reciprocal nature of the copy left is intended to impinge. And just an important note here is the wording that is on this slide, it is not the legal text of the licence. This is a description of what works. I don't have enough time to explain the legal text in detail because time is marching on. So this is just a description of the underlying mechanism of how the licence itself works. So basically, if you make a product from covered source and you'll see that these capitalised terms in there are capitalised terms as defined in the licence, then you've got to make the complete source to that product available to a recipient of the product. And this can be done either privately, which is the way that something that's entirely permissible within GPLV3, for example, or alternatively you are able to make that source public. And this is a distinction between the older versions of the CERN-OHL, which required that the design was made public by placing the source code in a specific source location. That's something that we still very much encourage and we want people to do that, but it's no longer strictly necessary. It is now possible that if you are conveying to another person you only have to convey the source to them. You don't have to make it publicly available. Obviously the recipient can then make it publicly available if they decide to do so. So what is complete source? Well it obviously includes the design materials, code, interfacing information, and this all has to be in preferred form for making modifications that will be wording that people are generally familiar with. But this is where the interesting concept comes in. It does not include what we call available components. And for available components, basically you only have to provide the specifications and the interface information. So let's give you an example of this in practice. So imagine that you have a circuit board that is released on the CERN OHL. That circuit board is going to contain components. Typically things like pastas, resistors, inductors, and so on. It may also contain an FPGA. So for those that are not familiar with FPGAs, an FPGA is a silicon chip that you are able to program by means of something called a bitstream into being an array of logic. So basically any sort of logic that you can imagine any array of AND gates and AND gates and OR gates that you want to be able to create any form of logic circuit as you can create this in a language called HDL, hardware description language, compile that into a bitstream and then feed the bitstream into the FPGA. And the FPGA then becomes a chip that has these particular logic characteristics. But the bitstream itself is created by means of something that looks a lot like a programming language. And so that's HDL file itself may be covered by the CERN open hardware licence. And that in common with the programming language will contain custom code that you've written yourself, but it may also contain standard libraries and third party libraries. So you can immediately see that you have a number of different layers, each of which may be licensed under different licences in a different way. And this concept of available component is designed to facilitate that. And then so that's looking at the circuit board level and going down. You can also go up as well. So the circuit board will sit in an enclosure which may have a power supply unit in it. Those may also be covered by a licence, the CERN OHL. Then that enclosure may sit in a rack and the rack itself may sit in a data centre. So we've looked very carefully at the way that you can have designs that are licensed at individual levels. The components that are contained within those designs can be available components and they're looked at differently from the way that the fundamental design itself is dealt with. This really is a powerful mechanism that enables you to stack designs on top of one another. So for a component to be described as an available component, so in other words a component for which you do not have to provide the complete source, well obviously if it's a self available under the CERN OHL or a compatible licence that means that you will have access to that source anyway. So that's fine. You can point people in a direction of that source. You don't have to provide it yourself. All of that available component, if it's available with the specifications, characteristics and interface information necessary to make a product you don't have to provide all of the information, all of the code required for it. So to give an example of that if you're talking about a circuit board that's covered by the CERN OHL, just standard components like capacitors, resistors, etc. You don't have to provide the recipe for how to make them. All you have to do is to say this is a 220 ohm resistor, quarter watt within a certain tolerance. People know that that's an easily available component that they can get hold of it. So that limits the scope of the source that you need to provide. And also because we're thinking in terms of this mechanism working for hardware description languages and also potentially for software we say that anything that's part of the normal distribution of a tool chain is also excluded and is therefore can be considered an available component. And that's very like the concept in GPL v3 of system library modules. You don't have to provide the code to system library modules because the assumption is that they're already available. So what do we regard as being a product? And so remember the release of a product is something that triggers the requirement to provide the complete source. Well it may obviously be a finished product. It may be the complete circuit board. But a product could also be considered to be a component itself. Or it could be an intermediate form derived from the source. So what do we mean by that? Well if you take hardware description language and then you compile it then you end up with a bit stream. If on the other hand you're working purely in a software domain and for example you're writing a C program then the first stage of the compilation program is that you will be producing an object file. So those themselves will be considered products if you release one of those then that triggers the obligation to produce the complete source. So the idea is that we're constraining the scope of the copy left so that upwards it's constrained by the concept of the product and downwards it's constrained by the concept of an available component. And in previous versions of the OHL we had this concept of the source having to be made available at a level of abstraction if you were to make any modifications to it. That was really difficult to implement and had the wider problem that it would be possible to have some source that was at a fairly high level for most of it. So it could be for example a circuit board and then suddenly you go into extreme detail about the content that's in the FPGA for example. What is the level of abstraction in that case? So this is a much neater way of being able to distinguish between those parts that you need to release the code for and those parts that you do not need to release the code for. So the difference between the strong and the weak versions is that in the weak version you can release the product without having to release the code for all its components if you have all of the interfacing information for those components. So that's basically like LGPL. So if you're looking at it from the circuit board example then you don't have to release all of the code to enable you to make the capacitors, the resistors, etc. You just have to provide the specifications of them so that people can go out and source them. And if you're looking at it from an HDL or a software concept you don't have to provide all of the code of all of the libraries that you're incorporating as long as the library is available for somebody to use and you're providing people with all of the interface information. So it's a bit like LGPL but it sort of works backwards. The strong is exactly the same apart from the fact that the exception above only applies as far as physical components are concerned. So this basically means that if you're looking at a piece of hardware like a circuit board what I've said continues to apply you don't have to provide all of the design information for the capacitors, the resistors, etc. But if you're looking at something that is in a digital domain so if you're looking at something like hardware description language or like software then you will have to provide the code for all of that software including the libraries and including any modules that plug in. So why is this exception only work as far as physical is concerned? Well we do note that there is a difference between the physical and the virtual worlds. If you've got a physical item then the reality is that there is something that will need to be purchased in the virtual world, in the digital world it's reasonable to imagine a situation where you force somebody to produce all of the code for that because there's zero cost in reproducing digital artefacts. There's obviously a cost involved in reproducing physical artefacts. So there is a difference between the two. The permissive version well that is significantly simpler than the reciprocal versions as you would imagine it's not super stripped down like an MIT or BSD license it's probably more like an Apache license so from that perspective it retains things like it retains the the patent wording retains most of the notice provisions the notice provisions that are in the license very similar to the provisions that you would have in the Apache license in any event. So the question is where are we intending on going to next? So all of the licenses themselves and the FAQ and the commentary are now all available online from the OHL website details are on there so please it would be very helpful if people could take a look at the text text we've also been consulting with a number of people in terms of what we think is actually going to work here so those organisations include the Fosse Foundation and also SPDX and various other people so this is the point at which we really want to throw that consultation out a little bit more widely so that we can get a bit more feedback in terms of whether we think that this license operates or how you think this license operates and if you do have any comments on it probably the best bet is to ping them over to me in the first instance and then we can discuss them with the internal drafting team as well Now I've sort of gone through very very quickly some of the top level features of the license it would be very good to get some feedback from in the room if anyone has any particular comments on those in my questions from the floor in the moment that would be extremely helpful and welcome thank you very much indeed Thank you so much Andrew I think it's great that you've come to talk to us about it I also think it's really cool that as part of drafting the license you've already thought ahead to have an FAQ and commentary about it Since I have the microphone I have a question I'm burning to ask before I turn it over to the audience Why OHL, CERN OHL, vs the other pre-existing hardware licenses? What's the rationale for this license? It's the only well it's probably the most prevalent reciprocal copy left license that is out there so people tend to use other licenses for hardware but they tend to be permissive licenses so there's a lot of use of BSD for example some people are using cheese, some people are using the solar pad license they're all permissive licenses it's much more difficult to make reciprocal and copy left licenses work and we're uncomfortable with people trying to use licenses like GPL for example as far as hardware is concerned there's a number of reasons for that first of all our license has some benefits over GPL as far as its use for hardware is concerned so one of these are the requirements to preserve the notices and there's an ability in there to require people to publish the source location actually on the object itself or the packaging so for example if you're producing a chip you could have a short form URL which is required to be placed on the chip and if people look at the chip then they can type that in and they can get to all the design documentation so it's things like that that aren't available as far as GPL is concerned Thank you next question I don't know a whole lot about hardware design but what I understand from the industry is that as a hardware designer I would have two issues the first one is I made a risk 5 chip and I have a memory controller that I'm not a memory controller guy so I go to somebody and I buy a memory controller the other one is of course you already pretty much talked to it like I need to source a chip and solder it down so in those two scenarios how copy left can I go with this license Okay so in the first example that you gave if you're looking at a risk 5 chip and you're looking at a memory controller so if you're really relicencing the risk 5 design under CERNOHL the memory controller could be classified as an available component so if it's available obviously it's available under an open license that's straightforward it is on the other hand even if it's available commercially then it's potentially still an available component if you have to buy a resist you have to buy it from somebody that's something commercial nobody's expecting that you get a resistor for free so the idea is that these other components that you might want to put onto a core if they qualify as an available component then you do not need to provide what it is, what it's interfaces are and where you get it from Thanks so much sorry if I missed it but does this also include a patchy style patent grants? Yes it's very similar to a patchy as far as patent granting is concerned You didn't mention anything I think about tool chains hardware could you say a couple of words about requirements on how the source is format the source for the bitstream the source for the hardware on the requirements for that in the license So there is an obligation in the license that says that even if you're using a proprietary tool chain if it's capable of producing the source in a way that is capable of being read by an open source tool then that's what you're supposed to do So I think this is one of those areas where we have to look at the practicalities of this and realise that particularly in terms of ASICs there really are only the mature proprietary tool chains available so at the very least in a way in which it's possible using that tool to bring the source out of a proprietary format and make it available to be read in a non proprietary format then that's what you've got to do So you've got this definition of an available component What happens if an available component stops being available a discontinued chip or something similar That's a very good question You've got an obligation to continue to make similar to the GPL if you're choosing to make the source available to the world at large then you have to continue to make it available for three years I guess the answer is that at the point that you make it available it's an available component and then it fails to be an available component to the later stage then that satisfies the terms of the licence there's obviously not an ideal situation that you can do I think this is an opportunity for a shout out to Zach that for software now we have software heritage so we know that it will always be available so we need the same thing for hardware we need like hardware heritage if we can figure out a way to do that Question here and then over there It's not a question maybe a recommendation In GitHub you have ability to select different licences when you submit your project can you contact GitHub and ask them to include your licence there because people are lazy No no no we're very keen to try and make it as easy as possible for people to use the licence we're reaching out to OSI FSF we want to make it available on GitHub Open Source Hardware Association already recommends that's definitely part of the outreach process to make sure that happens Could you so it's a certain OHL and the new version they're not copyright licences but as someone that's not a legal expert I kind of understand copyright but could you maybe try and provide some intuition as to what the actual mechanism is by which the OHL works and whether there's been any revisions to that in the second version I mean most of the time it is going to be copyright that's relevant because the licence impinges on a documentation is going to be something that is subject to copyright it might also in the European Union be subject to database right but basically the obligations are actually triggered the second that you make a modification but that doesn't alter your relationship with the outside world until a product that has been made according to the covered source is released to somebody outside so the second that you make a modification you're basically making a promise to the world that you're going to make the source available but nobody's able to rely on that promise because they don't have a copy of the product yet so soon as somebody gets hold of the product that's the point at which they are then able to say right I'm now expecting to receive the source alongside that we can still take a couple questions I'm going to let Molly set her laptop up here if she'd like any more questions okay thank you for the talk you mentioned that you were allowed to share your product privately with the original builder or openly can you explain why this privacy shared clause is in there yes I mean there are some debates as to whether prohibiting private distribution is something that would cause something to stop being OSI approved and given that it's something that sort of commonly exists as far as for example GPL3 allows it it seems strange to diverge from that I mean we don't really want people to do it so we much prefer that people publish it and if you look at the open source hardware association definition in one way that actually requires the design to be made public so we're not it's not something that we want people to use very much but it is there just to basically maintain a sort of parallelism with GPL3 I have a question or suggestion perhaps is when you have an available component it might be only available by one supplier and if this supplier stops then you're also in a dead end would it be an idea to have a class that it should be available at least two suppliers yeah we have thought about this and I'm very happy to have a lengthy conversation with you because it's going to take about half an hour to explain the thinking in that but yes that is definitely of value concern and something that we are worried about I think we have time for just two more questions we'll take one here and one in the back so in your example when you drilled down you went down but then you went back up and you said that it can be in a data rack and then in a data center so do you anticipate available components also being compatible with the open compute model that Facebook has or any of the other folks is that what you're thinking as well or is that like a higher order sorry I couldn't hear that very well so the available components is where you limit down and the product is where you limit up but above product you also had the data center in the rack but there are some projects like open compute where you're defining the racks and the data centers is open as well so do you consider those like available components it's meant to be compatible okay cool that makes sense