intel-microcode: new package

Is there a license file somewhere that states that even though it is proprietary, one has the right to redistribute the binaries?

On the Intel download site, after searching for the last version of the microcode data file [1], the download link leads to a license agreement page which describes three license terms, depending on the nature of the distributor (network administrator, end user or OEM). I think the OEM license applies to most buildroot users. Here is the content :

Ok. Thanks. And there is no zip file or tarball that contains both the license and the firmware? I'm simply worried about having just FOO_LICENSE = PROPRIETARY without a proper license file that indicates what license it is. Or maybe we need to put a special license file in package/intel-microcode/ and find a way to tell the license infrastructure that the license file is here rather than in the package itself?

Unfortunately no, the microcode file is the only one.

Signed-off-by Richard Braun <[email protected]>

---
 package/pkg-generic.mk |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

package/pkg-generic.mk +1 -5

index ffe7dfb..1bfaed2 100644
@@ -444,7 +444,6 @@ $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)
 endif
 
 # legal-info: declare dependencies and set values used later for the manifest
-ifneq ($$($(2)_LICENSE),PROPRIETARY)
 ifneq ($$($(2)_SITE_METHOD),local)
 ifneq ($$($(2)_SITE_METHOD),override)
 # Packages that have a tarball need it downloaded and extracted beforehand

@@ -455,7 +454,6 @@ $(2)_MANIFEST_LICENSE_FILES = $$($(2)_LICENSE_FILES)
 endif
 endif
 endif
-endif
 # defaults for packages without tarball or license files
 $(2)_MANIFEST_TARBALL ?= not saved
 $(2)_MANIFEST_LICENSE_FILES ?= not saved

@@ -464,9 +462,7 @@ $(2)_MANIFEST_LICENSE_FILES ?= not saved
 $(1)-legal-info:
 # Packages without a source are assumed to be part of Buildroot, skip them.
 ifneq ($(call qstrip,$$($(2)_SOURCE)),)
-ifeq ($$($(2)_LICENSE),PROPRIETARY)
-# Proprietary packages: nothing to save
-else ifeq ($$($(2)_SITE_METHOD),local)
+ifeq ($$($(2)_SITE_METHOD),local)
 # Packages without a tarball: don't save and warn
 	@$(call legal-warning-pkg-savednothing,$$($(2)_RAWNAME),local)
 else ifeq ($$($(2)_SITE_METHOD),override)

Dear Richard Braun,

This will need a review and ACK from Luca, Cc'ing him.

Quoted 6 lines

Signed-off-by Richard Braun <[email protected]>

---
 package/pkg-generic.mk |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

package/pkg-generic.mk $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2) · line 446

Quoted 8 lines

package/pkg-generic.mk +0 -0

index ffe7dfb..1bfaed2 100644
@@ -444,7 +444,6 @@ $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)
 endif
 
 # legal-info: declare dependencies and set values used later for the

package/pkg-generic.mk $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2)

Quoted 4 lines

package/pkg-generic.mk +0 -1

-ifneq ($$($(2)_LICENSE),PROPRIETARY)
 ifneq ($$($(2)_SITE_METHOD),local)
 ifneq ($$($(2)_SITE_METHOD),override)
 # Packages that have a tarball need it downloaded and extracted

package/pkg-generic.mk $(2)_MANIFEST_LICENSE_FILES ?= not saved · line 463

Quoted 11 lines

package/pkg-generic.mk +0 -1

@@ -455,7 +454,6 @@ $(2)_MANIFEST_LICENSE_FILES = $$($(2)_LICENSE_FILES)
 endif
 endif
 endif
-endif
 # defaults for packages without tarball or license files
 $(2)_MANIFEST_TARBALL ?= not saved
 $(2)_MANIFEST_LICENSE_FILES ?= not saved

@@ -464,9 +462,7 @@ $(2)_MANIFEST_LICENSE_FILES ?= not saved
 $(1)-legal-info:
 # Packages without a source are assumed to be part of Buildroot, skip

package/pkg-generic.mk $(2)_MANIFEST_LICENSE_FILES ?= not saved · line 468

Quoted 8 lines

