[U-Boot] GPL license statement

Wolfgang Denk wd at denx.de
Sun Jan 18 20:34:26 CET 2015


Hello all,

every now and then a new round of discussions about the U-Boot
licensing terms comes to boil.  As I started this project nearly
15 years ago, and still regularly participate in it's development
processes, I've been asked to comment on this topic.  Here we go:


Legal disclaimer:  I am speaking for myself only.  I do not claim to
represent the opinion of the community, nor that of my employer, DENX.


Short answer / management summary:
----------------------------------

The U-Boot project uses version 2 of the GNU General Public License
as published by the Free Software Foundation as general license.

This is version 2 only, not version 3, not even "version 2 or any
later version”.

There are no plans nor any ongoing activities to change that.

Any attempts to re-license U-Boot under a different license (say,
GPL-3.0 [1]) would require an enormous amount of efforts.  I have
never seen any indications that any entity would be willing to start
any such development or pay for the necessary efforts.


Long answer including background information:
---------------------------------------------

U-Boot is a community project, and development is driven by
contributions from the community.

There may be a large number of source files in the U-Boot project
which are coyrighted by me, but that does not mean much.  I am just a
small part of this community.

No individual entity, person or company, has sole power of
representation so he could decide which direction the development
takes.  They can submit proposals and patches, but that does not mean
that the community will automatically accept these.  They can even
create forks of the U-Boot project, but again it is up to the
community to decide what constitutes the "mainline" version of U-Boot
that is supported by the community.  In the end it is up for the
community to decide what is considered best and what will be publicly
accepted.


The project wide license for U-Boot is GPL-2.0.  Individual files are
covered by other, compatible licenses, but the license for the U-Boot
image that you will install and run on your devices is GPL-2.0.

If anybody wanted to change this licensing, that would require
considerable efforts.  Assume we attempt to make the smallest possible
change:  open the path for later versions of the GPL, i. e. introduce
GPL-2.0+ as general U-Boot license.  That would mean that all files in
U-Boot that are currently covered by GPL-2.0 only whould need to be
either removed, relicenced by their respective authors, or reimplemen-
ted from scratch.  This affects a LOT of code.  U-Boot was created with
the explicit intention to borrow as much code from the Linux kernel as
possible.  And that was done.  And Linux is licensed unter GPL-2.0.
In the result, not only a lot of individual files, but whole
sub-systems in U-Boot are covered by GPL-2.0: whole MTD / UBI / UBIFS
as well as most other file system code, many device drivers, large
parts of the networking code, etc. etc.  So what are the options?

- If we remove all such code, U-Boot would no longer compile or fail
  to boot on the overwhelming majority of supported systems - and on
  the remaining ones the functionality would be so crippled to render
  it basically unusable.
- Trying to contact all individual authors who contributed parts to
  the GPL-2.0 code in U-Boot would be not only a Sisyphean task, but
  it would also be bound to fail, as some of the involved authors have
  clearly delcared in the past that they refuse to do so.
- So remains reimplementing all these missing parts from scratch,
  and getting it into a usable state on the plethora of systems
  supported by U-Boot.  That would be a tremendous effort, worth
  probably several man-years of development.  So far, nobody ever even
  came close to seriously considering such a venture.


So U-Boot is stuck with status quo - it's licensed under GPL-2.0.


But why are there any discussions at all? What could be reasons that
would eventually motivate the community to change the status quo of
U-Boot licensing?


License terms have always been a somewhat controversial issue.  This
is unavoidable, as there are many different interests.  Just to give
two examples:

1. Device Owner:

   Assume there is a developer who has been actively contributing to
   the development of U-Boot for a number of years, dedicating a
   significant amount of efforts to the community.  Then he buys some
   device, and quickly finds out:

   - There is an annoying bug or problem or limitation of functio-
     nality in the device, and the vendor is not going to fix that.
   - The device is running U-Boot, and the bug is in the vendor
     provided U-Boot code.  You can easily verify this because the
     vendor prvides the full source code of U-Boot as required by GPL.
   - The problem is trivial to fix, for example simply by upgrading to
     a more recent version of U-Boot.
   - It is impossible to install a different version of U-Boot on the
     device, because the device accepts only cryptographically signed
     versions of U-Boot, and the vendor does not provide access to the
     keys needed for signing any custom version.

   So even though it's your own code running on the device you own,
   and you have full access to the source code, you are still locked
   out, unable to fix the problems you are suffering from.

   I think it is perfectly comprehensible if such a device owner
   would much rather have that U-Boot was licensed under GPL-3.0,
   where the vendor would have to provide access to the keys needed
   to create images that can be installed on the device.

   I.e., there are very good reasons why we should switch to GPL-3.0
   as soon as possible.

2. Device Manufacturer:

   Assume there is a manucacturer of devices that are deployed in
   "sensitive areas".  This is a wide area - here is just a short
   list of (real life) examples what this could include:

   - Smart Meters: You don't want to anybody mess with your account,
     or gets access to data you consider private.
   - Fire detector and burglar detection systems: Private or even
     public scurity would suffer if someone could install hacked
     software.
   - Medical equipment: Human health and even lifes could be at risk
     if modified software is running.
   - Gaming machines: A lot of money could be at stake if other than
     the officially approved code could be made to run.
   ...

   I think it is perfectly comprehensible that GPL-3.0 is totally
   unacceptable to such a device manufacturer.

   I.e., there are very good reasons never ever to switch to GPL-3.0.


Obviously we have a conflict here, that neither GPL-2.0 nor GPL-3.0
can resolve. It appears there is not (at least not yet) any licensing
model that could cover all interests.  So what can we do?

Actually we can do very little.  It boils down to two things:

- Hoping that some later version of the GPL might be able to cover the
  gap of interests so it would be considered a usable alternative by
  the majority of the community.  [There is no doubt that GPL-3.0
  is not able to do that.]
- Making sure that any future project for such a relicensing will not
  be made even harder that it already is;  this is why we ask that
  ``all new code that gets added to U-Boot shall use a "GPL-2.0+"
  SPDX-License-Identifier.''

Actually it is probably this latter clause which fuels discussions
about an imminent switch to GPL-3.0.  None of these discussions (at
least none that I am aware of) have any rational background, though;
in many cases they ware just caused by misunderstandings or mis-
information, and in some events they were attempts to spread FUD.

In reality, there is no reason for excitement: U-Boot is licensed
under GPL-2.0, and as far as I can tell it it will main so, at least
in the foreseeable future.

January 2015, Wolfgang Denk



[1] In this text, I use the SPDX License Tags as used within the hole
    U-Boot source code to refer to specific license terms; please see
    [2] for details.

[2] http://git.denx.de/?p=u-boot.git;a=blob;f=Licenses/README



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The ultimate barrier is one's viewpoint.
                        - Terry Pratchett, _The Dark Side of the Sun_



More information about the U-Boot mailing list