From: Peter Korsgaard <jacmet@uclibc.org>
To: buildroot@busybox.net
Subject: [Buildroot] Report from the Buildroot Developer Day
Date: Mon, 07 Nov 2011 17:17:00 +0100 [thread overview]
Message-ID: <87d3d3ewlf.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <4EB3D2F1.3010206@comelit.it> (Luca Ceresoli's message of "Fri, 04 Nov 2011 12:56:33 +0100")
>>>>> "Luca" == Luca Ceresoli <luca.ceresoli@comelit.it> writes:
Hi,
>> It is also not clear yet what the output of this report should be. On
>> one side, Thomas Petazzoni proposed that it generates an HTML document
>> inside a directory with all the tarballs and all the patches for the
>> different components. On the other side, Peter Korsgaard proposed that
>> a report be generated, but only with a list of tarballs, leaving the
>> user the work of putting the tarballs together. For Peter, there is no
Luca> I can't see any drawback of having Buildroot put together the
Luca> tarballs. It's boring for a man, and I suppose it would be easy
Luca> to implement in Buildroot.
My point was simply that the easiest / safest-from-a-legal-pov would
just be for people to provide their entire buildroot tree rather than
trying to pick out individual patches.
Luca> I think this would be illegal, at least according to the GPLv2:
Luca> "For an executable work, complete source code means all the source
Luca> code for all modules it contains, plus any associated interface
Luca> definition files, plus the scripts used to control compilation and
Luca> installation of the executable."
Luca> My understanding is that Buildroot is exactly "the scripts used to
Luca> control compilation and installation", so the patches that exist in
Luca> Buildroot should be released as well.
That's how I read it as well (but IANAL) and how I handle it at work -
E.G. supply buildroot together with the other upstream tarballs.
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2011-11-07 16:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-02 15:03 [Buildroot] Report from the Buildroot Developer Day Thomas Petazzoni
2011-11-02 20:15 ` Peter Korsgaard
2011-11-04 11:56 ` Luca Ceresoli
2011-11-04 12:30 ` Michael S. Zick
2011-11-07 16:17 ` Peter Korsgaard [this message]
2011-11-07 9:58 ` Thomas De Schampheleire
2011-11-07 12:09 ` Sam Ravnborg
2011-11-07 12:25 ` Thomas Petazzoni
2011-11-07 12:39 ` Yann E. MORIN
2011-11-08 13:20 ` Thomas De Schampheleire
2011-11-07 12:39 ` Thomas Petazzoni
2011-11-07 19:01 ` Yann E. MORIN
2011-11-08 8:19 ` Thomas De Schampheleire
2011-11-15 22:17 ` Arnout Vandecappelle
2011-11-15 23:28 ` Michael S. Zick
2011-11-17 13:57 ` Thomas De Schampheleire
2011-11-17 21:21 ` Bjørn Forsman
2011-11-18 6:39 ` Thomas De Schampheleire
2011-11-18 11:04 ` Bjørn Forsman
2011-11-18 11:36 ` Thomas De Schampheleire
2011-11-18 17:51 ` Arnout Vandecappelle
2011-11-18 22:53 ` Peter Korsgaard
2011-11-18 23:16 ` Arnout Vandecappelle
2011-11-19 8:24 ` Peter Korsgaard
2011-11-20 8:36 ` Thomas Petazzoni
2011-11-20 9:58 ` Peter Korsgaard
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=87d3d3ewlf.fsf@macbook.be.48ers.dk \
--to=jacmet@uclibc.org \
--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.