All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: yocto@yoctoproject.org, Martin Kelly <mkelly@xevo.com>
Subject: Re: Relicensing an Apache-licensed recipe as MIT
Date: Wed, 12 Apr 2017 21:54:23 +1200	[thread overview]
Message-ID: <1971160.7GEiT5quOD@peggleto-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <CAHiDW_FKOO2kGXxLs3NiB3yPmGh2OE1xec0Fdgnt2JuVmBvN_Q@mail.gmail.com>

On Wednesday, 12 April 2017 7:14:00 PM NZST Jussi Kukkonen wrote:
> On 11 April 2017 at 23:52, Martin Kelly <mkelly@xevo.com> wrote:
> > I'm thinking about integrating the open-vm-tools recipe from openswitch[1]
> > into openembedded (it massively improves the performance of VMWare guests)
> > but first I have a question about licensing. The openswitch repository is
> > Apache-licensed while the openembedded layers are all MIT licensed. I'm
> > not
> > a lawyer, but my understanding is that the Apache license is a superset of
> > the MIT license (it includes a patent clause that the MIT license lacks),
> > and therefore MIT code can be relicensed as Apache but not the other way
> > around.
> 
> The license of the layer refers to the licensing of the recipe files
> themselves: the source code licenses of the projects the recipes fetch and
> build are another thing. As long as the source code license is an open
> source one there should be no complaints about integrating into an
> openembedded layer.
> 
> To be completely clear: The LICENSE variable in a recipe refers to the
> source code license of the project to be built and should be set based on
> the licensing info found within the version of source code that we fetch
> and build. The recipe files are licensed according to the LICENSE and/or
> COPYING files of the layer it is in.
> 
> By the way, a quick search on layers.openembedded.org reveals this:
> http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/me
> ta-foss-openswitch/recipes-extended/open-vm-tools/open-vm-tools_10.0.5.bb
> (it seems to think the correct license is GPL).

This is muddying the waters somewhat - the LICENSE variable has nothing to do 
with this. We're only concerned with the license of the recipe itself.

My person opinion on the original question is that we shouldn't complicate 
matters by adding more than one license for metadata within the same layer if 
it's avoidable, so my suggestion would be to ask the original authors if they 
would be willing to relicense the single recipe you wish to copy as MIT.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


  reply	other threads:[~2017-04-12  9:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11 20:52 Relicensing an Apache-licensed recipe as MIT Martin Kelly
2017-04-12  7:14 ` Jussi Kukkonen
2017-04-12  9:54   ` Paul Eggleton [this message]
2017-04-12 10:50     ` Jussi Kukkonen
2017-04-12 16:43       ` Martin Kelly
2017-04-12 20:04         ` Martin Kelly

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=1971160.7GEiT5quOD@peggleto-mobl.ger.corp.intel.com \
    --to=paul.eggleton@linux.intel.com \
    --cc=mkelly@xevo.com \
    --cc=yocto@yoctoproject.org \
    /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.