package/pkg-generic.mk +1 -3

 ifneq ($(call qstrip,$$($(2)_SOURCE)),)
-ifeq ($$($(2)_LICENSE),PROPRIETARY)
-# Proprietary packages: nothing to save
-else ifeq ($$($(2)_SITE_METHOD),local)
+ifeq ($$($(2)_SITE_METHOD),local)
 # Packages without a tarball: don't save and warn
      @$(call legal-warning-pkg-savednothing,$$($(2)_RAWNAME),local)
 else ifeq ($$($(2)_SITE_METHOD),override)

--

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Additionally, it would be nice to get some context. Why do you need this? What its the use case?

The proprietary packages are not in the current legal info, precisely because you wouldn't distribute them.
If you have a package that you distribute under a non open-source license, I think it makes more sense to provide a real name to the license.

Thomas,

Quoted 1 line · Thomas De Schampheleire

Additionally, it would be nice to get some context. Why do you need

Quoted 5 lines

What its the use case?

The proprietary packages are not in the current legal info, precisely because you wouldn't distribute them.
If you have a package that you distribute under a non open-source

Quoted 1 line

I think it makes more sense to provide a real name to the license.

There are things like firmware, or DSP blobs or other stuff that are just provided in binary form, but their license allows free redistribution. Should we mark those as PROPRIETARY, or should we have a different license name for those?

Basically, the context is the intel-microcode package, which bundles a binary-only firmware for some Intel hardware. Which license informations should we attach to it?

Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" <[email protected] <mailto:[email protected]>> het volgende:

Quoted 13 lines

Thomas,

Quoted 7 lines · Thomas De Schampheleire

Additionally, it would be nice to get some context. Why do you need this? What its the use case?

The proprietary packages are not in the current legal info, precisely because you wouldn't distribute them.
If you have a package that you distribute under a non open-source license, I think it makes more sense to provide a real name to the license.

Quoted 8 lines

There are things like firmware, or DSP blobs or other stuff that are just provided in binary form, but their license allows free redistribution. Should we mark those as PROPRIETARY, or should we have a different license name for those?

Basically, the context is the intel-microcode package, which bundles a binary-only firmware for some Intel hardware. Which license informations should we attach to it?

I think we need a specific category for those packages that are not intended for distribution. That is, when you generate the legal info, these packages are not included.

Next to that, I can understand that there is another category of 'packages' that may be proprietary, but are intended for redistribution. I think we should keep this separate.

Now, whether we use the name 'proprietary' for the first or second category is an open question.

I'm not familiar with the microcode example that you give. I assume that they have some kind of legal text associated with them? Can we really assume that two such proprietary packages from different vendors have the exact same redistribution conditions? My gut says no, in which case there'd be a separate term for each variant. In Gentoo Linux there it's such a mechanism. In order to install a given package, you have to agree to the specific license, e.g. an Adobe Flash one.

Quoted 29 lines · Thomas De Schampheleire

Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" <[email protected] <mailto:[email protected]>> het volgende:

Quoted 16 lines

Thomas,

Quoted 1 line · Thomas De Schampheleire

Additionally, it would be nice to get some context. Why do you

need this?

Quoted 3 lines

What its the use case?

The proprietary packages are not in the current legal info,

precisely

Quoted 2 lines

because you wouldn't distribute them.
If you have a package that you distribute under a non open-source

license,

Quoted 1 line

I think it makes more sense to provide a real name to the license.

Quoted 8 lines

There are things like firmware, or DSP blobs or other stuff that are just provided in binary form, but their license allows free redistribution. Should we mark those as PROPRIETARY, or should we have a different license name for those?

Basically, the context is the intel-microcode package, which bundles a binary-only firmware for some Intel hardware. Which license informations should we attach to it?

Quoted 7 lines

I think we need a specific category for those packages that are not intended for distribution. That is, when you
generate the legal info, these packages are not included.

Next to that, I can understand that there is another category of 'packages' that may be proprietary, but are intended for redistribution. I think we should keep this separate.

Agreed.

Quoted 2 lines

Now, whether we use the name 'proprietary' for the first or second category is an open question.

The word "proprietary" implies that it's not for redistribution. [1]
Something like 'Intel microcode license' would be appropriate however.

