Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)

[David Lamparter <equinox@diac24.net>]

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 <equinox@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 -----