White paper for the EC, January 2020

From F-Si wiki
Jump to navigation Jump to search

This white paper contains comments and recommendations for the European Commission (EC) about Free and Open-Source (FOS) Silicon Hardware, as asked by the Commission to all participants at the end of the "Workshop about the future of Open Source Software and Open Source Hardware" on November 14 and 15 2019 in Brussels [1].

Update (2/2020): the paper was delivered to the EC at the end of January. For any further discussion, please reply to the Mastodon thread where the letter was announced publicly. This mediawiki page is now locked.

Free/libre licences

Problem statement

Not all open-source licences are equivalent. Some favour enterprises who do not support a truly collaborative environment, and others foster the creation of a shared code-base in the interests of the General Public and of SMEs. Some licences can on the long run weaken the open-source community, others can encourage fair competition between those enterprises who decide to contribute to open-source.

Different groups of interest, such as the giants of the web (Google, Amazon, Facebook, Apple, Microsoft, or GAFAM in short), versus small and medium enterprises (SMEs) and non-profit organizations (NPOs) like the Free Software Foundation, have different and sometimes conflicting interests which are reflected by different licence choices. As a rule of thumb, the most convenient open-source licences for the GAFAM are permissive licences, while SMEs and NPOs prefer copyleft.

Even for individual interest groups, such as NPOs alone, there is no universal licence which suits optimally all cases. For example, while a copyleft (GPL-like) licence is often a good choice for the General Public interest, there are cases where the adoption of a permissive licence can have a better impact on the community, such as when dealing with standards which shall be adopted widely.

For the case of free and open-source (FOS) hardware, much can be learned from the FOS software domain. For better conveying the message of this paper, however, we classify open-source licences into the following two categories:

1. Temporarily-open licences. These are the "permissive" licences such as BSD, Apache or MIT, which "permit" third parties (such as the GAFAM) to close the source code again. A prominent example using this type of licence is the BSD operating system, which became part of proprietary software used for example inside iOS, Whatsapp or Netflix.

2. Forever-open licences. These are the (weak- and strong-) copyleft licences which guarantee that the source-code must remain open forever such as the GNU General Public Licence (GPL). A prominent example using a GPL licence is the Linux kernel, which is today used in the majority of web servers, in uncountable academic projects and is inside 80% of the smartphones (kernel of Android).

Several examples demonstrate that the temporarily-open licences are not sustainable in the sense that the code (especially when of high quality) is eventually closed into a proprietary product, and that if an open-source version remains, this is not guaranteed to contain the latest progresses and updates which are present into the proprietary version. Under a temporarily-open licence this practice is perfectly legal, and is in fact a major incentive for adopting this licence. Some people argue that most companies are socially responsible, and that they will do their best to open-source anything they can. However, the experience with companies like the GAFAM shows how ethical, or even legally-enforced, obligations, are systematically ignored, for example when it comes to paying taxes.

Forever-open licences protect the interest of enterprises who contribute to open-source and foster a healthy competition. If an SME for example decides to release in the open-domain a program which could be shipped by its competitors inside their products, it is clear that the SME will prefer not to allow the competition to simply internalize such a program without having, in turn, to contribute back to the project by publishing all improvements which have been added. This can be enforced only by forever-open copyleft licences such as the General Public Licence (GPL) or the Lesser General Public Licence (LGPL), and not by temporarily-open (permissive) licences like the Apache licence.

Such arguments do not apply to companies which maintain a monopolistic code development approach (think about Android for example). These companies in fact do not need copyleft to prevent third parties from making "unfair" use of their code, but can use instead immense human resources to maintain an edge on the mainline development. On the contrary, they prefer not to use copyleft, so that they are allowed to publish the source-code when they wish, not when they ship a binary (like a security update), therefore maintaining an intrinsic advantage over competition. Think for example how Google could impose to Huawei to stop using Android even if Android has always been marketed as open-source.

