* btrfs-progs license @ 2020-12-08 9:49 Stefano Babic 2020-12-08 10:32 ` ronnie sahlberg ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Stefano Babic @ 2020-12-08 9:49 UTC (permalink / raw) To: linux-btrfs; +Cc: stefano babic 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. 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 ? Best regards, Stefano Babic -- ===================================================================== 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 ===================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 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 21:00 ` Omar Sandoval 2 siblings, 1 reply; 12+ messages in thread From: ronnie sahlberg @ 2020-12-08 10:32 UTC (permalink / raw) To: Stefano Babic; +Cc: Btrfs BTRFS On Tue, Dec 8, 2020 at 7:53 PM Stefano Babic <sbabic@denx.de> 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. > > 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 ? > There are always paths when licences conflict. One path I have used successfully in other projectss is just to write a replacement from scratch picking a licence I am more comfortable with. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2020-12-08 10:32 ` ronnie sahlberg @ 2020-12-08 10:41 ` Stefano Babic 0 siblings, 0 replies; 12+ messages in thread From: Stefano Babic @ 2020-12-08 10:41 UTC (permalink / raw) To: ronnie sahlberg, Stefano Babic; +Cc: Btrfs BTRFS Hi Ronnie, On 08.12.20 11:32, ronnie sahlberg wrote: > On Tue, Dec 8, 2020 at 7:53 PM Stefano Babic <sbabic@denx.de> 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. >> >> 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 ? >> > > There are always paths when licences conflict. > One path I have used successfully in other projectss is just to write > a replacement from scratch > picking a licence I am more comfortable with. > Yes, I come to the same conclusion - but before doing this, I just check if there is an option to reuse existing code. Anyway, btrfs-progs license already conflicts due to libbtrfutil and it should be set to GPLv3, and in my understanding even the utility "btrfs" should be avoided on many embedded systems if GPLv3 is not allowed (it is still marked as GPLv2 in Openembedded). Am I right (no lawyer here !) ? 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 ===================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2020-12-08 9:49 btrfs-progs license Stefano Babic 2020-12-08 10:32 ` ronnie sahlberg @ 2020-12-08 12:37 ` Neal Gompa 2020-12-08 13:25 ` Stefano Babic 2020-12-08 21:00 ` Omar Sandoval 2 siblings, 1 reply; 12+ messages in thread From: Neal Gompa @ 2020-12-08 12:37 UTC (permalink / raw) To: Stefano Babic; +Cc: Btrfs BTRFS, Omar Sandoval, David Sterba On Tue, Dec 8, 2020 at 4:52 AM Stefano Babic <sbabic@denx.de> 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. > Please don't use this phrasing, because it's not true. There is no circumstance where the GNU version 3 licenses (GPL, LGPL, AGPL) are incompatible with secure boot environments. What you're talking about is an additional restriction *you* are imposing in which you don't want to make it possible for the software to be user-serviceable for any purpose. That's not the same thing as "secure boot". > 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 ? > I'm not sure there is a conflict, but there are relatively few authors of the libbtrfsutil code, so we could get the license downgraded to LGPLv2+ instead of being LGPLv3+. -- 真実はいつも一つ!/ Always, there's only one truth! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2020-12-08 12:37 ` Neal Gompa @ 2020-12-08 13:25 ` Stefano Babic 0 siblings, 0 replies; 12+ messages in thread From: Stefano Babic @ 2020-12-08 13:25 UTC (permalink / raw) To: Neal Gompa, Stefano Babic; +Cc: Btrfs BTRFS, Omar Sandoval, David Sterba Hi Neal, On 08.12.20 13:37, Neal Gompa wrote: > On Tue, Dec 8, 2020 at 4:52 AM Stefano Babic <sbabic@denx.de> 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. >> > > Please don't use this phrasing, because it's not true. There is no > circumstance where the GNU version 3 licenses (GPL, LGPL, AGPL) are > incompatible with secure boot environments. What you're talking about > is an additional restriction *you* are imposing in which you don't > want to make it possible for the software to be user-serviceable for > any purpose. That's not the same thing as "secure boot". > Sorry for misunderstanding, you're right - but you have perfectly understood what I meant ;-) >> 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 ? >> > > I'm not sure there is a conflict, but there are relatively few authors > of the libbtrfsutil code, so we could get the license downgraded to > LGPLv2+ instead of being LGPLv3+. This would be really nice ! 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 ===================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2020-12-08 9:49 btrfs-progs license Stefano Babic 2020-12-08 10:32 ` ronnie sahlberg 2020-12-08 12:37 ` Neal Gompa @ 2020-12-08 21:00 ` Omar Sandoval 2020-12-10 11:27 ` David Sterba 2 siblings, 1 reply; 12+ messages in thread From: Omar Sandoval @ 2020-12-08 21:00 UTC (permalink / raw) To: Stefano Babic; +Cc: linux-btrfs, David Sterba 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2020-12-08 21:00 ` Omar Sandoval @ 2020-12-10 11:27 ` David Sterba 2020-12-10 12:03 ` Stefano Babic 0 siblings, 1 reply; 12+ messages in thread From: David Sterba @ 2020-12-10 11:27 UTC (permalink / raw) To: Omar Sandoval; +Cc: Stefano Babic, linux-btrfs, David Sterba 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'd like to understand what's the problem with LGPLv3 before we'd consider switching to LGPLv2, which I'd rather not do. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2020-12-10 11:27 ` David Sterba @ 2020-12-10 12:03 ` Stefano Babic 2021-01-14 18:47 ` David Sterba 2021-01-14 19:38 ` Neal Gompa 0 siblings, 2 replies; 12+ messages in thread From: Stefano Babic @ 2020-12-10 12:03 UTC (permalink / raw) To: dsterba, Omar Sandoval, Stefano Babic, linux-btrfs, David Sterba 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 ===================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2020-12-10 12:03 ` Stefano Babic @ 2021-01-14 18:47 ` David Sterba 2021-01-14 20:00 ` Stefano Babic 2021-01-14 19:38 ` Neal Gompa 1 sibling, 1 reply; 12+ messages in thread From: David Sterba @ 2021-01-14 18:47 UTC (permalink / raw) To: Stefano Babic; +Cc: dsterba, Omar Sandoval, linux-btrfs, David Sterba 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. There are no new changes to libbtrfsutil so the number of people who'd need to agree with the potential relicensing remains the same. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2021-01-14 18:47 ` David Sterba @ 2021-01-14 20:00 ` Stefano Babic 0 siblings, 0 replies; 12+ messages in thread From: Stefano Babic @ 2021-01-14 20:00 UTC (permalink / raw) To: dsterba, Stefano Babic, Omar Sandoval, linux-btrfs, David Sterba 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 ===================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2020-12-10 12:03 ` Stefano Babic 2021-01-14 18:47 ` David Sterba @ 2021-01-14 19:38 ` Neal Gompa 2021-01-14 20:16 ` Stefano Babic 1 sibling, 1 reply; 12+ messages in thread From: Neal Gompa @ 2021-01-14 19:38 UTC (permalink / raw) To: Stefano Babic; +Cc: dsterba, Omar Sandoval, Btrfs BTRFS, David Sterba On Thu, Dec 10, 2020 at 7:18 AM Stefano Babic <sbabic@denx.de> wrote: > > 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. While I'm not a lawyer, what I've been told by others is that it just means that you need a way to reset the keys for loading custom software. That doesn't mean giving your official keys, just a way to reset the trust for custom keys. This is analogous to how Secure Boot works on PCs with support for adding the user's own keys and removing preloaded keys. You can design systems to only interoperate on matching keys, so if a custom firmware is loaded, it's distrusted by standard firmware, and so on. This approach actually makes sense for the longevity of secure devices in the field, because they often outlast the companies that made them. Having a way to have another party "take over" and maintain the firmware is a good thing for the long-term stability of leveraging technology in sensitive industries. -- 真実はいつも一つ!/ Always, there's only one truth! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: btrfs-progs license 2021-01-14 19:38 ` Neal Gompa @ 2021-01-14 20:16 ` Stefano Babic 0 siblings, 0 replies; 12+ messages in thread From: Stefano Babic @ 2021-01-14 20:16 UTC (permalink / raw) To: Neal Gompa, Stefano Babic Cc: dsterba, Omar Sandoval, Btrfs BTRFS, David Sterba Hi Neal, On 14.01.21 20:38, Neal Gompa wrote: > On Thu, Dec 10, 2020 at 7:18 AM Stefano Babic <sbabic@denx.de> wrote: >> >> 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. > > While I'm not a lawyer, what I've been told by others is that it just > means that you need a way to reset the keys for loading custom > software. That doesn't mean giving your official keys, just a way to > reset the trust for custom keys. This is analogous to how Secure Boot > works on PCs with support for adding the user's own keys and removing > preloaded keys. This is correct, but this is unsatisfactory for embedded devices. Full agree in case of PCs, where you can load your keys. But think about a medical device (a lung ventilator, for example, as we are all rather conditioned from news), or a device that was certified by some authority. It is simply not allowed to replace the running firmware, and manufacturers want to be sure that only their software is allowed to run. Or device on aircraft, or whatever. It is more over the initial reason for GPLv3, that is the "tivoization" on set-top boxes. For such kind of restrictive applications, replacing the software is a noway. Manufacturers take care of this issue, run fossology and they avoid (L)GPLv3 software at all, even if it is easier and technically better to use them. > > You can design systems to only interoperate on matching keys, so if a > custom firmware is loaded, it's distrusted by standard firmware, and > so on. > Agree, but this cannot be applied for any device. > This approach actually makes sense for the longevity of secure devices > in the field, because they often outlast the companies that made them. > Having a way to have another party "take over" and maintain the > firmware is a good thing for the long-term stability of leveraging > technology in sensitive industries. This is not what I see in the embedded systems, and specially in case of certified devices. 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 ===================================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-01-14 20:18 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2021-01-14 19:38 ` Neal Gompa 2021-01-14 20:16 ` Stefano Babic
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).