From: Stefano Babic <sbabic@denx.de>
To: dsterba@suse.cz, Stefano Babic <sbabic@denx.de>,
Omar Sandoval <osandov@osandov.com>,
linux-btrfs@vger.kernel.org, David Sterba <dsterba@suse.com>
Subject: Re: btrfs-progs license
Date: Thu, 14 Jan 2021 21:00:09 +0100 [thread overview]
Message-ID: <7e6b258f-c3b4-32e7-eac5-8ee1b2611364@denx.de> (raw)
In-Reply-To: <20210114184706.GD6430@twin.jikos.cz>
Hi David,
On 14.01.21 19:47, David Sterba wrote:
> On Thu, Dec 10, 2020 at 01:03:04PM +0100, Stefano Babic wrote:
>> I read this, thanks.
>>
>> I was quite confused about the license for libbtrfsutil due to both
>> "COPYING" and "COPYING.LESSER" in the library path. COPYING reports
>> GPLv3. But headers in file set LGPLv3, sure, and btrfs.h is GPLv2.
>>
>>
>>> I'd like to understand what's the problem with LGPLv3 before we'd
>>> consider switching to LGPLv2, which I'd rather not do.
>>>
>>
>> Please forgive me ig I am not correct because I am just a developer and
>> not a lawyer.
>>
>> The question rised already when QT switched from LGPv2 to LGPLv3, and
>> after the switch what companies should do to be license compliant. Based
>> on information given by qt.io and from lawyers (I find again at least
>> this link https://www.youtube.com/watch?v=lSYDWnsfWUk), it is possible
>> to link even close source SW to libraries, but to avoid the known
>> "tivoization", the manufacturer or user of a library must provide
>> instruction to replace the running code. This is an issue for embedded
>> devices, specially in case the device is closed with keys by the
>> manufacturer to avoid attacks or replacement with malware - for example,
>> medical devices. This means that such a keys to be licence compliant
>> (anyone please correct me if I am wrong) must be provided, making the
>> keys itself without sense. The issue does not happen with LGPv2.1, and
>> this is the reason why many manufacturers are strictly checking to not
>> have (L)GPLv3 code on their device.
>
> I haven't forgotten about this, but haven't researched that enough to
> make the decision.
;-)
> I need to do the 5.10 release and that will be
> without change to the license.
Of course.
> There are no new changes to libbtrfsutil
> so the number of people who'd need to agree with the potential
> relicensing remains the same.
>
That's fine.
In my understanding, current licensing for btrf-progs could be
problematic. It is declared GPLv2 but it links libbtrfutils, and GPLv2
is not compatible according to FSF to (L)GPLv3. If libbtrfsutil becomes
LGPLv2.1, all conflicts are resolved ;-).
Best regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================
next prev parent reply other threads:[~2021-01-14 20:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-08 9:49 btrfs-progs license Stefano Babic
2020-12-08 10:32 ` ronnie sahlberg
2020-12-08 10:41 ` Stefano Babic
2020-12-08 12:37 ` Neal Gompa
2020-12-08 13:25 ` Stefano Babic
2020-12-08 21:00 ` Omar Sandoval
2020-12-10 11:27 ` David Sterba
2020-12-10 12:03 ` Stefano Babic
2021-01-14 18:47 ` David Sterba
2021-01-14 20:00 ` Stefano Babic [this message]
2021-01-14 19:38 ` Neal Gompa
2021-01-14 20:16 ` Stefano Babic
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=7e6b258f-c3b4-32e7-eac5-8ee1b2611364@denx.de \
--to=sbabic@denx.de \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=osandov@osandov.com \
/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;
as well as URLs for NNTP newsgroup(s).