Healthy vs. unhealthy open-source. There is open-source software which fosters cooperation, and there is open-source software which kills competition. Advertising a software, like Android, as open-source software is a clever marketing strategy. However, open-source software which is not well documented, or which is so complex that just one entity (in this example Google) can understand it and patch it with security updates, is not software which fosters a healthy competition where other entities have equal chances of branching, forking, or contributing in similar measures to the code.

How the software ecosystem will look in ten or fifty years from now, depends from the rules which are being enforced today, and most importantly by the licences being adopted. This is illustrated by the two following thought-experiments:

In the hypothetical case that only permissive open-source licences were used, companies like the GAFAM would always have an advantage over the public domain. This is a trivial corollary which follows the fact that the code-base of a company will always contain at least the code in the public domain, plus the code developed internally.

Vice-versa, in the hypothetical case that only copyleft open-source licences were used, the code in the public domain will always be larger than the “open-source” code developed by a single entity. Again, this is a trivial corollary which follows the fact that all the “open-source” code developed by a corporation is also part of the public domain.

Beyond the distinction between forever-open and temporarily-open licences mentioned above, patents are important too. The MIT licence for example, allows a publisher of source-code to sue its own users for patent infringement. It must be noticed that a court case of this type is not known but there may have been secret cases, and the threat remains. Google wisely avoids MIT licences and prefers licences like the Apache licence which includes a patent clause explicitly forbidding such a behaviour.

