All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 4/5] docs/manual: add section about patch licensing
Date: Fri, 26 Feb 2016 23:28:33 +0100	[thread overview]
Message-ID: <20160226222833.GA3437@free.fr> (raw)
In-Reply-To: <56D0CCDB.9020302@lucaceresoli.net>

Luca, All,

On 2016-02-26 23:08 +0100, Luca Ceresoli spake thusly:
> On 04/02/2016 00:34, Yann E. MORIN wrote:
[...]
> > So, we still have the problem of patches that are applied to packages
> > that can be had under a non-public license, like e.g. Qt, polarssl...
> > for which there exists a proprietary alternative?
> > 
> > In my opinion, the patches we carry are only available under the FLOSS
> > license we can get them:
> > 
> >   - if we cherry-picked them from upstream, then the only license we
> >     ever had for those patches is the FLOSS license, not the proprietary
> >     one; so they can't be applied to the proprietary version of the
> >     package (but a licensee may get those patches from the licensor, and
> >     replace our patches with the ones it got from the licensor);
> > 
> >   - if we wrote them, the only solution we have is to make them public
> >     domain, or they could not be applied either (we don't know the
> >     licensing terms for that proprietary version, so we can't license
> >     them under those terms);
> 
> Why can't we license these patches under the FLOSS license they are
> publicly available under?

Ah, my bad, I was not clear.

What I meant with that second point wa that, *if* we wanted to make
those patches available for the non-FLOSS license, then we'd have had to
license them in a very liberal way, and the only real possibility would
have been public domain, as any other license, hoever permissive it may
be, could clash with the proprietary license.

Now, I am absolutely *not* advocating for that.

In fact, I've always been, and will always be, advocating for the
patches to be made available under the _publicly available_ FLOSS
license of the package they are applied to, which is the conclusion we
came to, and which we wrote in COPYING (and soon in the manual).

> Of course this implies "they can't be applied
> to the proprietary version of the package", just like you state in the
> first case. This is a limitation, but I think it is legal. Don't you
> think so?

 1- I think it is perfectly legit, yes.
 2- I do not see that as a limitation, no.
 3- I am 100% fine with that! ;-)

> >   - if we got them from somewhere else (e.g. openwrt, gentoo,
> >     alpine...), then we'd have to get the licensing terms from those
> >     providers, and I guess most of them either don't know (most
> >     probable) or would only provide them under the usual FLOSS license
> >     of that package (not knowing better than us in points 1 and 2 above).
> > 
> > So, this situation is really complex, and we can't deal with that in
> > such a simple way.
> > 
> >> They are not distributed under the Buildroot license.
> > 
> > Well, what of a patch to a GPLv2 package? It is the same license as
> > Buidlroot's license... What I mean, is that some patches might be
> > covered by the same licensing terms, but that it's not because of
> > Buildroot, but because of the package they are applied to. I'd like we
> > make that clearer...
> 
> Aaaah, yes, you're right... Well, I guess we all got what I meant, but
> indeed I wrote something ambiguous. :(

Yes, I did get your meaning, of course! ;-)

But legalese stuff is suffficiently complex that we have to be as clear
as possible when we write such stuff. In the end, I think we pretty much
covered all the bases with that blurb we've added now, no?

Thank you for working on this topic! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2016-02-26 22:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 22:19 [Buildroot] [PATCH v2 0/5] Patch file clarification & Co Luca Ceresoli
2016-02-01 22:19 ` [Buildroot] [PATCH v2 1/5] Update copyright year Luca Ceresoli
2016-02-01 22:24   ` Luca Ceresoli
2016-02-01 22:19 ` [Buildroot] [PATCH v2 2/5] docs/manual: slightly clarify patch licensing Luca Ceresoli
2016-02-02  8:58   ` Yann E. MORIN
2016-02-03 22:53   ` Yann E. MORIN
2016-02-10 22:15   ` Arnout Vandecappelle
2016-02-25 10:50   ` Peter Korsgaard
2016-02-01 22:19 ` [Buildroot] [PATCH v2 3/5] COPYING: add exception about " Luca Ceresoli
2016-02-01 22:31   ` Thomas Petazzoni
2016-02-03 23:02   ` Yann E. MORIN
2016-02-03 23:57     ` Arnout Vandecappelle
2016-02-04 20:42       ` Yann E. MORIN
2016-02-04 21:08         ` Thomas Petazzoni
2016-02-04 21:40           ` Yann E. MORIN
2016-02-04 21:51             ` Thomas Petazzoni
2016-02-04 22:28               ` Steve Calfee
2016-02-05  9:25         ` Luca Ceresoli
2016-02-05 12:07           ` Peter Korsgaard
2016-02-10 22:35     ` Arnout Vandecappelle
2016-02-19 17:28       ` Luca Ceresoli
2016-02-25 10:57         ` Peter Korsgaard
2016-02-25 11:53           ` Luca Ceresoli
2016-02-01 22:19 ` [Buildroot] [PATCH v2 4/5] docs/manual: add section " Luca Ceresoli
2016-02-03 23:34   ` Yann E. MORIN
2016-02-26 22:08     ` Luca Ceresoli
2016-02-26 22:28       ` Yann E. MORIN [this message]
2016-02-10 22:37   ` Arnout Vandecappelle
2016-02-01 22:19 ` [Buildroot] [PATCH v2 5/5] legal-info: explicitly state how patches are licensed Luca Ceresoli
2016-03-06 15:14   ` Thomas Petazzoni
2016-03-06 22:52     ` Luca Ceresoli
2016-03-06 22:56       ` Yann E. MORIN

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=20160226222833.GA3437@free.fr \
    --to=yann.morin.1998@free.fr \
    --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.