All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 6/6] package/mtools: new host-package
Date: Tue, 12 Mar 2013 18:16:32 +0100	[thread overview]
Message-ID: <513F62F0.6050303@lucaceresoli.net> (raw)
In-Reply-To: <201303110102.06732.yann.morin.1998@free.fr>

Yann E. MORIN wrote:
 > Thomas, Luca, All,
 >
 > On Sunday 10 March 2013 Thomas Petazzoni wrote:
 >> On Thu,  7 Mar 2013 22:55:31 +0100, Yann E. MORIN wrote:
 >>
 >>> +MTOOLS_VERSION  = 4.0.18
 >>> +MTOOLS_SOURCE   = mtools-$(MTOOLS_VERSION).tar.bz2
 >>> +MTOOLS_SITE     = $(BR2_GNU_MIRROR)/mtools/
 >>
 >> MTOOLS_LICENSE = GPLv3+
 >> MTOOLS_LICENSE_FILES = COPYING
 >
 > Done.
 >
 >> However, this makes me realize that we don't distinguish host packages
 >> from target packages in the manifest.csv file. For example, once I had
 >> the licensing informations for this mtools file, I have the following
 >> line in my manifest.csv:
 >>
 >> "mtools","4.0.18","GPLv3+","COPYING","mtools-4.0.18.tar.bz2"
 >>
 >> And then, someone might think "damn, I have some GPLv3 software in my
 >> system, I now need to comply with the additional special requirements
 >> of GPLv3", while in fact it's not the case (as far as I know) because
 >> mtools is not distributed on the embedded device. Maybe we need to
 >> explicit which packages are on the target, which packages are on the
 >> host, and which packages are on both, no?
 >
 > Yes, fully agreed; this would be very puzzling.
 >
 > I would suggest that we not install licensing information about host
 > packages, unless they are also used on the target.

It would probably be sound in most cases, but not compliant to some
licenses, at least if there isa GPL package on the target.
Take what the GPLv2 saysin clause 3:

 > The source code for a work means the preferred form of the work for
 > making modifications to it.  For an executable work, complete source
 > code means all the source code for all modules it contains, plus any
 > associated interface definition files, plus the scripts used to
 > control compilation and installation of the executable.

What do the "scripts used to control compilation and installation"?
We use a toolchain, the autotools, CMake, Python etc on the host to build
packages. While these tools are arguably more complex than the average
"script", they are "used to control the cpmpilation and installation".

Reading on:

 >   However, as a
 > special exception, the source code distributed need not include
 > anything that is normally distributed (in either source or binary
 > form) with the major components (compiler, kernel, and so on) of the
 > operating system on which the executable runs, unless that component
 > itself accompanies the executable.

While this is saying you do not need to redistribute the Debian compiler,
it is using "compiler" and "kernel" as two examples of the "scripts used
to control compilation and installation". Hence my understanding that the
toolchain should be redistributed, along with all of the host tools that
are used to build anything on the target.

As far as the mtools are concerned, they are probably not used to produce
the executables on the target, so they actually do not need to be in the
redistribution list. But most other host packages are different.

Indeed, in the practice I'm retty sure almost nobody modify autotools,
or CMake or other host packages, so even redistributing them would not
disclose much industrial secret.

Bottom line, I think it would be useful to save in the package manifest
an additional column stating whether the package is on the target, on
the host, or both. But skipping host-only packages is not safe.

Luca

  parent reply	other threads:[~2013-03-12 17:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-07 21:55 [Buildroot] [pull request v4] Pull request for branch yem-host-image-tools Yann E. MORIN
2013-03-07 21:55 ` [Buildroot] [PATCH 1/6] package/e2fsprogs: add host-package selection Yann E. MORIN
2013-03-07 21:55 ` [Buildroot] [PATCH 2/6] package/dosfstools: " Yann E. MORIN
2013-03-07 21:55 ` [Buildroot] [PATCH 3/6] package/libconfuse: add host variant Yann E. MORIN
2013-03-07 21:55 ` [Buildroot] [PATCH 4/6] package/genimage: new host-only package Yann E. MORIN
2013-03-10 11:41   ` Thomas Petazzoni
2013-03-10 23:39     ` Yann E. MORIN
2013-03-11 21:30       ` Thomas Petazzoni
2013-03-07 21:55 ` [Buildroot] [PATCH 5/6] package/genpart: " Yann E. MORIN
2013-03-10 11:44   ` Thomas Petazzoni
2013-03-10 23:50     ` Yann E. MORIN
2013-03-07 21:55 ` [Buildroot] [PATCH 6/6] package/mtools: new host-package Yann E. MORIN
2013-03-10 11:49   ` Thomas Petazzoni
2013-03-11  0:02     ` Yann E. MORIN
2013-03-11 21:30       ` Thomas Petazzoni
2013-03-12 17:16       ` Luca Ceresoli [this message]
2013-03-12 17:40         ` Thomas De Schampheleire
2013-03-12 23:24           ` Arnout Vandecappelle
2013-03-15 11:48             ` Thomas Petazzoni
2013-03-10 11:40 ` [Buildroot] [pull request v4] Pull request for branch yem-host-image-tools Thomas Petazzoni
  -- strict thread matches above, loose matches on Subject: below --
2013-03-17 18:19 [Buildroot] [pull request v5] " Yann E. MORIN
2013-03-17 18:19 ` [Buildroot] [PATCH 6/6] package/mtools: new host-package Yann E. MORIN
2013-03-18 22:14   ` Peter Korsgaard
2013-02-17 23:04 [Buildroot] [pull request v3 'next'] Pull request for branch yem-host-image-tools Yann E. MORIN
2013-02-17 23:04 ` [Buildroot] [PATCH 6/6] package/mtools: new host-package Yann E. MORIN
2013-02-08 21:56 [Buildroot] [pull request v2] Pull request for branch yem-host-image-tools Yann E. MORIN
2013-02-08 21:56 ` [Buildroot] [PATCH 6/6] package/mtools: new host-package Yann E. MORIN
2013-02-08 17:32 [Buildroot] [pull request] Pull request for branch yem-host-image-tools Yann E. MORIN
2013-02-08 17:33 ` [Buildroot] [PATCH 6/6] package/mtools: new host-package Yann E. MORIN
2013-02-08 17:44   ` Thomas Petazzoni

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=513F62F0.6050303@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.