Solutions and recommendations to the EC

  • Encourage the use of forever-open licences (copyleft) whenever possible. This should be mandatory for all public funded projects and for universities, unless special exceptions apply (details can be discussed in the future).
  • Patent fair play: Force universities and public-funded projects to add a clause to all of their patents which grants copylefted projects a perpetual royalty-free permission of using their invention. In other words this condition says “as far as you contribute to the common good by publishing your work using a copyleft licence, your work is allowed to use our invention at no cost”. This, or similar incentives, are important to encourage the use of copyleft licences. Patents are important because in the context of silicon chips, there is a very large amount of IP.
  • The fragmentation of licences is a big obstacle, therefore, do not develop a new licence like the 2007 "European Union Public Licence", but support instead those already existing (or those currently being developed to fill the void when protecting silicon chips like the CERN OHL v2).
  • Take into account that the Open Source Initiative (OSI) represents well the interests of the GAFAM, and less the interests of the General Public. Ask for general consensus from NPOs like April (https://april.org), the FSF (https://fsf.org), and from well-known General Public digital activists such as Aral Balkan (https://ar.al/).
  • Encourage schools and university to teach how licences work. Academic papers and direct experience, in fact, show how the average engineer is totally unaware of the meaning of the different licences and cannot even distinguish between a copyleft and a permissive one.
  • People who receive funding by companies like the GAFAM, which is a frequent case in European academia, have a conflict of interest when it comes to choosing a licence. Require people to declare such conflicts of interest whenever called to advise policy makers.

Critical infrastructure

Problem statement

Today European’s society and economy are highly intertwined with the digital world and thus it is crucial to be in control of it. However, Europe is far from being sovereign in the digital domain, and especially in the design and manufacturing of core hardware components. Electronics industries in the EU are definitely not as developed as in the US or in China. The equivalent of a "Silicon Valley" is missing in Europe. As a consequence a large part of the European digital infrastructure relies on components fabricated abroad, which can possibly contain undesired features and which have not been necessarily developed based on Europe’s interests. Further, digital integrated circuits (ICs) tend to be complicated and prone to accidental and intentional security vulnerabilities. Detecting this kind of weaknesses is especially hard when the circuits cannot be fully inspected (even if the high-level code of the circuits is open, then it is still hard to verify that the physical chip does not contain any additional backdoors).

In order to make a digital IC fully auditable by the community, the following conditions must be met:

  • The high-level description of the chip, such as the Register Transfer Level (RTL) code, must be public.
  • The layout of the chip must be public.
  • It must be possible to verify that the layout actually corresponds to the RTL code. This requires that the software (EDA tools) utilized to transform RTL code into layout is available.

Solutions and recommendations to the EC

We recommend that the EC fosters a community-driven approach to develop FOS silicon chips and FOS EDA tools therefore making the above conditions possible.

Obstacles to the creation of truly FOS silicon chips

Problem statement

Today it is (almost) impossible to publish a chip design in its entirely, namely from abstract Register Transfer Level (RTL) design down to silicon layouts (which contain the exact information on the shape of the transistors and metal wirings between them). There are two reasons for this:

1. (Nearly) all silicon chips are designed using one of the three dominant Electronic Design Automation (EDA) tools (Cadence, Synopsys and Mentor). These EDA tools are shipped with very restrictive licences and user agreements which explicitly forbid users from publishing anything which has been created with their tools. This condition alone is sufficient to kill open-hardware, and it is comparable to the hypothetical and absurd case of somebody writing a book with Microsoft Word and then not being able to publish the book because, allegedly, this could reveal how proprietary algorithms, like the automatic grammar correction, work.

2. The silicon foundries, which fabricate the chips upon reception of a layout from the designer, impose restrictive NDAs which prevent from publishing any details about the process, including the layouts of the transistors that they provide to the designers via the Process Design Kit (PDK). Fortunately, there are foundries which are increasingly interested to relaxing such restrictions, and it is foreseeable that once FOS silicon will become more popular, more and more foundries will release openly their PDK.

Solutions and recommendations to the EC

  • Foster FOS EDA tools: It is clear that the restrictions imposed by proprietary EDA companies must be cleared. Some propose to approach them and convince them to relax their constraints. However we believe that this will never occur, or at least not the the extent needed. In our opinion it is clear therefore that the EC should foster a complete set of EDA tools which consists of Free and Open-Source software. This is also one of the key objectives of the F-Si, and, as demonstrated during the last Free Silicon Conference (FSiC), FOS EDA tools are already capable of designing small digital circuits (see the talk by Tim Edwards and video therein).
  • Enable and encourage European universities to cooperate. Each university shall become the centre of competence of individual expertises, for example a university could become leader in memory compilers, while another could become the leader in place-and-route algorithms. Fortunately, it is likely that a large part of the knowledge currently incorporated in the leading proprietary EDA tools once stepped out of academia. In fact, an incredible amount of knowledge is documented in papers and books.

Electronic Design Automation (EDA) tools captivity

Problem statement

The degree of standardization in the domain of silicon design and manufacturing is currently very primitive. For example, designing a silicon chip for a certain silicon technology requires accessing a number of files specific to the corresponding foundry. These files specify for example the compact models of the transistors, the timing information of the standard cells, the physical properties (such as thickness and dielectric constant) of the material utilized, and the Design Rules (DRs) which shall not be violated. Such files are usually shipped in formats which are often unique to one of the major EDA companies. Since it is standard for most companies to design chips for more than one foundry, these are obliged to purchase the licence for a same tool from multiple EDA vendors. Such a variety of tools increases the costs for maintaining and operating them.

Solutions and recommendations to the EC

  • foster an ecosystem of Free and Open Source EDA tools which will automatically lead to the creation of open standards, and their acceptance in a wider context.

How to establish a value chain

Problem statement

How can EU grow in competitiveness, and create a fertile ecosystem for FOS silicon development?

Solutions and recommendations to the EC

  • The large adoption of copyleft licences is crucial especially on the long run. The example of Owncloud (owned by private investors) being able to fork into NextCloud (adopting purely copyleft licence, and offering support as business model) is an illuminating example of the role of licences. The founder Frank Karlitschek illustrated this nicely in a public talk available at https://conf.tube/videos/watch/05857289-4f99-4109-bd71-f5e0a779a544.
  • Make it easier for companies to finance FOS developers which adopts high standards like NextCloud. For example, make sure that every service purchased by (or every donation to) a company like NextCloud can be tax-free (clearly more discussions are required to identify ethical companies from others, and possible criteria can involve whether they adopt a copyleft licence or not).
  • Define a "standard", i.e. a set of requirements, which qualify a company eligible of the tax-free support mentioned at the previous point. Call such a standard "ethical" to stress that the value is not measured in terms of revenue but in terms of abstract impact on the General Public interests.
  • Put SMEs and start-ups in the condition of experimenting which is the most successful business model for FOS companies. The example of NextCloud and RedHat, which monetise on support, is excellent; but is this the best model?
  • Large investments are needed. Building a domestic open-source microprocessor capable of competing, say, with an Intel microprocessor costs tens of million EUR for the mask-set alone. The full design and ecosystem is orders-of-magnitudes more expensive. The EC should plan for this type of investments in the future. Intermediate steps, such as the creation of other critical components of the digital infrastructure, like routes or modems (which are mush simpler and cheaper to produce than a PC microprocessor) can be targeted first.
  • Encourage universities to cooperate with each others, to exchange designs, to synchronize on developing complementary core expertises (high-level supervision by the EU may be required).
  • Support NGO entities working for the General Public interest.

US vs. EU investments in open-source EDA and open-source hardware

Problem statement

With the Electronics Resurgence Initiative (ERI) the US has decided in 2017 to invest $1.5 billion to advance the architecture, the materials and design tools for silicon chips [2]. The ERI is the background for other US projects like the posh open-source hardware (POSH) program [3] and OpenRoad [4] which explicitly target open-source electronic design automation (EDA) tools. The OpenRoad project repository currently counts 16 projects, of which only three are licenced forever-open (GPL), and thirteen are licenced temporarily-open.

Quoting an MIT Technology Review article, “The US military agency is worried the country could lose its edge in semiconductor chips” [5]. How the US military plans to use open-source while still keeping its edge over other Countries can just be speculated based on earlier behaviour, such as the famous “Embrace, Extend, Extinguish” term coined at Microsoft, or by drafting early standards as explained in one of the slides leaked by Snowden [“What’s the Threat” on page 96 of https://static.macmillan.com/static/holt/greenwald/NoPlaceToHide-Documents-Uncompressed.pdf ]. Certainly, the US DoD is interested to keep its domestic EDA companies, Cadence and Synopsys, in a dominant position. If open-source EDA tools are published with permissive licences, like most of the OpenRoad projects, it is clear that Cadence and Synopsys will easily maintain their dominant position by including in their proprietary tools the best from the open-source domain. Notoriously, DARPA let circulate several letters within US academia strongly discouraging any use of forever-open copyleft licences.

Geopolitical influence. It is well known within the community of chip designers that the full licence costs of Cadence and Synopsys are extremely high and strictly secret. Many SMEs indeed cannot afford to pay them. It is a common practice therefore to negotiate these costs with Cadence and Synopsys, which sometimes even ask for the business plan of the interested companies. The criteria based on which Cadence and Synopsys decide the discount amount (which is usually very substantial) are not known. It is clear therefore that the discount strategy allows Cadence and Synopsys to decide which company is given the chance to exist or not, therefore paving the way to geopolitical influence.

Solutions and recommendations to the EC

  • The fact that US DoD invests in open-source demonstrates the point that open-source is a better development strategy.
  • Adopt the opposite licence scheme as the US DoD. In fact, the EU should invest in a sustainable ecosystem, rather than favouring the US dominant EDA vendors.
  • Foster FOS EDA tools to mitigate the dependency from US EDA tools. This will strengthen the EU enterprises, which in turn will diminish the migration of highly-qualified European citizens outside of the EU. The EU, in fact, offers excellent electronics education, but has few companies which can take advantage of this.