Re: btrfs-progs license

[Stefano Babic <sbabic@denx.de>]

Hi David,

On 10.12.20 12:27, David Sterba wrote:
> On Tue, Dec 08, 2020 at 01:00:01PM -0800, Omar Sandoval wrote:
>> On Tue, Dec 08, 2020 at 10:49:10AM +0100, Stefano Babic wrote:
>>> Hi,
>>>
>>> I hope I am not OT. I ask about license for btrfs-progs and related
>>> libraries. I would like to use libbtrfsutils in a FOSS project, but this
>>> is licensed under GPLv3 (even not LGPL) and it forbids to use it in
>>> projects where secure boot is used.
>>
>> libbtrfsutil is LGPLv3, where did you get the idea that it is GPLv3?
>>
>>> Checking code in btrfs-progs, btrfs is licensed under GPv2 (fine !) and
>>> also libbtrfs. But I read also that libbtrfs is thought to be dropped
>>> from the project. And checking btrfs, this is linked against
>>> libbtrfsutils, making the whole project GPLv3 (and again, not suitable
>>> for many industrial applications in embedded systems).
>>>
>>> Does anybody explain me the conflict in license and if there is a path
>>> for a GPLv2 compliant library ?
>>
>> No objections from me to make it LGPLv2 instead, I suppose. Dave,
>> thoughts?
> 
> I've replied in https://github.com/kdave/btrfs-progs/issues/323, the
> initial question regarding GPL v3 does not seem to be relevatnt as
> there's no such code.
> 

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.

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
=====================================================================