Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox