From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] Some legal-info observations/problems
Date: Wed, 09 Oct 2013 15:14:54 +0200 [thread overview]
Message-ID: <525556CE.3000308@lucaceresoli.net> (raw)
In-Reply-To: <CAAXf6LVxoXMaBFVzc6Hd46ST8AwDOyd8PdRfJ04WKfF9po_K9w@mail.gmail.com>
Hi Thomas,
I ack all of your report. Just a few notes below.
Thomas De Schampheleire wrote:
> Luca, all,
>
> Let's try to summarize/conclude on these items...
>
...
>> 4. Suppose that a package has no license files and explicitly declares
>> this with FOO_LICENSE_FILES =
>> In this case, you will still get a warning: "cannot save license
>> (FOO_LICENSE_FILES not defined)", but in fact it is simply empty.
>> I think it would be better to distinghuish the situation 'empty' and
>> 'not defined'.
>
> Reading the various comments I have the impression there is a
> consensus to define a magic value for FOO_LICENSE_FILES, correct. The
> question is: which value(s). If we want to differentiate between:
> a. there is a license, it has a license text, but the text is not
> provided with the sources, and
> b. there is a license but there doesn't exist any license text,
> then we need two magic values.
>
> There were a few suggestions:
> N/A, none, NONE (ThomasP), which would cover (b)
> missing (rejected by ThomasP), not-provided, none-provided (ThomasDS),
> which would cover (a)
(a) is for cases when we are unable to extract the text, so what about
"not-extracted"?
>
>
> In case of (a), I'm not sure if a warning is needed. It could for
> example be that the license is 'public domain' which doesn't need a
> license text.
> For (b) I think a warning is a good idea.
>
>
>
> Related to this is the question of a license URL. I personally think
> it is not legally safe to only refer to a URL from a package, because
> who knows someone changes the license text on the URL. They could just
> alter the license of existing sources.
> So although the feature of automatically downloading a license text
> from its URL looks nice, I (not a lawyer) would not recommend
> implementing it. I follow ThomasP's reasoning of requesting upstream
> to add the effective license text to the sources, and in the meantime
> using the magic value decided above for case (b).
I agree with you. Regarding the legal stuff we should stay on the safe
side. But Arnout and Simon expressed an opposite opinion on another
branch of this thread...
--
Luca
next prev parent reply other threads:[~2013-10-09 13:14 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-02 14:06 [Buildroot] Some legal-info observations/problems Thomas De Schampheleire
2013-10-02 14:22 ` Peter Korsgaard
2013-10-02 14:32 ` Thomas De Schampheleire
2013-10-02 15:23 ` Thomas Petazzoni
2013-10-02 16:33 ` Luca Ceresoli
2013-10-03 8:24 ` Thomas De Schampheleire
2013-10-03 16:40 ` Arnout Vandecappelle
2013-10-04 8:54 ` Thomas De Schampheleire
2013-10-04 9:07 ` Thomas Petazzoni
2013-10-04 15:30 ` Ryan Barnett
2013-10-04 15:34 ` Thomas Petazzoni
2013-10-04 15:39 ` Ryan Barnett
2013-10-04 15:46 ` Simon Dawson
2013-10-07 22:43 ` Arnout Vandecappelle
2013-10-09 7:23 ` Simon Dawson
2013-10-09 7:29 ` Thomas Petazzoni
2013-10-09 7:31 ` Simon Dawson
2013-10-05 21:07 ` Luca Ceresoli
2013-10-02 16:31 ` Arnout Vandecappelle
2013-10-03 8:30 ` Thomas De Schampheleire
2013-10-02 18:49 ` Ryan Barnett
2013-10-03 8:34 ` Thomas De Schampheleire
2013-10-03 13:31 ` Ryan Barnett
2013-10-03 13:42 ` Danomi Manchego
2013-10-03 14:12 ` Ryan Barnett
2013-10-03 16:50 ` Arnout Vandecappelle
2013-10-03 21:38 ` Peter Korsgaard
2013-10-03 22:44 ` Ryan Barnett
2013-10-07 8:19 ` Thomas De Schampheleire
2013-10-09 13:14 ` Luca Ceresoli [this message]
2013-10-09 16:46 ` Arnout Vandecappelle
2013-10-11 14:13 ` Thomas De Schampheleire
2013-10-09 19:54 ` Ryan Barnett
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=525556CE.3000308@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.