Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages
Date: Tue, 02 Oct 2012 15:41:38 +0200	[thread overview]
Message-ID: <506AEF12.5080906@lucaceresoli.net> (raw)
In-Reply-To: <5068558E.4070005@mind.be>

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

  reply	other threads:[~2012-10-02 13:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-20 15:12 [Buildroot] [PATCH] intel-microcode: new package Richard Braun
2012-09-20 20:36 ` Thomas Petazzoni
2012-09-20 21:12   ` Richard Braun
2012-09-21  8:35     ` Thomas Petazzoni
2012-09-22  9:42       ` Richard Braun
2012-09-28 12:17         ` Richard Braun
2012-09-28 12:20           ` [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages Richard Braun
2012-09-28 12:23             ` Thomas Petazzoni
2012-09-28 16:40               ` Thomas De Schampheleire
2012-09-28 17:05                 ` Thomas Petazzoni
2012-09-28 18:52                   ` Thomas De Schampheleire
2012-09-30 14:22                     ` Arnout Vandecappelle
2012-10-02 13:41                       ` Luca Ceresoli [this message]
2012-10-02 14:35                         ` Arnout Vandecappelle
2012-10-02 17:50                         ` Thomas De Schampheleire
2012-10-16 15:42                         ` Richard Braun
2012-10-20 20:51                           ` Luca Ceresoli
2012-10-20 21:55                             ` Richard Braun
2012-09-28 12:20           ` [Buildroot] [PATCH] intel-microcode: new package Richard Braun
2012-09-28 12:24             ` Thomas Petazzoni
2012-09-29  9:31             ` Thomas De Schampheleire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=506AEF12.5080906@lucaceresoli.net \
    --to=luca@lucaceresoli.net \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox