Here are a few snippets out of a private mail on this topic; I've removed the original mail and paraphrased its contents since I firmly believe in not publishing any content (incl. metadata) from private e-mails that isn't my own :)
----- Forwarded message from David Lamparter <equi...@diac24.net> ----- Someone wrote: > On Wed, 20 Mar 2019, David Lamparter wrote: > > That is really the crux of the question here. The code does contain > > /references/ to libfrr functions and data structures. But it doesn't > > contain any code that was copied/moved/directly derived from GPL > > functionality. Is it still considered derivative? > > > > We (FRR) believe it isn't. That's why we think we can still distribute > > babeld and ldpd under their permissive licenses. > [Someone cited section 2b of the GPL here] > > "You must cause any work that you distribute or publish, that in > whole or in part contains or is derived from the Program or any part > thereof, to be licensed as a whole at no charge to all third parties > under the terms of this License." > > [Someone argues here that since babeld is distributed with FRR, the > whole work falls under the GPL] I understand your argument, and it has indeed come up before, and you need to continue reading the GPL. Section 4 reads: 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. Note that it says here "the Program", not "work [...] that in whole or in part contains [...] the Program". While section 2b that you cited requires cost-free distribution and GPL license of any additional parts of the larger work, it does not exclude that larger work from being licensed more permissively. That requirement against more permissive licensing is only established in section 4 above, and only for "the Program" (which includes derivatives of it per the definition of section 0, but not collective works.) > [Someone linked to: > https://repository.jmls.edu/cgi/viewcontent.cgi?article=1014&context=jitpl ] I'm not sure that document says what you believe it says. Refer to page 493 (inline numbering): On the other hand, it is axiomatic that changing the GPL program's source code creates a derivative work. Distributing that derivative work makes it subject to the terms of the GPL. These two scenarios are the only bright line rules for copyleft in the GPL. Between the end-points of mere aggregation and direct source modification lays a broad spectrum of possible combinations that the terms of the GPL may or may not reach. [...] Whether the FSF could convince a court to enforce copyleft on these kinds of combinations remains to be seen. The FSF's license enforcement group has charged many organizations with violating the GPL, but every case in the United States has been quietly settled outside of court. There is literally no legal precedent in the United States concerning enforcement of the GPL at the time of this writing. Without legal precedent establishing which specific technical software combinations impose copyleft, practitioners must predict their legal standing by determining whether the proprietary software within a combination, infringes on the distribution rights of the GPL software licensor. They also must consider whether the proprietary software constitutes a derivative work. I should probably point out at this junction that the SFLC, which is one of the legal opinions Paul has sought, was also contacted by the FreeBSD project about this same issue. For Paul, I am only aware of a preliminary response supportive of his opinion that the SFLC has given with a caveat of further inspection needed. The FreeBSD project followed through with that request for time and further consideration, and has - to my best knowledge - received an elaborated response from the SFLC indicating that FRR's licensing is OK. (I need to contact the FreeBSD people or SFLC to get a copy of that, I've only been told about this recently and can't guarantee for its correctness. As I'm currently attending netdevconf & IETF, there's probably a delay of 2 weeks until I have spare cycles to hunt this down, but of course it doesn't need to be me to do this, if anyone wants to poke the SFLC or the FreeBSD project.) [Some content cut] -David ----- End forwarded message -----