| Message ID | 1348834801-2672-1-git-send-email-rbraun@sceen.net |
|---|---|
| State | Rejected |
| Headers | show |
Dear Richard Braun, This will need a review and ACK from Luca, Cc'ing him. Thomas On Fri, 28 Sep 2012 14:20:01 +0200, Richard Braun wrote: > > Signed-off-by: Richard Braun <rbraun@sceen.net> > --- > package/pkg-generic.mk | 6 +----- > 1 files changed, 1 insertions(+), 5 deletions(-) > > diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk > index ffe7dfb..1bfaed2 100644 > --- a/package/pkg-generic.mk > +++ b/package/pkg-generic.mk > @@ -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)
Op 28 sep. 2012 14:23 schreef "Thomas Petazzoni" < thomas.petazzoni@free-electrons.com> het volgende: > > Dear Richard Braun, > > This will need a review and ACK from Luca, Cc'ing him. 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. Best regards, Thomas > > On Fri, 28 Sep 2012 14:20:01 +0200, Richard Braun wrote: > > > > Signed-off-by: Richard Braun <rbraun@sceen.net> > > --- > > package/pkg-generic.mk | 6 +----- > > 1 files changed, 1 insertions(+), 5 deletions(-) > > > > diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk > > index ffe7dfb..1bfaed2 100644 > > --- a/package/pkg-generic.mk > > +++ b/package/pkg-generic.mk > > @@ -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) > > > > -- > Thomas Petazzoni, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Thomas, On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: > 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. 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? Best regards, Thomas
Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" < thomas.petazzoni@free-electrons.com> het volgende: > > Thomas, > > On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: > > > 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. > > 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. Best regards, Thomas
On 28/09/12 20:52, Thomas De Schampheleire wrote: > > Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com > <mailto:thomas.petazzoni@free-electrons.com>> het volgende: >> >> Thomas, >> >> On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: >> >> > 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. >> >> 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. Agreed. > 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)'. Regards, Arnout [1] http://en.wiktionary.org/wiki/proprietary > 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.
Arnout Vandecappelle wrote: > On 28/09/12 20:52, Thomas De Schampheleire wrote: >> >> Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" >> <thomas.petazzoni@free-electrons.com >> <mailto:thomas.petazzoni@free-electrons.com>> het volgende: >>> >>> Thomas, >>> >>> On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: >>> >>> > 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. >>> >>> 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. > > Agreed. > >> 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)'. 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. Luca
On 02/10/12 15:41, Luca Ceresoli wrote: > 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. I would say this is even desirable, so Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Hi Luca, all, On Tue, Oct 2, 2012 at 3:41 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote: > Arnout Vandecappelle wrote: >> >> On 28/09/12 20:52, Thomas De Schampheleire wrote: >>> >>> >>> Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" >>> <thomas.petazzoni@free-electrons.com >>> <mailto:thomas.petazzoni@free-electrons.com>> het volgende: >>>> >>>> >>>> Thomas, >>>> >>>> On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: >>>> >>>> > 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. >>>> >>>> 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. >> >> >> Agreed. >> >>> 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)'. > > > 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? I think it is a clean and suitable solution for this problem. > > 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. > Best regards, Thomas
On Tue, Oct 02, 2012 at 03:41:38PM +0200, Luca Ceresoli wrote: > 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." 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 ?
Richard Braun wrote: > On Tue, Oct 02, 2012 at 03:41:38PM +0200, Luca Ceresoli wrote: >> 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." 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: > "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, (http://downloadcenter.intel.com/confirm.aspx?httpDown=http://downloadmirror.intel.com/21385/eng/microcode-20120606.tgz&lang=eng&Dwnldid=21385&keyword=microcode) This means we cannot redistribute the code, except as part of a product. OTOH in the downloaded file, that one may simply download at http://downloadmirror.intel.com/21385/eng/microcode-20120606.tgz without accepting any agreement, contains the (different) license that you're quoting right now, which would permit redistribution. I used to think big companies can afford good lawyers, but this does not seem to be happening at Intel. > 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 ? I agree with your interpretation of the license in the .dat file, although this does not clarify whether the applicable text is the Agreement on the web page or this one license. In both cases I don't think my proposal needs to be changed. The principle is still true: one package may be redistributable or not. If it is not, one may still want to describe its license in the _LICENSE variable with a more descriptive text than "PROPRIETARY". 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. But I would go on and implement it anyway, since it could be useful to other Buildroot users and not hurt the other ones. Luca
On Sat, Oct 20, 2012 at 10:51:00PM +0200, Luca Ceresoli wrote: > 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: Confusing indeed. > 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. That's what troubles me as well. I don't want to introduce dead code. But if you do it as you seem to have planned, then I won't worry about it and just wait for the feature. I'll try to get some clarification from Intel in the meanwhile. Thanks for your answer.
diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk index ffe7dfb..1bfaed2 100644 --- a/package/pkg-generic.mk +++ b/package/pkg-generic.mk @@ -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)
Signed-off-by: Richard Braun <rbraun@sceen.net> --- package/pkg-generic.mk | 6 +----- 1 files changed, 1 insertions(+), 5 deletions(-)