Patchwork pkg-infra: produce legal info for proprietary packages

login
register
mail settings
Submitter Richard Braun
Date Sept. 28, 2012, 12:20 p.m.
Message ID <1348834801-2672-1-git-send-email-rbraun@sceen.net>
Download mbox | patch
Permalink /patch/187775/
State Rejected
Headers show

Comments

Richard Braun - Sept. 28, 2012, 12:20 p.m.
Signed-off-by: Richard Braun <rbraun@sceen.net>
---
 package/pkg-generic.mk |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)
Thomas Petazzoni - Sept. 28, 2012, 12:23 p.m.
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)
Thomas De Schampheleire - Sept. 28, 2012, 4:40 p.m.
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 Petazzoni - Sept. 28, 2012, 5:05 p.m.
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
Thomas De Schampheleire - Sept. 28, 2012, 6:52 p.m.
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
Arnout Vandecappelle - Sept. 30, 2012, 2:22 p.m.
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.
Luca Ceresoli - Oct. 2, 2012, 1:41 p.m.
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
Arnout Vandecappelle - Oct. 2, 2012, 2:35 p.m.
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>
Thomas De Schampheleire - Oct. 2, 2012, 5:50 p.m.
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
Richard Braun - Oct. 16, 2012, 3:42 p.m.
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 ?
Luca Ceresoli - Oct. 20, 2012, 8:51 p.m.
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
Richard Braun - Oct. 20, 2012, 9:55 p.m.
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.

Patch

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)