Two packages should only use the same license name if they have the same
terms of use and redistribution (although the exact wording or the exact conditions may be different, cfr. various BSD-3c versions or exceptions in
GPLv2 licenses).

If we want to make it explicit that this is not an open source
package, we
could make it 'Intel microcode license (non-free)'.

INTEL_MICROCODE_LICENSE = Intel microcode license
INTEL_MICROCODE_REDISTRIBUTE = NO

Of course this would make package files more verbose for non-redistributed packages, but they are a minor part so it is probably not a problem.

Quoted 51 lines · Arnout Vandecappelle

Quoted 31 lines · Thomas De Schampheleire

Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" <[email protected] <mailto:[email protected]>> het volgende:

Quoted 16 lines

Thomas,

Quoted 1 line · Thomas De Schampheleire

Additionally, it would be nice to get some context. Why do you need

this?

Quoted 5 lines

What its the use case?

The proprietary packages are not in the current legal info, precisely because you wouldn't distribute them.
If you have a package that you distribute under a non open-source

license,

Quoted 1 line

I think it makes more sense to provide a real name to the license.

Quoted 8 lines

There are things like firmware, or DSP blobs or other stuff that are just provided in binary form, but their license allows free redistribution. Should we mark those as PROPRIETARY, or should we have a different license name for those?

Basically, the context is the intel-microcode package, which bundles a binary-only firmware for some Intel hardware. Which license informations should we attach to it?

Quoted 7 lines

I think we need a specific category for those packages that are not intended for distribution. That is, when you
generate the legal info, these packages are not included.

Next to that, I can understand that there is another category of 'packages' that may be proprietary, but are intended for redistribution. I think we should keep this separate.

Agreed.

Quoted 2 lines

Now, whether we use the name 'proprietary' for the first or second category is an open question.

The word "proprietary" implies that it's not for redistribution. [1]
Something like 'Intel microcode license' would be appropriate however.

Quoted 8 lines

Two packages should only use the same license name if they have the same
terms of use and redistribution (although the exact wording or the exact conditions may be different, cfr. various BSD-3c versions or exceptions in GPLv2 licenses).

If we want to make it explicit that this is not an open source package,
we
could make it 'Intel microcode license (non-free)'.

The current legal-info implementation is based on the assumption that Buildroot
is used to build the root fs for an embedded device, for which packages can be
divided in two broad categories:
* open-source packages that are publicly available, whose source code can
or
must be redistributed;
* packages for which copying rights are reserved and the source is not available in the public; these packages are often developed by (or for)
the
device manufacturer and are kept proprietary as part of the device industrial secret.

All packages in the second category a marked as _LICENSE = PROPRIETARY, which
means a) that they're not freely licensed and b) that the tarball will not be
saved by Buildroot. This clearly prevents to specify in better detail the license of these packages.

This is a short path I took based on the above assumptions, but it is not correct is all cases.

intel-microcode is clearly not fitting any of the two categories: we want to describe its license, but we are not allowed to redistribute it freely, as the license text reported from Richard seems to signify.

A clean solution is probably to let the _LICENSE do its work, i.e. simply describe the license, and add a new _REDISTRUBUTE parameter (defaulting to YES), to specify if the tarball must be copied or not. Defining the license and choosing whether or not to redistribute would become technically independent, which is more correct.

Examples:

MYAPP_LICENSE = PROPRIETARY
would become
MYAPP_LICENSE = PROPRIETARY
MYAPP_REDISTRIBUTE = NO
or
MYAPP_LICENSE = Copyright (C) 2012 My Company # just an idea MYAPP_REDISTRIBUTE = NO

INTEL_MICROCODE_LICENSE = PROPRIETARY
would become
INTEL_MICROCODE_LICENSE = Intel microcode license INTEL_MICROCODE_REDISTRIBUTE = NO
Of course this would make package files more verbose for non-redistributed
packages, but they are a minor part so it is probably not a problem.

What do people think about such a solution?

Another solution would be to totally ignore the problem because it is affecting very few packages. But this would prevent Buildroot to provide intel-microcode in a "legally safe" way.

