Available via license: CC BY-NC-ND 4.0
Content may be subject to copyright.
Andrew Katz, Open Hardware In: Open Source Law, Policy and Practice. Edited by: Amanda Brock, Oxford University Press.
© Andrew Katz 2022. DOI: 10.1093/ oso/ 9780198862345.003.0023
23
Open Hardware
Andrew Katz
23.1 Introduction 490
23.2 What is Hardware? 490
23.3 A Brief History 491
23.4 The Op en Source Hardware
Definition 493
23.4.1 e Open Source Hardware
Statement of Principles 493
23.4.2 e Op en Source Hardware
Denition 493
23.5 Hardware and Reciprocity
(Copyleft)—Intellectual
Property 496
23.5.1 Reciprocity and the costs
of reverse engineering 498
23.5.2 e boundary problem 499
23.5.3 e competing copyles
problem 501
23.6 Hardware and Other Forms of
Intellectual Property Right 501
23.6.1 Patents 501
23.6.2 Design rights, database
rights, and other intellectual
property rights 503
23.7 Specific Open Hardware
Licences 503
23.8 Non- copyleft Hardware
licences 508
23.9 Op en Source Hardware:
Development Models 508
23.10 Conclusion 511
23.1 Introduction
Open hardware has taken a slower and more cautious route to success than Open
Source soware, and in many ways lags behind it. At this juncture, there are far fewer
businesses operating in the world of open hardware, and those businesses are less
prominent and successful (although there are signs that this is rapidly changing).
ere are also far fewer specic open hardware licences than Open Source licences
(which many will say is a good thing), and there are still fundamental questions about
the applicability of various dierent forms of intellectual property right (IP) to dif-
ferent aspects of hardware.
23.2 What is Hardware?
Hardware can cover everything from printed circuit boards to silicon chip designs,
to cases for computer hardware, to mechanical devices, artistic objects, and even
liquids like cola or beer. Ultimately, some physical matter— atoms— must be in-
volved. Whereas information, soware, and content as intangible assets can remain
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
491
in the abstract domain1 (in some cases, until the instant they are used or consumed
by someone), it is a characteristic of hardware that it consists of physical material.
23.3 A Brief History
e concept of ‘openness’ only became necessary to counterbalance societal or le-
gislative processes which began to apply restrictions such as copyright or patent—
to ‘close’— what had inevitably, in its embryonic stages, been open. As explored in
Chapter 24, ‘openness’ (in the sense of freedom of use) only becomes an issue for
hardware, as with any asset class, once the law or norms restricted the use of that
hardware through the imposition of IP. As we will see shortly, IP aects hardware,
although the scope and eect of coverage can be quite dierent from the way in
which IP aects soware.
e evident success of Open Source instigated the exploration of a similar con-
cept for hardware: open hardware or open source hardware.2 For example, Bruce
Perens, one of the founders of the Open Source Initiative (OSI), established the
Open Hardware Certication Program in 1997.3 is was a process which allowed
organisations providing electronic devices to self- certify that the interfaces of their
designs were documented in order to facilitate the programing of device driver
soware. e focus, therefore, was not so much on the design documentation for
the device itself but the ability for the device (e.g. a printer) to be accessible to a
broad range of soware. is would give comfort to purchasers of the equipment
that it would (at least in theory) be possible for them to continue to use their equip-
ment should they change their operating system, or if the manufacturer of the
equipment went out of business and no longer provided soware updates.4
Other initiatives focused more on the design of the hardware itself, such
as FreeIO and the OpenGraphics project, and, in parallel, the growing maker
1 More recently, this is usually digital, but information can exist in analogue form which is still ab-
stract such as a series of uctuations in the magnetic domains on a tape medium such as a compact
cassette.
2 Although the denition of ‘open source hardware’ promulgated by the Open Source Hardware
Association (see later in the chapter), there is no such consistent denition for ‘open hardware’.
Originally, ‘open hardware’ was used for hardware with freely available interface information (even if
there was no access to the designs for the hardware coupled with a right to modify and recreate them)
and ‘open source hardware’ for hardware where the designs were available for copying, modication,
making, and distributing the product, and redistribution of the product and the design. e denitions
are now somewhat blurred: for example, the CERN Open Hardware Licence is very much intended to
allow the designs to be made available, so to that extent it may also be considered to be an Open Source
Hardware licence.
3 <https:// web.arch ive.org/ web/ 199 8121 2031 618/ http:// www.openh ardw are.org/ > accessed 20 April
2022.
4 See n 3.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
movement, meetups, and groups developed such as the Open Source Hardware
Camp5 and OGGCamp, both in the UK. In 2010, the rst Open Hardware Summit
was held in New York, and the germ of an open source hardware denition was es-
tablished, and developed throughout that year, with version 1.0 nally published
in early 2011.6 e Open Source Hardware Association has proven to be longer
lasting than many previous open hardware associations, and held its 10th and 11th
summits (albeit virtually, owing to COVID- 19) in 2020 and 2021. As well as pro-
moting the Open Source Hardware Denition, and holding an annual summit, it
has a certication program which allows organisations providing Open Source
Hardware (OSHW) to obtain a certication that their designs are compliant.7 At
the time of writing, 1,484 hardware designs were certied.8
Between 2010 and 2022, open hardware has matured, with the growing success
of projects such as Arduino (a family of open source hardware microcontroller
boards), RepRap (a 3D printer which is itself available as open hardware), and,
more recently, open source chip designs such as those based on the RISC- V in-
struction set architecture. e BBC launched a low- cost open hardware microcon-
troller aimed at education (the micro:bit) in 2015 with the rst units delivered to
children in 2016.
Open hardware also gained ground in research and academia: as well as RepRap
mentioned earlier, which was developed by Adrian Bowyer at Bath University,
CERN launched the White Rabbit Project, a mechanism for timing events to sub-
nanosecond accuracy using the well- understood Ethernet networking protocol
as its base. e project was initiated as a result of proposals presented by Javier
Serrano in 2008, and also led to launch of the CERN Open Hardware Repository
and the launch of the rst version of the CERN Open Hardware Licence in 2011.9
A particularly interesting area of open source hardware is open source silicon.
Silicon chip designs have been released under Open Source licences for some time
(e.g. Sun Microsystems released OpenSPARC under the GNU General Public
License version 2.0 (GPLv2) in 2005). Since then, several chip designs have been
released under Open Source licences,10 and companies such as Western Digital
Corporation and SiFive have developed products using microprocessor core de-
signs based on the Risc- V instruction set architecture. SiFive has at the date of
writing received a total of US$365.5 million in investment, giving it an overall
5 Now incorporated into the splendidly named Wuthering Bytes tech festival which takes place in
Yorkshire in the UK every year (with a name like that, where else?). <https:// wut heri ngby tes.com/ > ac-
cessed 20 April 2022.
6 <https:// fre edom de ned.org/ OSHW> accessed 20 April 2022.
7 <https:// certi cat ion.oshwa.org> accessed 20 April 2022.
8 <https:// certi cat ion.oshwa.org/ list.html> accessed 20 April 2022.
9 Javier Serrano is still involved in both projects and is a member of the core draing team for the
CERN OHL.
10 A Katz ‘A Survey of Open Processor Core Licensing’, JOLTS Vol 10.1 <https:// www.jolts.world/
index.php/ jolts/ arti cle/ view/ 130> accessed 20 April 2022.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
493
market value of over US$1 billion at the share value for the most recent funding
round.11
Perhaps the most signicant indicator that open source hardware has come of
age is that the European Commission in 2019 issued a call for tenders for a research
project with a scope which explicitly covers open hardware, to examine techno-
logical independence, competitiveness, and innovation in the EU economy.12 e
nal report was delivered in March 2021.
23.4 e Open Source Hardware Denition
e Open Source Hardware Denition and its associated Statement of Principles
rely heavily on the Open Source Denition (OSD) developed by the OSI, and the
Four Freedoms of the Free Soware Foundation, respectively. It is a nice illustra-
tion of the close relationship between these two venerable Open Source denitions
that they can be combined into, eectively, a single unied denition for open
source hardware (OSHW).13
23.4.1 e Open Source Hardware Statement of Principles
Open source hardware is hardware whose design is made publicly available so
that anyone can study, modify, distribute, make, and sell the design or hardware
based on that design. e hardware’s source, the design from which it is made,
is available in the preferred format for making modications to it. Ideally, open
source hardware uses readily- available components and materials, standard pro-
cesses, open infrastructure, unrestricted content, and open- source design tools to
maximize the ability of individuals to make and use hardware. Open source hard-
ware gives people the freedom to control their technology while sharing know-
ledge and encouraging commerce through the open exchange of designs.
23.4.2 e Open Source Hardware Denition
Introduction
Open Source Hardware (OSHW) is a term for tangible artifacts— machines, de-
vices, or other physical things— whose design has been released to the public in
such a way that anyone can make, modify, distribute, and use those things. is
11 <https:// www.cru nchb ase.com/ organ izat ion/ si ve> accessed 17 June 2022.
12 <https:// ec.eur opa.eu/ digi tal- sin gle- mar ket/ en/ news/ call- tend ers- study- imp act- open- sou rce-
sow are- and- hardw are- techno logi cal- indep ende nce> accessed 20 April 2022.
13 <https:// www.oshwa.org/ de nit ion/ > accessed 20 April 2022.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
denition is intended to help provide guidelines for the development and evalu-
ation of licenses for Open Source Hardware.
Hardware is dierent from soware in that physical resources must always be
committed for the creation of physical goods. Accordingly, persons or companies
producing items (‘products’) under an OSHW license have an obligation to make
it clear that such products are not manufactured, sold, warrantied, or otherwise
sanctioned by the original designer and also not to make use of any trademarks
owned by the original designer.
e distribution terms of Open Source Hardware must comply with the fol-
lowing criteria:
1. Documentation
e hardware must be released with documentation including design les, and
must allow modication and distribution of the design les. Where documenta-
tion is not furnished with the physical product, there must be a well- publicised
means of obtaining this documentation for no more than a reasonable reproduc-
tion cost, preferably downloading via the Internet without charge. e documen-
tation must include design les in the preferred format for making changes, for
example the native le format of a CAD program. Deliberately obfuscated design
les are not allowed. Intermediate forms analogous to compiled computer code—
such as printer- ready copper artwork from a CAD program— are not allowed as
substitutes. e license may require that the design les are provided in fully-
documented, open format(s).
2. Scope
e documentation for the hardware must clearly specify what portion of the
design, if not all, is being released under the license.
3. Necessary Soware
If the licensed design requires soware, embedded or otherwise, to operate
properly and fulll its essential functions, then the license may require that one of
the following conditions are met:
a) e interfaces are suciently documented such that it could reasonably
be considered straightforward to write open source soware that allows
the device to operate properly and full its essential functions. For ex-
ample, this may include the use of detailed signal timing diagrams or
pseudocode to clearly illustrate the interface in operation.
b) e necessary soware is released under an OSI- approved open source
license.
4. Derived Works
e license shall allow modications and derived works, and shall allow them
to be distributed under the same terms as the license of the original work. e
license shall allow for the manufacture, sale, distribution, and use of products
created from the design les, the design les themselves, and derivatives thereof.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
495
5. Free redistribution
e license shall not restrict any party from selling or giving away the project
documentation. e license shall not require a royalty or other fee for such sale. e
license shall not require any royalty or fee related to the sale of derived works.
6. Attribution
e license may require derived documents, and copyright notices associated
with devices, to provide attribution to the licensors when distributing design les,
manufactured products, and/ or derivatives thereof. e license may require that
this information be accessible to the end- user using the device normally, but shall
not specify a specic format of display. e license may require derived works to
carry a dierent name or version number from the original design.
7. No Discrimination Against Persons or Groups
e license must not discriminate against any person or group of persons.
8. No Discrimination Against Fields of Endeavor
e license must not restrict anyone from making use of the work (including
manufactured hardware) in a specic eld of endeavour. For example, it must not
restrict the hardware from being used in a business, or from being used in nuclear
research.
9. Distribution of License
e rights granted by the license must apply to all to whom the work is re-
distributed without the need for execution of an additional license by those
parties.
10. License Must Not Be Specic to a Product
e rights granted by the license must not depend on the licensed work being
part of a particular product. If a portion is extracted from a work and used or
distributed within the terms of the license, all parties to whom that work is re-
distributed should have the same rights as those that are granted for the ori-
ginal work.
11. License Must Not Restrict Other Hardware or Soware
e license must not place restrictions on other items that are aggregated with
the licensed work but not derivative of it. For example, the license must not insist
that all other hardware sold with the licensed item be open source, nor that only
open source soware be used external to the device.
12. License Must Be Technology- Neutral
No provision of the license may be predicated on any individual technology,
specic part or component, material, or style of interface or use thereof.
ese denitions, like the Four Freedoms and the OSD on which they are based,
focus very much on licensing and, accordingly, they rely heavily on the under-
lying IP applicable to hardware.14 However, hardware provides some signicant
14 ese principles should be interpreted consistently with the equivalent principles in the Open
Source Denition: see C hapters 1, 3, and 16 for more details.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
challenges, as the intellectual property regime which potentially applies to it is
somewhat more complex than that applicable to soware.
23.5 Hardware and Reciprocity (Copyle)—
Intellectual Property
Primarily, soware is governed by copyright (it is generally treated by copyright
law in a similar way to a literary work). Patents and other IP such as database right
can also aect soware, but IP applies to hardware in a more complex and incon-
sistent way. An upshot of this is that it is more dicult to apply reciprocal licensing
obligations to hardware designs. Note that it is becoming common to use the term
‘reciprocal’ in preference to ‘copyle’ in relation to open hardware licensing be-
cause hardware is dependent on a broader range of intellectual property rights than
copyright alone, so it is potentially misleading to use the term ‘copyle’ with its
close association to copyright. In this chapter, you can regard the terms as broadly
interchangeable.
As explained in Chapter 3, reciprocity relies on there being some form of IP
which can apply each time an item is distributed. For copyle, the relevant form is
copyright. Every time IP impinges there is the opportunity to apply a condition to
the licence which is being granted, and reciprocity works because the condition is
that the item being distributed must itself be licensed on the same reciprocal terms.
is perpetuates the licence each time the relevant item (or a derivative of it) is
distributed.
If the act of distribution (or any of the necessary precursors to distribution, such
as copying or making the item available to the public) requires no licence under
any IP, then the distribution of the item cannot be controlled through application
of a conditional licence to IP because there is no opportunity to apply a condition
(such as the one implementing copyle).
To take an extreme example: it is obvious that a work, such as the Great Gatsby
(which is now in the public domain because the copyright in it has expired) cannot
be subject to any copyright licence, so it is not possible to apply any copyle restric-
tions to it.15
15 Richard Stallman (founder of the Free Soware Foundation) was aware of this when he criticised
the Swedish Pirate Party’s recommendations for a very short period of copyright (ve years). At the end
of ve years, under its plans, computer soware would enter the public domain and therefore what was
previously available under the GPL would be capable of being incorporated into proprietary soware
without the requirement for the corresponding source being made available. In other words, the core
purpose of the GPL— to ensure that free soware remained free— would be defeated aer ve years.
is oended Stallman’s anti- closure view that free soware must remain free, and aer considering
(and rejecting) a special exception for soware which would extend the Pirate Party’s proposed ve-
year term of copyright for the specic purpose of allowing the GPL’s copyle mechanism to continue
working for longer, he concluded that it would be better for the source code for non- free soware to be
placed in escrow and automatically released at the end of the ve- year term.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
497
When a piece of soware is distributed, it will almost invariably have been
copied and then made available to the public before the distribution takes place.
Any one of these acts is likely to be and can be presumed to be aected by copy-
right, and therefore performing that act will require a licence and consequently
provide an opportunity to apply a copyle condition.
With hardware, it is not necessarily the case that making an item to a design,
or making the item available to the public, or physically transferring the item to
someone else, requires some form of licence under which the condition can be
applied. An example of this is the OpenCola. As its name suggests, OpenCola
is a Coca- Cola- style drink, diering signicantly from Coke in that its recipe is
publicly available16 and licensed under the GNU General Public License (GPL).
However, because making a drink to a recipe is not an act which is restricted by
copyright, doing so does not require a licence and therefore provides no oppor-
tunity for the licensor of the recipe to require anyone making OpenCola (or a
variant) to make the recipe available to them. If OpenCola was soware source
code, then the act of compiling the source to make the executable soware would
be creating an adaptation (or depending on the jurisdiction’s terminology, a de-
rivative work) which would be an act restricted by copyright, for which a licence
(in this case, the GPL) is required. In this example, the GPL’s copyle condition
would therefore kick in, and the licensee would be required to provide (or oer to
provide) a copy of the source code. For OpenCola, the copyle eect would not
extend to the product itself.17
In brief, whereas almost any activity involving soware— running it,
distributing it, copying it, amending it— will involve an act reserved to the copy-
right owner, it is by no means clear that similar acts relating to hardware are simi-
larly controlled.18
Some major open hardware licences, the CERN Open Hardware Licence
family19 (other than in the case of CERN, the permissive variant), and the TAPR
Open Hardware License,20 seek to apply a form of reciprocity. e lack of impinge-
ment of IP on hardware causes issues for both licence models, as will be discussed
shortly.21 ey use very dierent techniques to achieve their aim.
16 <https:// web.arch ive.org/ web/ 200 1021 8075 323/ http:// www.openc ola.com/ downl oad/ 3_ so dr
ink/ form ula.shtml> accessed 20 April 2022.
17 It would extend to the text of the recipe though: if the licensee transfers the recipe text so someone
else, that recipient would have the right to change it, and distribute it, and if they did so, that distribution
would also have to be subject to the GPL.
18 Except in relation to patent, which is dealt with later in this chapter.
19 <http:// www.ohwr.org/ proje cts/ cern ohl/ wiki> accessed 20 April 2022.
20 <http:// ww w.tapr.org/ ohl.html> accessed 20 April 2022.
21 For further analysis of these issues, see A Katz, <http:// www.ifos slr.org/ ifos slr/ arti cle/ view/ 69
(2012), and Richard Stallman (1999) <http:// www.lin uxto day.com/ inf rast ruct ure/ 199906 2200 505N
WLF> both accessed 20 April 2022.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
Application of reciprocity to open source hardware is not only problematic
from an IP perspective. ere are also challenges from an economic and practical
perspective.
23.5.1 Reciprocity and the costs of reverse engineering
e cost of making a bit- for- bit copy of a piece of soware is close to zero. In contrast,
because hardware involves physical material, there will always be some cost involved
in instantiating a piece of hardware. For example, even if the hardware can be repli-
cated by 3D printing, the cost of the feedstock needs to be considered. Many hard-
ware designs will be too complex to be replicated using a 3D printer: for example,
the front suspension sub- assembly for a car may require milling and machining of
the steel components which make it up. Even if the design documentation includes
CNC (computer numerical control) les to control the machine tools such as a lathe
and milling machine, the eort required in setting the machines up, monitoring
them, and nishing and assembling the mechanical components is signicantly
greater than the eort required to compile the binary of a piece of soware from the
source code or, even more simply, copying an existing binary.22
If a piece of soware is covered by a copyle licence, such as the GPL, someone
wishing to make use of the functionality of that soware has two options from a
copyright perspective.23 ey can either agree to comply with the terms of the GPL,
and simply copy the soware, essentially for zero cost, accepting the copyle (and
other) requirements of the GPL, or they can decide to expend engineering eort to
replicate the functionality of the soware by reverse engineering and recreating it.
Recall that copyright protects the expression of an idea and not the underlying
idea itself (although that may potentially be subject to patent protection).24 us it
is possible to determine the functionality (idea) of a piece of soware, and then rep-
licate that soware independently (using a dierent expression), so that the rights
in the new piece of soware belong to its author, and it may be exploited freely by
that author without reference to the rights holders of the original piece of soware25
(assuming no patent issues). Compaq famously employed a reverse- engineering
22 Other issues that may be signicant are the capital cost of the equipment itself, physical space re-
quired to house it, the environment (e.g. humidity, temperature, security), energy supply, and so on. We
explore these in brief later in this chapter.
23 For completeness, two further options are to ignore the licence and infringe the copyright (with
the legal consequences that that might entail), or to persuade the copyright owners of the soware to
grant a licence which is more amenable (possibly at a price)— something Richard Stallman calls buying
exceptions to the GPL.
24 is is somewhat of an over simplication, since it ignores rights that may exist in the structure,
sequence, and organisation of the code and its equivalent in other jurisdictions.
25 Ignoring, for the time being, other rights, particularly patent rights, that may cover the original
soware.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
499
and rewrite (a ‘clean room’) technique to replicate the BIOS26 of the original IBM
PC. is enabled Compaq to create the rst legal IBM PC clones.
A similar reverse- engineering technique can be employed with hardware, such
as mechanical and electronic devices.27
To take an extreme example, there is a monumental dierence in cost between
taking a copy of the Linux kernel (almost zero) and in replicating its functionality
by reverse engineering and recoding it. Even in 2008, when the Linux Kernel was
vastly simpler than it is now, the cost of coding the kernel from scratch was es-
timated by the Linux Foundation at $1.4 billion.28 It is not surprising that busi-
nesses opt to comply with the GPL rather than try to recreate their own compatible
kernel.29
e economics for hardware are liable to be dierent. Given that the instanti-
ation of any piece of hardware is liable to require non- trivial eort in any event,
the dierential in cost between re- engineering a design in a way which does not
impinge on any intellectual property rights, and using an existing open hardware
design (and agreeing to comply with the conditions applicable to it) is likely to be
smaller than the equivalent scenario in soware. e extent to which this is true
will vary signicantly between types of hardware: it is less likely to be true for de-
vices such as microprocessor designs than it is for mechanical suspension parts, for
example.
erefore, before seeking to apply a copyle (or other form of reciprocal) licence
to hardware, it is important to consider the characteristics of the hardware being
licensed: the additional complexity imposed by a copyle licence may not be justi-
ed if it is trivially easy to design around the requirements in any event.
23.5.2 e boundary problem
If copyle is to work eectively in open hardware, there must be some clear limit to
the degree to which the copyle element of a design is intended to aect the rest of
26 Basic Input Output System. is is a relatively small piece of soware embedded in the read- only
memory of a PC which provides a basic hardware interface to the computer’s memory and peripherals,
and an interface to the operating system, such as Windows or (later) Linux. If a PC from a manufac-
turer other than IBM could be made to run a BIOS which was functionally compatible with the IBM PC
BIOS, this would enable it to run soware, including the operating system, which was originally written
for the IBM PC.
27 As we have seen, it is by no means clear that the hardware itself is covered by copyright.
Accordingly, the process of creating an alternate design containing the same functionality, free of any IP,
is relatively more straightforward for hardware than for soware. Furthermore, it is even simpler when
open hardware is concerned, because the design documentation will be available.
28 <https:// www.linu xfou ndat ion.org/ press- rele ase/ 2008/ 10/ linux- fou ndat ion- publis hes- study- est
imat ing- the- value- of- linux/ > accessed 20 April 2022.
29 Another option is for businesses needing a Unix- like kernel who are not keen on using soware
covered by the GPL to adopt FreeBSD, which is licensed under the more liberal BSD licence.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
the design. For example, if a wheel hub is released under an open source hardware
licence, does that mean that if it is included in a front suspension sub- assembly,
that whole of that sub- assembly will become subject to the copyle licence? What
if that sub- assembly is incorporated into a car: does that copyle impact the whole
car and mean that the design for the whole car must be released under the same
licence? ese issues exist for Open Source as well, but the boundaries are reason-
ably well understood (even so, they continue to generate a great deal of debate).
e denitions are somewhat easier in the soware world— the Mozilla licence,
for example, is intended to apply le- level copyle, where the term ‘le’ is reason-
ably well understood; at least it is much better understood than a vague term like
‘sub- assembly’.
e boundary problem also applies in terms of the components of which a de-
sign is composed. What level of detail is required? To take the example of a wheel
hub once more: the hub is likely to require components such as a ball bearing as-
sembly. Ball bearings are available in a number of common sizes and specica-
tions and consist of two concentric hardened steel rings (races) with a number of
hardened steel balls in between them. A reciprocal open source hardware licence
may require that the complete design materials for the product are required. Strict
interpretation could require that the wheel hub design also contains complete
documentation for manufacturing the ball bearing, which in turn would require
complete documentation for manufacturing the steel balls. To take this to a ridicu-
lous extreme, instructions would be required for the manufacture of the entire hub
assembly from its constituent atoms.30 is is not a problem (generally) with so-
ware because, ultimately, the source code provides enough information to compile
the object code of the soware: this is equivalent to saying that there is enough in-
formation for the soware to be manufactured out of the ‘atoms’ which soware is
made of— the binary digits 1 and 0.
By considering both the tangible nature of hardware and the breadth of the
range of classes and categories of item to which the term ‘hardware’ can apply, un-
like the much simpler category of soware covered in Open Source licensing, the
additional complexities become clear.
e reciprocal variants of the current version of the CERN Open Hardware
Licence (version 2) address this issue by exempting from the requirement to
provide the complete design documentation, any components which qualify as
‘Available Components’. We look at this mechanism in greater depth below.
30 An explanation for this oversight may be that many people think of open hardware as being mainly
electronic devices. Electronic construction tends to consist of components, such as resistors, capacitors,
ICs, transistors, and inductors, all being soldered onto a circuit board. e components are all standard
items, with well understood specications, and therefore, it is fairly clear that the level of abstraction
required of the design is at component level.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
501
23.5.3 e competing copyles problem
It is clear that if a copyle licence requires derivatives to be released under exactly
the same licence, then it becomes impossible to combine two works into a third,
being a derivative of both the original works, if each of the original works is sub-
ject to a dierent copyle licence. For example, it is not possible to license a work
consisting of combined GPL and OSL (Open Soware License) components under
only the GPL (as required by the GPL) and only the OSL (as required by the OSL).
e requirements of the two licences cannot be satised simultaneously.
is is a well- known problem for Open Source, with compatibility lacking be-
tween even dierent versions of the GPL.31
e practical issue is that the eectiveness of an open project is understood to
grow, as a network eect, in proportion to the square of the participants.32 e set
of all soware released under a particular copyle licence can be considered to be
a commons, in which all components are freely able to interact. If two commons
of soware projects under dierent licences are unable to interoperate, then each
commons on its own would be a quarter as eective, in terms of potential inter-
actions between the two commons combined.
Attempts have been made to deal with restrictions on interaction: some Open
Source licences explicitly allow relicensing under similar licences. For example,
the European Union Public Licence (EUPL) allows relicensing under the GPL.
However, care has to be taken in allowing relicensing. If someone has chosen a
licence with relatively strong copyle then they are unlikely to be happy with the
ability of anyone downstream to choose a licence which has weaker copyle, or no
copyle at all.
erefore, learning from what has gone before in the world of soware, there
should ideally be only one copyle Open Source hardware licence (or a family
of intercompatible licences), to prevent licence incompatibility through licence
proliferation.
23.6 Hardware and Other Forms of Intellectual
Property Right
23.6.1 Patents
Copyright has been an eective way of controlling the use and exploitation of
soware (and the implementation of copyle), in part because, under the Berne
31 Unless there is an option to take a later version, for example, GPLv2 or later is compatible with
GPL v3.
32 Metcalfe’s law.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
Convention, it arises automatically, without the formality of any assertion or regis-
tration. Patents, in contrast, may provide a number of opportunities to impinge
on the use and exploitation of a piece of hardware but require extensive formality
and budget to obtain and maintain. At rst glance, it may seem that if patents give
a number of opportunities for a licence to impinge during the lifecycle of a piece of
hardware that copyright does not, then for a hardware licence to be eective, and,
in particular, for it to be able to implement copyle, it should concentrate on pa-
tents rather than copyright.
is assumption has a number of diculties:
1. It has been noted that a characteristic of the Open Source development
model is that there is a low barrier to entry for participants. Each participant
in a soware project will automatically obtain copyright in the work that he
or she submits, and this can form the basis of the licensing applicable to the
project, both in relation to third parties and also in relation to the relation-
ship between the participants themselves (as in the case of the Linux kernel,
for example), or the participant and the project sponsor. In contrast, patent
protection is not automatic, so there has to be a more complex mechanism
in place to mediate the relationship between the participants, the sponsor (if
any) and the end users. is will have to take into account the issues set out
shortly.
2. Even relatively small pieces of soware code may attract copyright protec-
tion. A smaller number of designs, whether hardware or soware, will poten-
tially have the necessary quality of inventiveness and novelty to qualify as a
patentable invention.
3. Patents are expensive and take time to apply for. is militates against many
open projects, which have minimal funding. It also requires that some mech-
anism is in place to decide how funding is obtained, and is spent, and which
inventions are worthy of being applied for.
4. Patentable inventions need to be kept secret at the initial stages. is
means in practice that information about the invention needs to be kept to
a small number of people until (dependent upon jurisdiction) it has been
led. is adds complexity (non- disclosure agreements need to be entered
into, and the various recipients of the information need to be trustworthy),
and, crucially, it is contrary to commonly employed Open Source commu-
nity development models, as it is directly in opposition to the principles
of ‘given enough eyeballs, all bugs are shallow’ and ‘release early, release
o e n ’.
5. A patent is only eective in the jurisdiction in which it is granted. Worldwide
coverage requires multiple patent applications and grants, and this multipli-
cation rapidly becomes very expensive.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
503
at is not to say that is impossible to establish a reciprocal open development
model based on patent protection, but these barriers suggest that it is likely to
be more challenging than the equivalent copyright- based Open Source so-
ware model.
For example, the secrecy problem may be addressed by having an inner circle
of developers who have signed mutual non- disclosure agreements (NDAs), and
anyone who comes up with an invention which they feel may be patentable may
apply to join the inner circle, and therefore share his or her invention subject to the
mutual NDAs.
23.6.2 Design rights, database rights, and other intellectual
property rights
Hardware and hardware designs may also be covered by other IP such as design
rights (registered and unregistered), semiconductor topography (mask) rights, and
database rights (for bill of materials, for example). Many Open Source soware li-
cences refer specically to the IP which are most applicable to soware (copyright,
and occasionally patent), without mentioning or allowing for these other rights.
For this reason, licences draed to cover hardware, such as the CERN- OHL family
and the Solderpad licence, either allow for these additional rights explicitly, or they
are carefully draed so as not to limit themselves to any specic underlying rights.
In common with Open Source soware licences, trademarks, if they are men-
tioned at all, are not freely licensed alongside other IP in open hardware licences.
ere may be clauses restricting the use of either the licensor’s or the licence
sponsor’s trademarks to suggest that a modication of a particular design or an art-
icle made to it has been approved by the licensor or the licence sponsor. Trademarks
may be addressed (as sometimes happens in the world of Open Source) through an
orthogonal trademark licence which allows the project trademark and variants of
it to be used only where certain criteria have been met: for example, where an item
meets a particular compatibility standard. e Arduino trademark policy is a good
example of this.33
23.7 Specic Open Hardware Licences
Although licences specically intended for open hardware exist, many open source
hardware projects are licensed under Open Source soware licences (e.g. GPL,
33 <https:// www.ardu ino.cc/ en/ tradem ark> accessed 20 April 2022.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
LGPL, BSD, Apache). ey are also sometimes licensed under content licences
such as one of the Creative Commons family. However, soware and content li-
cences are typically not suited to open hardware, for reasons as diverse as inappro-
priate terminology (e.g. what is the ‘object code’ of an open hardware design?), the
inapplicability of certain types of IP and width of IP that may be applicable as has
been considered earlier.
Accordingly, a number of dierent licences have been developed for use in
open hardware. e most prominent open hardware licences are the CERN
Open Hardware Licence family,34 the TAPR Open Hardware License,35 and the
Solderpad Hardware License. Other licences such as the Open Compute Project
Hardware Licenses have many characteristics of being an open hardware licence,
but the extent to which they qualify as true open hardware licences is up for de-
bate (e.g. the patent licences granted under the Open Compute Project Hardware
Licences are restricted to implementations of the design as specied by the original
licensor, so from this perspective they are better regarded as standards licences
than open hardware licences).
e TAPR licence was developed by attorney and radio amateur John
Ackermann, who acknowledges many of the diculties of applying copyle to
hardware.36 e TAPR licence is intended to be a copyle licence, and although it
acknowledges copyright in the design documentation, it attempts to cover the im-
pingement issue by acting as a contract and thus contractually binding anyone who
relies on the licence to release modications to the design under the same licence.37
e contract is formed by presenting an oer which is capable of acceptance by
anyone wishing to make use of the licensed invention, and as such presents itself as
a unilateral contract, capable of acceptance by conduct, without communication of
that acceptance to the licensor.38 Ackermann is aware of the potential problems in
common law jurisdictions which require consideration of contract, for example a
payment, especially where the licensor does not have any rights (such as a patent)
to license in return. He attempts to deal with this not by granting a licence, which
34 <http:// www.ohwr.org/ proje cts/ cern ohl/ wiki> accessed 20 April 2022.
35 <http:// ww w.tapr.org/ ohl.html> accessed 20 April 2022.
36 <http:// www.tapr.org/ Ackermann_ Open_ S ourc e_ Ha rdwa re_ A rtic le_ 2 009.pdf> accessed 20
April 2022.
37 A number of mechanisms based on contract have been suggested to make reciprocity work for
hardware. e principle is generally that in order to use design A, the licensee enters into a contract with
the licensor, and then whenever the licensee distributes an article made to design A (or a derivative),
this must be subject to the same licence, which is itself a contract, binding on the next downstream li-
censee, and so on. It has been suggested that this can be used to create, contractually, pseudo- IP that do
not otherwise exist at law. However, a contract is only eective between the parties to it. If someone re-
ceives the design, or the documentation, for whatever reason, not subject to the contract, then they will
not be a party to the contract, and will not be bound by the pseudo- IP. If the licence is reliant on real IP,
then someone seeking to exploit the design will have to have some form of licence, and will be in breach
unless they do so, irrespective of whether there is a contract with the rights holder. ere is therefore no
necessity for a contractual chain.
38 Carlill v Carbolic Smoke Ball Company [1892] EWCA Civ 1.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
505
he believes would be failed consideration if there is no underlying IP to license,
but by granting a patent non- assert, which he claims would be eective as it antici-
pates, for example, that the licensor might acquire a relevant patent in the future.39
e CERN Open Hardware Licences take a slightly dierent tack. ey con-
centrate on the design documentation, and the user’s rights (subject to the con-
ditions applying to the licence) are granted once the user performs any act that
would otherwise impinge on an IP in the design documentation. Version 1.2 of the
licence, provides that amendment of the design documentation is conditional on
the publication of the amendments. However, that obligation is suspended until
such time as an instantiation of the design is made available to the public.40 e
1.x versions of the CERN OHL are reciprocal (copyle) licences. Version 2 of the
CERN OHL is somewhat dierent.
It comes in three variants, a permissive variant (which we discuss in the section
to follow), and two reciprocal (or copyle) variants, in ‘strong’ and ‘weak’ forms
(intended to be broadly similar in eect to the GPL and LGPL respectively). As
with version 1.2 of the CERN OHL, the primary focus is on licensing the under-
lying design documentation. As soon as a licensee modies, copies, or otherwise
does anything which requires a licence in relation to the documentation, they are
required to irrevocably undertake to make the source publicly available to anyone
to whom they provide an item made to the design (unless the recipient of the item
already has access to the design— for example, where the licensee gave it to them
personally). e original licensor has the option to add notices to their design
which must be preserved when the design is copied, and those notices can include
a requirement to put a URL on any item made to the design, or on its casing or
packaging, to make it as easy as possible for any recipient of the physical product to
have access to the design.
A key innovation in the CERN OHL is the implementation of ‘Available
Components’. Broadly, the idea is that many designs are likely to consist of a
number of components. For an electronic design, this is likely to include com-
monly available electronic items such resistors, capacitors, and transistors. Where
the components are readily available with appropriate interfacing information
(in the case of an electronic component, this will commonly be supplied as a data
sheet), then there is no need to provide any source for that component. However,
if there are any specialist components (perhaps a component such as an inductor
which has been specially designed for the project) that are not readily available,
then either the source for that component must be supplied under a compatible
licence, or sucient information must otherwise be provided to enable it to be
39 <http:// www.tapr.org/ Ackermann_ Open_ S ourc e_ Ha rdwa re_ A rtic le_ 2 009.pdf> accessed 20 April
2022, and a telephone conversation between John Ackermann and the author.
40 See section 3.3. <https:// ohwr.org/ proj ect/ cern ohl/ wikis/ Docume nts/ CERN- OHL- vers ion- 1.2>
accessed 17 June 2022.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
made. e logic behind this mechanism is to encourage modular thinking and to
avoid the boundary problem. For example, a computer may consist of the com-
ponents: motherboard, a power supply, a case, connectors, memory, disk drives,
etc. Each of those are components, so the computer design can be provided as (at
the top level) a case incorporating a number of components, and then (at the next
level) each of those components can be either available components or they can be
separately licensed under a compatible licence (e.g. a motherboard), and then the
components of that item (e.g. the processor on the motherboard) must itself either
be an available component, or must itself be licensed, and so on. is also makes it
very easy to utilise a part of a design (e.g. the power supply) in another, completely
unrelated design: if it is separately licensed, then there is no need to think hard
about which components of the Notice le need to be retained, for example.
e distinction between the W (weak) and S (strong) versions is quite subtle
and was initially introduced to deal with the rapidly expanding area of open source
silicon.
Briey, open source chip designs are oen released as source code written in a
hardware description language (HDL), such as Verilog. e source code of HDL
looks extremely similar to the source code of a computer program written in a
computer programing language like C. e code describes the interconnection of
components such as logic gates in the design41 as well as more complex compo-
nents. As noted in relation to OpenSPARC earlier, as with a computer program,
other components can be imported into the code as ‘libraries’. ese can potentially
be regarded as available components. Under CERN- OHL- S, the provision which
allows an available component to be provided without also providing the complete
source for it (i.e. if it is readily available with interfacing information) only applies
to physical components. Accordingly, since these libraries are provided in code
form, they are not physical, and therefore the exemption does not apply. e con-
sequence of this is that a designer cannot combine CERN- OHL- S code with other
components to make an HDL code design, unless the complete source for those
other components is also available, and can also be licensed under CERN- OHL- S.
is is similar to the eect of the GPL, which intended to be project- scoped copy-
le. In this case, if you are shipping a silicon chip design in HDL and any of the
components are licensed under CERN- OHL- S, then you are required to release all
of the design, including the included components, under CERN- OHL- S42.
e reality of silicon chip design is that many of the soware tools used to design
chips are proprietary, and contain their own proprietary libraries and so on. As de-
sirable as it is for proponents of hardware freedom to insist that all components on
a chip design are released under a reciprocal (copyle) licence, in many cases that
41 Hence the term sometimes applied to HDL designs: gateware.
42 ere is also a provision which excludes components included ‘as part of the normal distribution
of a tool used to design or Make the Product’. Section 1.7(b)(ii).
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
507
is just not possible where the toolchain consists of proprietary components, and as
a result, a compromise was developed— the CERN- OHL- W.
CERN- OHL- W expands the denition of ‘available component’ to include non-
physical components such as code libraries for silicon chip design. is means that
so long as the library is available, and you have information about how to inter-
face it to the rest of the design, then you do not have to release the code for the
library itself. It is also weaker than the S version in another sense: it is possible
to use W- licensed designs as libraries themselves without the reciprocal eect ap-
plying to the code in which the library is used. In other words, it is possible to use a
CERN- OHL- W licensed non- physical component in conjunction with a chip de-
sign which is licensed under a completely dierent (even a proprietary) licence
without all of the code being released under CERN- OHL- W. Any changes to the
CERN- OHL- W component will have to be made available to the recipient, and
made available under the same licence, but, provided that the rest of the design
integrates with the CERN- OHL- W component through its documented interface,
there is no requirement to release the rest of the design under that licence. In that
way, it’s possible to combine CERN- OHL- W- licensed components with compo-
nents licensed under dierent (even proprietary) licences.
ose familiar with Open Source soware licensing will recognise that this is a
similar eect to the one implemented by the LGPL. e distinction is that whereas
the LGPL permits the code licensed under it to be linked to proprietary code, it is
not possible to incorporate proprietary components within an LGPL- licensed li-
brary, the CERN- OHL- W allows both types of combination.
e CERN- OHL 2.0 family of licences also adopts a number of mechanisms
similar to those found in Open Source licences: there is a patent licence and re-
taliation clause similar to Apache 2.0 and a cure period for breach similar to
GPLv3.43
Although the CERN- OHL 2.0 family is not primarily designed for use with so-
ware, it was acknowledged that there may be circumstances in which designers
may want to have the whole of a hardware design, and the soware used in it e.g.
in its rmware) licensed under the same licence.44 For this reason the draers de-
cided to submit the three licences to the OSI for ocial approval as Open Source
soware licences. Approval was granted in January 2021. e three CERN- OHL v2
licences are the rst licences designed primarily for open hardware to be approved
by OSI.
43 See <https:// w ww.ohwr.org/ cern ohl> accessed 20 April 2022. for more information.
44 In order to avoid the creation of yet another incompatible commons of soware projects licensed
under a new reciprocal/ copyle licence, CERN recommends that where soware is licensed under the
CERN- OHL- W or - S, the licensor should give consideration to dual licensing it under an equivalent
soware licence, such as LGPLv3 or GPLv3.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
23.8 Non- copyle Hardware Licences
In many cases, it may be more straightforward to use a non-copyle licence. e
Solderpad Hardware License has been developed, based on Apache 2.0 Open
Source soware licence. e changes revolve mainly around terminology (e.g. ex-
panding the denition of ‘source form’ to cover more hardware- related forms of
documentation), and also the expansion of the types of IP which are covered (data-
base right, for example).45 e current version acts as a ‘wraparound licence’ which
adds additional permissions and denitions to the underlying Apache 2.0 licence.
It also explicitly allows a licensee to regard anything licensed under the Solderpad
licence as licensed under plain Apache 2.0. In this way, even though Solderpad is
not a licence approved by the OSI (it is not a soware licence), anything licensed
under it can be regarded as licensed under Apache 2.0 which is an OSI approved
licence. Solderpad is, in eect a dual licence: Solderpad and Apache 2.0, at any
licensee’s option.
Version 2.0 of the CERN- OHL includes a permissive variant. is removes the
reciprocal requirement of CERN- OHL and does not require anyone conveying ei-
ther a product made in accordance with a CERN- OHL- P- licensed design, or the
design incorporating the materials themselves, to be licensed under CERN- OHL-
P. It does, however, require the retention of any notices. is is similar in eect
to the Apache 2.0 licence, in that it allows free intermingling of code under that
licence, and other licences, and distribution of that code under any other licence
including a proprietary licence, provided that attributions and notices are retained.
As mentioned earlier, CERN- OHL- P is an OSI- approved Open Source licence.
23.9 Open Source Hardware: Development Models
It is generally accepted that one of the drivers to success of Open Source soware
is that there are very low barriers to entry for participation in many projects. e
projects are typically hosted on publicly accessible repositories such as GitLab, and
are typically written in languages where the tools— compilers, development envir-
onments, and debuggers— are themselves free soware. A modest computer, a reli-
able power supply, and an Internet connection are all that is required to participate.
is makes it very easy for individuals to collaborate wherever they are located
in the world, and the nature of soware means that it is very easy to develop, test
and launch a soware product as all these activities occur within the virtual digital
domain.
45 <http:// solder pad.org/ licen ses/ > accessed 20 April 2022.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
509
e following diagram explains the development cycle:
Simulate
Design
Test Build Productize
Customer
e core cycle is Design > Build > Test > Design.
In the soware world, this typically consists of writing the soware (Design), com-
piling it (Build), and testing it (Test). is process then loops until the soware is ready
for release, in which case it is made available to the public, maybe by placing the exe-
cutable in an install package and publishing it on a website, or loading it into a device
as rmware which is then shipped. In the world of Open Source, there may be no
meaningful productization step, as the soware is consistently available as it develops,
and where a project has release cycles, it will also update on a much more frequent ca-
dence than proprietary code. Nonetheless, all these activities will take place in the low-
cost, low- barrier to entry into the virtual world (except possibly, in a limited number
of cases, the productization step). is means the development cycle can be very rapid.
e same core cycle applies to hardware, but it is not necessarily the case that all of
it can take place in the low- friction virtual world. In fact, by denition at the very least,
the productization and distribution steps must take place in the real, physical world, as
may, in practice, other steps.
Increasingly, as a substitute for the build phase, soware tools and methodologies
including computer- aided design (CAD) and nite element analysis simulation tools
can be deployed, enabling much of the development and testing to take place in the vir-
tual world: computers can model things as diverse as earthquake stresses on bridges,
the aerodynamic drag of car bodies, the thermal eect of dierent sorts of insulation
on buildings, radio frequency emissions and susceptibility of electronic circuit boards,
and the damping eect of suspension components, and therefore the Design > Build >
Test cycle can in some cases be made more ecient, cheaper, and faster by substituting
it with a Design > Simulate > Test cycle, but even so, there are limitations to the eect-
iveness of these tools. Another factor is cost: in contrast to the soware arena, where
some of the nest tools (e.g. the Gnu Compiler Collection) are available for zero cost
as Open Source and have become an industry standard, the hardware world lacks an
equivalent richness of Open Source tools, and even where the cycle takes place en-
tirely in the digital world, this may require the use of proprietary tools.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
is is a potential inhibitor to the eciency of the open development process
as it applies to hardware, and this presupposes that the activities can take place
virtually.
Where the development activities have to take place in the real world (e.g.
building a dump truck), this can introduce signicant expense: it may require a
factory, large amounts of energy, expensive capital equipment (lathes, milling ma-
chines, materials handling equipment), expensive raw materials (nuts, bolts, steel
rods, and steel sheet), physical space and environmental requirements (e.g. a sil-
icon chip foundry will have to be very tightly controlled for dust). And each of
these will have to be of a certain and replicable quality. Silicon chips require ultra-
pure cylinders of silicon, and even fasteners like nuts and bolts have to be of a cer-
tain specication and tensile strength46. is also applies to energy: many activities
will require a reliable electricity supply without brownouts or spikes. Regulation
may be relevant: some activities (making and developing pharmaceuticals and ex-
plosives, for example) are very highly regulated. ere are even signicant regula-
tions applicable to the food and agricultural sectors. is is all much less likely to be
the case when dealing with pure soware.
All of these things add barriers to entry to the process, inhibiting individuals
from entering the cycle, and slowing the cycle itself.
is means that assumptions at the heart of Open Source soware and, in par-
ticular, the licensing and development models, do not necessarily map well to
Open Source hardware, and the extent to which they are likely to map eectively
depends very much on how similar the open hardware domain is to soware.
As we have seen, hardware description languages are very similar to computer
soware languages, and can describe complete microprocessor cores. Almost all
of the cycle can take place entirely in soware, and indeed communities have de-
veloped, very similar to Open Source soware communities, around dierent var-
ieties of core (and other associated components). Librecores is one directory of
these components.47 e development of these cores can happen entirely within
the digital domain (including simulation and testing for physical characteristics
such as thermal requirements, electrical load, and radiofrequency emissivity). It is
only at the productisation stage that the core interacts with the physical world, and
even then, in many cases, a digital representation of the core (called a ‘bitstream’)
can be created which can be loaded onto a multi- purpose silicon chip called an
FPGA. ese chips are readily available components, and can cost as little as $5
46 Incidentally, this highlights another dierence between hardware and soware. Whereas ‘com-
plete corresponding source’ in an Open Source licence such as GPL may require the provision of build
instructions specifying various conguration les, and the use of certain compilers and linkers within
the toolchain, and associated scripts, the extent of similar instructions in hardware may need to be that
much greater. Bolts may need to be fastened to a specied torque, uid levels may need to be measured
at a specic temperature, and an analogue radio receiver may need to be set up by adjusting trimmers in
a particular sequence.
47 <https:// ww w.lib reco res.org> accessed 20 April 2022.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022
511
each (or even less in bulk).48 is means that the development cycle for cores can
be very rapid, and the cost of production can be low. In addition, there has been
increasing work in the development of open source toolchains, and there now exist
a number of open source toolchains which can simulate and synthesise open hard-
ware components such as cores, written in languages like Verilog.
Accordingly, assumptions which apply to the Open Source soware develop-
ment process, and its emergent aspects like community development and business
models can also apply to the development of processor cores.
For something like an open source car, these dynamics are much less likely to
apply, and open source soware assumptions are therefore less likely to apply.
23.10 Conclusion
Open source hardware is a relative newcomer in comparison with Open Source
soware. As a eld it has adopted many assumptions and models from the world of
Open Source soware, but its latecomer status gives it the advantage of being able
to learn from what has gone before.
It is yet to be seen whether the reciprocal (copyle) model will be as successful
in open source hardware as it has been in Open Source soware. Its applicability is
less straightforward owing to the breadth of IP which can potentially impinge on
hardware, coupled with the deceased opportunity for each IP to impinge.
It may well be the case that some types of open source hardware (such as cores)
map more closely onto our understanding of the development processes, commu-
nity dynamics, and business models which are applicable to Open Source soware
than others.
Open source hardware is a dynamic and interesting eld, and is starting to garner
signicant investment and involvement from industry, and attention from govern-
ment and policy- makers. In many ways, it will learn from and develop alongside Open
Source soware but there is still space for it to develop its own direction and dynamics.
48 e nal product may be the FPGA with the relevant core’s bitstream installed in it or, if the core is
required in much greater volume, a single- purpose chip— an ASIC —can be produced using that core.
It is very expensive to manufacture ASICs because it requires preparing semiconductor masks, and set-
ting up costly specialised equipment, but once that has been done, they can be manufactured in bulk
very cheaply.
Downloaded from https://academic.oup.com/book/44727/chapter/378969450 by guest on 04 November 2022