On Tue, Feb 04, 2020 at 03:39:14PM +0530, Kaleb Keithley wrote:
On Mon, Feb 3, 2020 at 11:35 PM Daniel P. Berrangé
<berrange(a)redhat.com>
wrote:
> On Mon, Feb 03, 2020 at 11:26:46PM +0530, Kaleb Keithley wrote:
> > Coming in Ceph-15 (octopus)
> >
> > From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause
> > and MIT
> > To: LGPL-2.1 and LGPL-3.0 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0
> and
> > BSD-3-Clause and MIT
>
> Do you have info on which parts of Ceph are covered by the newly
> introduced LGPLv3.0 ?
>
>
I'm still waiting for a reply to the email I sent Sage. In the meantime I
did a cursory inspection of the source and don't see anything new that is
licensed with LGPL 3.0. (I'm not a lawyer and I did not do an exhaustive
search.)
What I do see that is new is the top-level license file (i.e. COPYING file)
has been changed to add "... or LGPL-3..."
Again, I'm not a lawyer, but AFAIK that magic word "or" in the phrase
"LGPL-2.1 or LGPL-3" should make it acceptable for things like QEMU that
are GPLv2.0 only.
Thanks for the pointer. I've looked at the commit which made this change
and I'm increasingly concerned that it *will* in fact impact apps like
QEMU which are GPLv2.0 only. Here is the full text:
commit 2f361a6eeebaa0aa2cb79495f108a89a862ef8bd
Author: Sage Weil <sweil(a)redhat.com>
Date: Wed Jun 6 16:32:53 2018 -0500
relicense LGPL-2.1 code as LGPL-2.1 or LGPL-3.0
The primary motivation to relicense is a desire to integrate with projects
that are licensed under the Apache License version 2.0. Although opinions
vary, there are some who argue the the LGPL-2.1 and Apache-2.0 licenses
are not fully compatible. We would like to avoid the ambiguity and
potential for controversy.
Projects we would like to consume that are Apache-2.0 licensed include
Seastar, OpenSSL (which is in the process of relicensing to Apache-2.0),
and Swagger (swagger.io). Note that some of these are dynamically linked
or consumed via a high-level language and may or may not require a change
to LGPL-3.0, but providing the option for LGPL-3.0 certainly avoids any
uncertainty.
A few other source files are already incorporated into Ceph that claim an
Apache-2.0 license:
src/common/deleter.h
src/common/sstring.h
src/include/cpp-btree
The Ceph developers would further like to provide a license option that is
more modern than the current LGPL-2.1. LGPL-3.0 includes updated,
clarified language around several issues and is widely considered
more modern, superior license.
Signed-off-by: Sage Weil <sage(a)redhat.com>
So in summary
- The historical Ceph license is primarily LGPLv2.1-only
- This prevents Ceph from using & linking to Apache 2.0 licensed code
- Changing "LGPLv2.1-only or LGPL-3.0-only" makes Ceph *source*
compatible with Apache 2.0
That's not the end of the story for license compatibiltiy though. The
problem here is the effect on the *combined* work, and ripples to apps
using libraries.
Although the source is dual licensed LGPLv2.1-only or LGPL-3.0-only,
the presence of Apace 2.0 code eliminates the possibility to choose
LGPLv2.1-only for the combined work. The only option left for the
combined work is thus to choose LGPL-3.0-only.
If this only affects Ceph binaries, that change is self-contained at
least, so not a big problem.
If this use of Apache 2.0 code extends to the Ceph *libraries* then this
license change ripples out to affect applications linking to Ceph.
This will make Ceph incompatible with QEMU as QEMU is GPLv2-only as a
combined work.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|