intel-microcode is clearly not fitting any of the two categories: we want to describe its license, but we are not allowed to redistribute it freely, as the license text reported from Richard seems to signify.

Quoted 3 lines · Luca Ceresoli

intel-microcode is clearly not fitting any of the two categories: we want to describe its license, but we are not allowed to redistribute it freely, as the license text reported from Richard seems to signify.

Actually, there is a license text embedded in the microcode file. It reads :

Redistribution. Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met:
.Redistributions must reproduce the above copyright notice and the following
disclaimer in the documentation and/or other materials provided with the distribution.
.Neither the name of Intel Corporation nor the names of its suppliers may be used
to endorse or promote products derived from this software without specific prior written permission.
.No reverse engineering, decompilation, or disassembly of this software is
permitted.
."Binary form" includes any format commonly used for electronic conveyance
which is a reversible, bit-exact translation of binary representation to ASCII or ISO text, for example, "uuencode."

"OEM LICENSE: You may reproduce and distribute the Software only as an integral part of or incorporated in Your product or as a standalone Software maintenance update for existing end users of Your products, excluding any other standalone products,

The disclaimer is a common 'this software is distributed "as is"' notice.

I'm not exactly sure what "redistribute it freely" means here, since I'm much more used to free licenses, but it seems to me that redistribution is actually allowed as buildroot isn't in any way violating any of these conditions, as long as this text appears in the list of licenses, which my patch takes care of.

Do you agree with that, and if yes, how would that change the rework proposal ?

This in confusing. In your previous e-mail dated Sep 20you quoted the "Intel Software License Agreement", that one is supposed to accept before downloading the package from the web page:

What hurts me a little is that, if intel-microcode turns out to be redistributable, we would have no use case in mainline Buildroot that makes use of such a feature to the legal-info code.

Signed-off-by Richard Braun <[email protected]>

---
 package/Config.in                          |    1 +
 package/intel-microcode/Config.in          |    7 +++++++
 package/intel-microcode/intel-microcode.mk |   24 ++++++++++++++++++++++++
 3 files changed, 32 insertions(+), 0 deletions(-)
 create mode 100644 package/intel-microcode/Config.in
 create mode 100644 package/intel-microcode/intel-microcode.mk

Signed-off-by Richard Braun <[email protected]>

---
 package/Config.in                          |    1 +
 package/intel-microcode/Config.in          |    7 +++++++
 package/intel-microcode/intel-microcode.mk |   24 ++++++++++++++++++++++++
 3 files changed, 32 insertions(+), 0 deletions(-)
 create mode 100644 package/intel-microcode/Config.in
 create mode 100644 package/intel-microcode/intel-microcode.mk

package/Config.in +1 -0

index 58dd5e8..e8a3f50 100644
@@ -212,6 +212,7 @@ source "package/hwdata/Config.in"
 source "package/i2c-tools/Config.in"
 source "package/input-event-daemon/Config.in"
 source "package/input-tools/Config.in"
+source "package/intel-microcode/Config.in"
 source "package/iostat/Config.in"
 source "package/irda-utils/Config.in"
 source "package/kbd/Config.in"

package/intel-microcode/Config.in new file +7 -0

new file mode 100644
index 0000000..495ebd7
@@ -0,0 +1,7 @@
+config BR2_PACKAGE_INTEL_MICROCODE
+       bool "intel-microcode"
+       depends on BR2_x86_64 || BR2_i386
+       help
+         This package provides an Intel microcode data file that can be
+         used to correct processor errors. The iucode-tool package and
+         proper kernel support are required to upload the microcode.

package/intel-microcode/intel-microcode.mk new file +0 -0

new file mode 100644
index 0000000..16323e2

package/intel-microcode/intel-microcode.mk new file +9 -1

+       head -n 33 $(@D)/microcode.dat > $(@D)/license.txt
+endef
+
+define INTEL_MICROCODE_INSTALL_TARGET_CMDS
+       $(INSTALL) -D -m 0644 $(@D)/microcode.dat \
+               $(TARGET_DIR)/usr/share/misc/intel-microcode.dat
+endef
+
+$(eval $(generic-package))
--

1.7.2.5