FRR package in Debian violates the GPL licence

[Paul Jakma]

Hi,

The FRR package contains code, e.g. in the ldpd and babeld directories
notably, which can not function without the assistance of and
orchestration of GPL code; code whose function can not be understood
without reference to the GPL source code - this FRR code is deriving of
the GPL code (as per multiple sets of legal advice available to me),
which I hold copyright in.

The code concerned however is explicitly /not/ being distributed under
the terms required by the GPL licence, but rather much weaker licences
(BSD or MIT/X11, e.g.). Licenses which fail to implement the reciprocal
source code publication conditions of the GPL, amongst other things.

This is no accident. It is a deliberate campaign to undermine the GPL on
this code-base, to normalise the stripping of copyleft requirement from
it, and permit the ability to build proprietary works on top of it.
E.g., see:

https://github.com/FRRouting/frr/issues/1923

It is - I am advised - not permitted by the GPL and infringing of my
copyright in thise code-base, and also incitement to commit copyright
infringement. As such, the termination clause of the GPL became
applicable to FRR.

Use and distribution is unlicensed.

I reserve the right to recover damages and compensation, to the greatest
extent allowed by relevant laws, from anyone any unlicensed use or
distribution of code I hold copyright in.

regards,

[Andrej Shadura]

Hi Paul,

Post by Paul Jakma
It is - I am advised - not permitted by the GPL and infringing of my
copyright in thise code-base, and also incitement to commit copyright
infringement. As such, the termination clause of the GPL became
applicable to FRR.
Use and distribution is unlicensed.

I’m afraid your understanding of how the GPL works is incorrect.

[Don Armstrong]

Post by Paul Jakma
The code concerned however is explicitly /not/ being distributed under
the terms required by the GPL licence, but rather much weaker licences
(BSD or MIT/X11, e.g.). Licenses which fail to implement the
reciprocal source code publication conditions of the GPL, amongst
other things.

Because Debian distributes[1] FRR in compliance with the terms of the
GPL, and the terms of the license of the subparts of FRR are compatible
with the GPL, Debian is not in violation of the terms of the GPL.

Post by Paul Jakma
It is - I am advised - not permitted by the GPL and infringing of my
copyright in thise code-base, and also incitement to commit copyright
infringement. As such, the termination clause of the GPL became
applicable to FRR.

The termination clause of the GPL applies to entities who are
redistributing FRR not to the code base in general; as Debian
redistributes in compliance with the GPL (and presumably the FRR project
on github does as well), Debian hasn't activated GPL-2 §4.

I suggest reaching out to Richard Fontana (or your own legal
representation) if any of this is unclear;
https://github.com/FRRouting/frr/issues/1923 has the start of covering
some of this.

1: Or at least, we should be; if not, please file the bug so it can be
fixed.

[Paul Jakma]

Post by Don Armstrong

Post by Paul Jakma
The code concerned however is explicitly /not/ being distributed under
the terms required by the GPL licence, but rather much weaker licences
(BSD or MIT/X11, e.g.). Licenses which fail to implement the
reciprocal source code publication conditions of the GPL, amongst
other things.

Because Debian distributes[1] FRR in compliance with the terms of the
GPL, and the terms of the license of the subparts of FRR are
compatible with the GPL, Debian is not in violation of the terms of
the GPL.

The GPL stipulates that the distributor must "appropriately publish on
each copy an appropriate copyright notice".

FRR deliberately do not so on a number of files, in the ldpd and babeld
directories most notably, even where those files do prominently feature
notice of another licence (a weaker one lacking the requirements of the
GPL).

This is very deliberate, as FRR denies the applicablility of the GPL to
those files, even though these files are dependent on the GPL source
code for function and comprehension and these files are derived works of
the GPL source code, according to legal advice. The FRR project - by
their own words - are not distributing this code under the GPL,
manifested no least by their refusal to comply with the notification
requirement of the GPL.

Non-compliance with conditions stipulated by the GPL licence, on code
that may only be distributed in accordance with the GPL licence, is an
infringement of copyright.

Post by Don Armstrong
The termination clause of the GPL applies to entities who are
redistributing FRR not to the code base in general; as Debian
redistributes in compliance with the GPL (and presumably the FRR
project on github does as well), Debian hasn't activated GPL-2 §4.

The FRR project, and associated entities (such as Cumulus Networks, Big
Switch Networks, 6WIND, LAbN Consulting, Orange Telecom, the Linux
Foundation) have no GPL licence for this code-base.

The Debian project can not magically grant itself a GPL licence for this
infringing code, when the FRR project have none to give.

regards,

[Don Armstrong]

Post by Paul Jakma
The GPL stipulates that the distributor must "appropriately publish on
each copy an appropriate copyright notice".

Debian does, in /usr/share/doc/frr/copyright.

Post by Paul Jakma
This is very deliberate, as FRR denies the applicablility of the GPL
to those files, even though these files are dependent on the GPL
source code for function and comprehension and these files are derived
works of the GPL source code, according to legal advice.

My understanding is that those files in themselves are not derivative
works of GPLed source code, but the entire FRR project is. At least,
that's the judgment of the project in
https://github.com/FRRouting/frr/issues/1923

Post by Paul Jakma
The Debian project can not magically grant itself a GPL licence for
this infringing code, when the FRR project have none to give.

As long as Debian is complying with the GPL, whether the FRR project is
or is not complying is irrelevant according to GPL-2 §4:

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.

I'm afraid that the underlying issue here is a dispute between the
Quagga project and the FRR fork of the Quagga project;[1] Debian isn't a
party to this dispute, and it's not Debian's job to choose a winner. I
hope that the parties to the dispute will compete on the merits or even
better, collaborate in the future.

Best of luck.


1: https://lists.quagga.net/pipermail/quagga-users/2017-August/014815.html

[Paul Jakma]

Post by Don Armstrong
Debian does, in /usr/share/doc/frr/copyright.

That is not one of the files at issue.

Post by Don Armstrong
My understanding is that those files in themselves are not derivative
works of GPLed source code, but the entire FRR project is. At least,
that's the judgment of the project in
https://github.com/FRRouting/frr/issues/1923

I am going to stick with the legal advice I have received, including
from a solicitor specialising in copyright, over the belief of someone
with no qualifications in this area and no experience other than having
read some stuff on the Internet.

Post by Don Armstrong
As long as Debian is complying with the GPL, whether the FRR project

The FRR project had no licence under which to lawfully distribute these
files to the Debian project. These files remain unlicensed, even in the
hands of the Debian project, regardless of the good intent (or
otherwise) of the Debian project. The Debian project has no licence to
distribute them under either.

Post by Don Armstrong
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.

"have" - do note the past tense there.

As the FRR project have _never_ complied with the GPL with regard to
these files, there was never and never will be a GPL licence to
distribute them under. Nor to downstreams.

At least, so long as no one resolves this issue to the satisfaction of
the copyright holders whose work has been infringed (and no one has ever
tried with me - though I have approached some large organisations on
this in the past, to no avail).

Post by Don Armstrong
Quagga project and the FRR fork of the Quagga project;[1] Debian isn't
a party to this dispute,

The Debian project is a party to this dispute, given you are choosing to
distribute the infringing work.

Post by Don Armstrong
and it's not Debian's job to choose a winner.

That's not my concern.

My concern is that the Debian project abides by what is legally required
by copyright law, certainly with respect to work I hold copyright in.

regards,

[Don Armstrong]

Post by Paul Jakma

Post by Don Armstrong
Debian does, in /usr/share/doc/frr/copyright.

That is not one of the files at issue.

That's in the binary package and source package that Debian distributes;
we don't distribute files separately.

Post by Paul Jakma
I am going to stick with the legal advice I have received, including
from a solicitor specialising in copyright, over the belief of someone
with no qualifications in this area and no experience other than
having read some stuff on the Internet.

This *is* debian-legal; if anything anyone said here was actually
qualified legal advice, it wouldn't be given in this forum. It certainly
wouldn't be given by me.

Since there's not much more debian-legal can do for you, please seek out
a resource with legal representation like the Software Freedom
Conservancy who has expertise in copyright law and its application to
free software/open source.

Best of luck.

[Paul Jakma]

Post by Don Armstrong

Post by Paul Jakma
I am going to stick with the legal advice I have received, including
from a solicitor specialising in copyright, over the belief of
someone with no qualifications in this area and no experience other
than having read some stuff on the Internet.

This *is* debian-legal; if anything anyone said here was actually
qualified legal advice, it wouldn't be given in this forum. It
certainly wouldn't be given by me.

Note, the "someone with no qualifications in this area" was referring a
member of the FRR project - not you (I don't know you).

Post by Don Armstrong
Since there's not much more debian-legal can do for you, please seek
out a resource

I'm not looking for legal advice here. I have taken advice (indeed, I
have two independent sets of legal advice on this; i.e., another set of
advice obtained after the email of mine you linked to).

I am informing debian-legal of that advice, given that Debian appears to
be distributing the infringing work.

regards,

[Paul Jakma]

what if Debian added such the missing header to those files that miss
it before packaging, so that the source packages comply with the
License?

My understanding is the work would still be unlicensed. There is no GPL
licence available from anyone for the infringing work.

One would need to obtain a licence from all the copyright holders
concerned. According to advice, I am one of those copyright holders. And
that includes having a copyright interest in the code in the ldpd/ and
babeld/ directories of FRR, being code which depends explicitly and
heavily on the GPL code in the other directories and which can not be
compiled, comprehended or function without reference to the GPL source
code.

I'm open to resolving this, as part of a wider resolution of the issues
in this matter. Otherwise, I would be unlikely to.

The likelyhood of someone being able to drive this to resolution... But
people are welcome to try.

If the only possible license for that code is GPL (as it depends on
GPL code) one might argue that the lack of GPL header is a bug that
might fool a user to use that file as permissively licensed,
terminating his own license forever!

This isn't a "bug". This is a very deliberate attempt by a set of
corporates, led by Cumulus Networks, under a Linux Foundation project
aegis, to try erase the copyleft nature of the GPL licence on code,
which they havn't the right to do.

They are trying to forge a new reality for GPL code, where other
people's GPL code can be treated as if it had a much weaker licence, so
it can be appropriated by said corporates and their customers.

In any case if Debian distribute the code as GPL and that code can
only EXIST as a GPL derivative (thus GPL itself) they are not
violating anything, and they could easily add the missing headers just
to protect the user from an accidental but definotive termination.

We're talking about code that can only be distributed under the terms
required by the GPL, and where the original distributors of that code
have forfeited their right to distribute that code under the GPL through
licence infringement - from T=0.

Also, read David's email, where he is speaking for FRR: He is explicit
that FRR are _not_ distributing the source code concerned under the GPL
(and hence refuse to comply with the GPL notification requirements, even
where they have placed prominent notices of other applicable licences
which they find favourable). If there is any doubt as to whether FRR are
distributing the source code concerned under the GPL, I hope David's
email has dispelled it. Take him at his word.

I'd have to take advice to be 100% sure, but I do not believe it is
possible to obtain the code concerned with a GPL licence. Also, I do not
believe it is possible to take unlicensed code, slap a GPL notice on it,
and just unilaterally grant oneself a GPL licence to other people's
code.

regards,

[David Given]

On Mon, 18 Mar 2019 at 11:10 Paul Jakma <***@jakma.org> wrote:
[...]

Post by Paul Jakma
One would need to obtain a licence from all the copyright holders
concerned. According to advice, I am one of those copyright holders. And
that includes having a copyright interest in the code in the ldpd/ and
babeld/ directories of FRR, being code which depends explicitly and
heavily on the GPL code in the other directories and which can not be
compiled, comprehended or function without reference to the GPL source
code.

I'll admit to having trouble following.

Can you point at a specific example of a derived file which they're
distributing under the BSD license, and the GPL-licensed file it was
derived from?

[Paul Jakma]

Post by David Given
[...]

Post by Paul Jakma
One would need to obtain a licence from all the copyright holders
concerned. According to advice, I am one of those copyright holders. And
that includes having a copyright interest in the code in the ldpd/ and
babeld/ directories of FRR, being code which depends explicitly and
heavily on the GPL code in the other directories and which can not be
compiled, comprehended or function without reference to the GPL source
code.

I'll admit to having trouble following.
Can you point at a specific example of a derived file which they're
distributing under the BSD license, and the GPL-licensed file it was
derived from?

It'd probably be easier to list the files which are /not/. I tried a
number of years ago - when I still thought (naively) others were
ultimately acting in good faith and wished to respect licences - to
untangle quagga-babeld into files with the GPL-dependent sections, and
the files with just the original non-GPL-dependent code.

I was able to get about 3 .c files (and their .h) be clearly independent
of the GPL library, and even then it needed a small compatibility
library.

The other side rejected this approach to resolving the matter.

----

Anyway, a small, non-exhaustive sampling with rough, incomplete notes -
for the sake of speed:

https://github.com/FRRouting/frr/blob/master/babeld/babel_filter.c

Depends heavily on lib/vty.{c,h} for the "VTY" CLI sub-system provided
by the GPL source code, lib/prefix.{c,h} for address prefix, on
lib/log.{c,h}, etc., and contains code which is exported as callbacks to
have its execution orchestrated by GPL code, and see below.

https://github.com/FRRouting/frr/blob/master/babeld/babel_interface.c

Depends heavily on lib/command.{c,h}, etc.. Further, its functionality
is orchestrated via the GPL library code by defining callbacks for
babel_zebra below to register, whose execution is ultimately
orchestrated by the GPL library code as well as being dependent on the
GPL zebra daemon.

https://github.com/FRRouting/frr/blob/master/babeld/babel_zebra.c

Depends heavily on lib/command.{c,h}, lib/stream.*, lib/zclient.*, and
on the GPL zebra daemon.

Many/most of these subsystems further depend on other pieces of GPL
library or daemon code.

It's a similar story with ldpd/, there are a good number of files for
which the FRR project have not put GPL headers on deliberately (see
David's email), which make use of and depend upon (as per at top) GPL
library and daemon code. E.g.:

https://github.com/FRRouting/frr/blob/master/ldpd/ldpd.c

Depends on lib/sigevent, lib/zclient (see comments above), lib/thread,
etc. etc.

I don't think it's disputed that this code is wholly dependent on the
GPL code for execution - it's implicit in David's email that this is the
case, where he acknowledges (at least) that FRR accept that the
/binaries/ are covered by the GPL.

regards,

[David Given]

On Mon, 18 Mar 2019 at 13:09 Paul Jakma <***@jakma.org> wrote:
[...]

Post by Paul Jakma
Anyway, a small, non-exhaustive sampling with rough, incomplete notes -

Thanks!

I may be missing something here, but none of the examples you gave show any
signs of being derived code. They *use* vty.[ch], but do not include any of
their code (bear in mind that I'm not familiar with either code base).

Being merely dependent on third-party code is not, to my understanding,
sufficient to be considered derived code.

It looks like this is a clearcut case of aggregation:

somepackage/gpllibrary/COPYING.GPL
somepackage/bsdlibrary/COPYING.BSD
somepackage/COPYING.GPL

bsdlibrary can be distributed *on its own* under the terms of the BSD, but
if it's distributed along with gpllibrary, then the combined licensing
terms of both libraries can only be met by the combined package being
distributed under the terms of the GPL.

In FRR's case, the combined repository is clearly labelled as being
distributable under the terms of the GPL. This all looks fine to me.

[Paul Jakma]

Post by David Given
Being merely dependent on third-party code is not, to my
understanding, sufficient to be considered derived code.

If code which is written to depend explicitly and heavily on the APIs
and frameworks provided by GPL is /not/ considered subject to the GPL,
but 'mere' 'aggregration', one would wonder why the LGPL would ever have
been drafted. One would wonder why readline was ever an issue for the
BSDs. etc., etc.

Your legal analysis is not inline with formal legal advice given by
qualified solicitors, who have examined this issue. That advice is that
the code concerned is deriving of the GPL code.

I will stick with the views of those qualified solicitors, over the view
of a software engineer, at least on legal matters.

regards,

[Paul Jakma]

I think I have seen MIT/BSD pieces of code in most of the GPL projects
I have looked into.

Nothing in the advice I have received precludes the happy co-existence
of MIT/BSD code with GPL code in the same project.

The cases you have in mind, presumably, are those where BSD/MIT code has
been imported but /not/ modified and extended such that that code
derives from GPL licensed code.

Which is a different case to this case.

regards,

[Thorsten Alteholz]

I think I have seen MIT/BSD pieces of code in most of the GPL

projects

I have looked into.

Nothing in the advice I have received precludes the happy co-existence
of MIT/BSD code with GPL code in the same project.

You might want to have a look at [1]. Each module might have its own
license but the whole work has to be licensed under GPL.
Maybe [2] helps as well when you replace "public domain" by MIT license.

Thorsten



[1] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#IfLibraryIsGPL
[2] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#CombinePublicDomainWithGPL

[Paul Jakma]

Post by Thorsten Alteholz
[2]
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#CombinePublicDomainWithGPL

"You can do that, if you can figure out which part is the public domain
part and separate it from the rest."

Indeed...

See also my earlier email on trying to separate the code (and if you
google you might find more on that).

regards,

[Vincent Bernat]

Post by Paul Jakma

Post by David Given
Being merely dependent on third-party code is not, to my
understanding, sufficient to be considered derived code.

If code which is written to depend explicitly and heavily on the APIs
and frameworks provided by GPL is /not/ considered subject to the GPL,
but 'mere' 'aggregration', one would wonder why the LGPL would ever
have been drafted. One would wonder why readline was ever an issue for
the BSDs. etc., etc.

IMO because the definition of derived work comes from binary linking
(static or dynamic). There are libreadline alternatives licensed under a
BSD-like license (like libedit or libeditline). There are
API-compatible, not ABI-compatible. If you link the program with
libreadline, you have to distribute the result under the GPL. If you
link it with libedit, you don't have to. The source code of the program
is exactly the same. Is it GPL or is it not?

The API exposed by Quagga could be provided by another project using
another license.

Post by Paul Jakma
I will stick with the views of those qualified solicitors, over the
view of a software engineer, at least on legal matters.

Maybe these views could be published somewhere.

[Paul Jakma]

Post by Vincent Bernat
IMO because the definition of derived work comes from binary linking
(static or dynamic).

The advice I've had did not reason in these terms.

As I know the FRR people think computer technical implementation details
like dynamic linkage, and address spaces, etc., are very important here,
I specifically double-checked with the solicitor, and my understanding
is they are not really relevant here.

Which I guess isn't surprising, as things like "derived work" (or
"adapted work", etc.) are legal terms that do not really depend on the
low-level technicalities of computer programming.

Post by Vincent Bernat
There are libreadline alternatives licensed under a BSD-like license
(like libedit or libeditline). There are API-compatible, not
ABI-compatible. If you link the program with libreadline, you have to
distribute the result under the GPL. If you link it with libedit, you
don't have to. The source code of the program is exactly the same. Is
it GPL or is it not?
The API exposed by Quagga could be provided by another project using
another license.

If there had been other completely independent implementations of the
facilities and functions provided at present by the GPL code they
obtained from Quagga (and GNU Zebra before it), then perhaps the legal
advice would be different. I don't know, but I concede it could be -
you'd have to ask a lawyer.

Anyway, that's not the reality we're in.

Post by Vincent Bernat

Post by Paul Jakma
I will stick with the views of those qualified solicitors, over the
view of a software engineer, at least on legal matters.

Maybe these views could be published somewhere.

Sure.

Will do, once Cumulus Networks, 6WIND, Linux Foundation,
NetDEF/OpenSourcerouting.org/whatever other corporates Martin Winter or
Alistair Woodman or David Lamparter are involved in, etc., publish their
legal advice on this matter.

regards,

[David Lamparter]

Post by Don Armstrong
My understanding is that those files in themselves are not derivative
works of GPLed source code, but the entire FRR project is. At least,
that's the judgment of the project in
https://github.com/FRRouting/frr/issues/1923

For the record, with both my hats as the Debian maintainer for the frr
source package as well as a TSC member on the FRRouting project, I would
like to note that this is indeed my/our understanding of our licensing
situation.

We expressly acknowledge that FRR binary packages must be distributed in
their entirety under GPLv2 or newer, and this is what I thought is
indicated in the Debian package too. (If I have messed that up, I
sincerely apologize and will fix that as soon as possible - please point
me in the appropriate direction.)

We do not believe any of the _source_code_ in ldpd or babeld is
derivative of Quagga (or other) GPL source code.

The respective original authors have expressed and reaffirmed their
wishes for the code to remain under a permissive license. While we
could obviously just slap GPL on top, we have decided to try and honour
the original author's requests.

We would also have liked to comply with Paul's wishes as an author on
Quagga. However, since the two are mutually exclusive, and Paul's
wishes are applying to other people's code while ldpd & babeld are about
the respective author's wishes for their own code, the latter seemed the
more appropriate choice. As we don't understand the code in question to
be derivative, we don't see a legal obligation in this choice.

Cheers,


-David


P.S.: please Cc: me as I'm not subscribed to debian-legal.

[Ole Streicher]

Post by David Lamparter
We expressly acknowledge that FRR binary packages must be distributed in
their entirety under GPLv2 or newer, and this is what I thought is
indicated in the Debian package too.

Debian does not attach *any* license to a binary package. It just
documents the licenses of the sources. There is however no way (except
carefully going through the [documented] build process) to find out,
under which conditions a binary files can be used/(re)distributed/modified.

Best

Ole

[David Lamparter]

Post by Ole Streicher

Post by David Lamparter
We expressly acknowledge that FRR binary packages must be
distributed in their entirety under GPLv2 or newer, and this is what
I thought is indicated in the Debian package too.

Debian does not attach *any* license to a binary package.

Huh. This is slightly surprising to me, I thought binaries always need
a license attached too. But now that I think about it, indeed I don't
even know how I would get a license "label" for a random binary .deb...
(as you say, the shipped copyright file documents its sources...)

Post by Ole Streicher
It just documents the licenses of the sources. There is however no way
(except carefully going through the [documented] build process) to
find out, under which conditions a binary files can be
used/(re)distributed/modified.

Well. Presumably that should yield the same result. Either way I'll
add some extra comments/docs.

Cheers,

-David

[Paul Wise]

Post by David Lamparter
Huh. This is slightly surprising to me, I thought binaries always need
a license attached too. But now that I think about it, indeed I don't
even know how I would get a license "label" for a random binary .deb...
(as you say, the shipped copyright file documents its sources...)

There is a debhelper feature that lets you put different copyright
files into each binary package. I've used it in the past where a utils
package had a different license to the library package. We certainly
don't systematically do this, as there is simply no way to determine
what file in the binary package is derived from what file(s) in the
source package and what command produced them.

[Roberto]

Post by David Lamparter
The respective original authors have expressed and reaffirmed their
wishes for the code to remain under a permissive license. While we
could obviously just slap GPL on top, we have decided to try and honour
the original author's requests.

Indeed, when including external libraries/files into a software project,
I was always encouraged to contribute my changes under the same license
of each individual part, for polite reasons. So, I am somewhat puzzled
about this issue.

On the other side, if I understood correctly, there are authors who want
to contribute their code under GPL exclusively, and they feel that some
of their changes got included into the bundled libraries (and are
significant enough to be covered by copyright), so those libraries
should be wrapped by the GPL as well.

Maybe those external libraries should not be imported in the first
place, to respect all authors' wishes seems imposible when they are
mutually exclusive, and that's looks "murky" even if allowed by the
license.

[Paul Jakma]

Post by Roberto
On the other side, if I understood correctly, there are authors who
want to contribute their code under GPL exclusively, and they feel
that some of their changes got included into the bundled libraries
(and are significant enough to be covered by copyright), so those
libraries should be wrapped by the GPL as well.

It's not like that. It's more like (as a high-level summary):

1. There are GPL libraries (and associated support daemons), providing a
number of facilities.

2. There is BSD and MIT/X11 licensed code

3. People took the code of (2), and adapted that code - extensively and
explicitly - to make use of and rely upon the facilities of the code
of (1); facilities which were missing in the code of (2).

The people involved in (3) - Linux Foundation, Cumulus Networks, 6WIND,
Big Switch Networks, etc. - refuse to acknowledge the legal reality that
the code of (3) is covered by the GPL licence of the code of (2), and
refuse to honour the conditions required by the GPL - see David
Lamparter's mail.

They've gone to great lengths on that, including using corporate
connections to adversely affect the employment of copyright holders of
(2), where those copyright holders objected to what the people of (3)
were doing.

regards,

[Paul Jakma]

Post by Paul Jakma

Post by Roberto
On the other side, if I understood correctly, there are authors who want
to contribute their code under GPL exclusively, and they feel that some of
their changes got included into the bundled libraries (and are significant
enough to be covered by copyright), so those libraries should be wrapped
by the GPL as well.

1. There are GPL libraries (and associated support daemons), providing a
number of facilities.
2. There is BSD and MIT/X11 licensed code
3. People took the code of (2), and adapted that code - extensively and
explicitly - to make use of and rely upon the facilities of the code
of (1); facilities which were missing in the code of (2).
The people involved in (3) - Linux Foundation, Cumulus Networks, 6WIND, Big
Switch Networks, etc. - refuse to acknowledge the legal reality that the code
of (3) is covered by the GPL licence of the code of (2), and refuse to honour
the conditions required by the GPL - see David Lamparter's mail.
They've gone to great lengths on that, including using corporate connections
to adversely affect the employment of copyright holders of (2), where those

s/of (2)/of (1)/

Post by Paul Jakma
copyright holders objected to what the people of (3) were doing.
regards,

regards,

[Roberto]

Post by Paul Jakma
3. People took the code of (2), and adapted that code - extensively and
explicitly - to make use of and rely upon the facilities of the code
of (1); facilities which were missing in the code of (2).
The people involved in (3) - Linux Foundation, Cumulus Networks, 6WIND, Big
Switch Networks, etc. - refuse to acknowledge the legal reality that the
code of (3) is covered by the GPL licence of the code of (2), and refuse to
honour the conditions required by the GPL - see David Lamparter's mail.

Well, that's more complicated than I've thought. Under my point of view,
those companies are right, sorry to say that.

[Ole Streicher]

Post by Paul Jakma
The people involved in (3) - Linux Foundation, Cumulus Networks,
6WIND, Big Switch Networks, etc. - refuse to acknowledge the legal
reality that the code of (3) is covered by the GPL licence of the code
of (2), and refuse to honour the conditions required by the GPL - see
David Lamparter's mail.

And which statement of the GPL do they violate in your opinion?

Ole

[Paul Jakma]

Post by Ole Streicher

Post by Paul Jakma
The people involved in (3) - Linux Foundation, Cumulus Networks,
6WIND, Big Switch Networks, etc. - refuse to acknowledge the legal
reality that the code of (3) is covered by the GPL licence of the code
of (2), and refuse to honour the conditions required by the GPL - see
David Lamparter's mail.

And which statement of the GPL do they violate in your opinion?

a) They are very clear they are /not/ distributing the source code under
the GPL licence.

b) They are not complying with Section 1.

regards,

[Ole Streicher]

Post by Paul Jakma

Post by Ole Streicher

Post by Paul Jakma
The people involved in (3) - Linux Foundation, Cumulus Networks,
6WIND, Big Switch Networks, etc. - refuse to acknowledge the legal
reality that the code of (3) is covered by the GPL licence of the code
of (2), and refuse to honour the conditions required by the GPL - see
David Lamparter's mail.

And which statement of the GPL do they violate in your opinion?

a) They are very clear they are /not/ distributing the source code under
the GPL licence.
b) They are not complying with Section 1.

In GPLv2, section 1 allows the distribution of unmodified source code,
if the license information is distributed unmodified as well.

Which unmodified GPL source code do they distribute without the
licensing information?

[Paul Jakma]

Post by Ole Streicher
In GPLv2, section 1 allows the distribution of unmodified source code,
if the license information is distributed unmodified as well.
Which unmodified GPL source code do they distribute without the
licensing information?

They are distributing files which were created outwith of Quagga, which
explicitly refer to, make use of and rely upon facilities provided by
GPL code obtained from Quagga (which obtained code from GNU Zebra
before it).

I've given some examples of such files, and some of the GPL facilities
they use, see previous mail.

Those files are derived works of the GPL code obtained from Quagga,
according to legal advice. Those files may only be distributed under the
terms of the GPL.

The Quagga project, and the FRR project as well, contain files with a
number of different licences, and one must look at the specific file to
determine the applicable licence(s). It is a file-scoped project with
respect to copyright notices.

To be compliant with the GPL, these files are required by the GPL to
have the appropriate copyright notices, according to legal advice.

They do not.

This is no bug or oversight - it is very deliberate, as the FRR people
have repeatedly made clear (and are adamant) that they are not
distributing these files under the GPL.

regards,

[Giacomo Tesio]

This does not match section 1, which allows the distribution of
unmodified files along with the proper license information.
Again: Could you please point to the section in the GPL that is
violated?

The "with the proper license" part. ;-)


Giacomo

[Ole Streicher]

Post by Giacomo Tesio

This does not match section 1, which allows the distribution of
unmodified files along with the proper license information.
Again: Could you please point to the section in the GPL that is
violated?

The "with the proper license" part. ;-)

As far as I checked, all unmodified GPL licensed files keep the short
GPL statement in the file, and are accompanied with a copy of the GPL in
the project's root directory. To cite the relevant section from GPL:

| 1. You may copy and distribute verbatim copies of the Program's source
| code as you receive it, in any medium, provided that you conspicuously
| and appropriately publish on each copy an appropriate copyright notice
| and disclaimer of warranty; keep intact all the notices that refer to
| this License and to the absence of any warranty; and give any other
| recipients of the Program a copy of this License along with the Program.
|
| You may charge a fee for the physical act of transferring a copy, and
| you may at your option offer warranty protection in exchange for a fee.

This all is respected, for each unchanged file. I don't see a violation
here.

Best

Ole

[Ole Streicher]

Post by Paul Jakma

Post by Ole Streicher

Post by Paul Jakma
b) They are not complying with Section 1.

In GPLv2, section 1 allows the distribution of unmodified source code,
if the license information is distributed unmodified as well.
Which unmodified GPL source code do they distribute without the
licensing information?

They are distributing files which were created outwith of Quagga,
which explicitly refer to, make use of and rely upon facilities
provided by GPL code obtained from Quagga (which obtained code from
GNU Zebra before it).

This does not match section 1, which allows the distribution of
unmodified files along with the proper license information.

Again: Could you please point to the section in the GPL that is
violated?

Best regards

Ole

[Paul Jakma]

This does not match section 1, which allows the distribution of
unmodified files along with the proper license information.

What unmodified files are you referring to?

I have explained several times now that this concerns files which were
created outside of Quagga, adapting portions of BSD or MIT/X11 licensed
code in some cases and writing new files in others, and those files were
written to explicitly refer to, make use of and rely upon the GPL code
from Quagga (and GNU Zebra) for function and comprehension.

Those files are derived works of the GPL code and must be distributed
according to the conditions of the GPL licence, if they are to be
distributed lawfully.

The GPL licence requires appropriate copyright notices in Section 1.
Section 1 applies to unmodified files, and it also applies to modified
files and derived works (see Section 2).

I'm not sure why you keep asking about unmodified files. The GPL applies
to more than just any unmodified files. Please clarify.

regards,

[Ole Streicher]

Post by Paul Jakma

This does not match section 1, which allows the distribution of
unmodified files along with the proper license information.

What unmodified files are you referring to?

Section 1 handles the case of unmodified files, and this is what I
referred to.

Post by Paul Jakma
I have explained several times now that this concerns files which were
created outside of Quagga [...]
Those files are derived works of the GPL code and must be distributed
according to the conditions of the GPL licence, if they are to be
distributed lawfully.

Those files do not use GPL code; they just refer to it. No line of that
code was originated in GPL licensed code.

If someone compiles the code, then the compiler merges the GPL licensed
header, creating an object file that drives from GPL (and must be
distributed as such). But this applies to the object file, not to the
source.

Post by Paul Jakma
The GPL licence requires appropriate copyright notices in Section
1. Section 1 applies to unmodified files, and it also applies to
modified files and derived works (see Section 2).

Files written from scratch are not derived works. When I write the
following lines:

#include <log.h>
int main(void) { zlog_rotate(); return 0; }

then this is my own code, not derived from any GPL code. I can
distribute this code under any license I want, even when it is meant to
be used with the Zebra log implementation, and even when it has no
meaning outside of this.

The created *object* file must be under GPL, if zebra's log.h was used
to create it -- since log.h is GPL.

Best

Ole

[Paul Jakma]

Post by Ole Streicher
Those files do not use GPL code; they just refer to it. No line of that
code was originated in GPL licensed code.

Ah, you're in the "copyright only protects literal copying" camp, and
you don't acknowledge the concept of derived works.

There's little point discussing further with you, if so.

Copyright gives authors of works not just the right not to just control
literal copying, but also a controlling right in any adaptations of
their work (amongst other things). Whether you agree with this or not,
various variants of this concept are law in many countries around the
world.

regards,

[Ole Streicher]

Post by Paul Jakma

Post by Ole Streicher
Those files do not use GPL code; they just refer to it. No line of that
code was originated in GPL licensed code.

Ah, you're in the "copyright only protects literal copying" camp, and
you don't acknowledge the concept of derived works.

In the GPL case, it protects /modified/ code copies.

| 2. You may modify your copy or copies of the Program or any portion
| of it, thus forming a work based on the Program, and copy and [...]

The example I brought, was written from scratch, it was therefore not a
"modified copy".

Post by Paul Jakma
Copyright gives authors of works not just the right not to just
control literal copying, but also a controlling right in any
adaptations of their work (amongst other things).

My example

#include <log.h>
int main(void) { zlog_rotate(); return 0; }

is not an adaption of any GPL code. It is fully written by my
own. Therefore, I don't need to respect the GPL to distribute it. The
same is true for the FRR code as far as I have seen it.

Otherwise you must point to a certain code file and prove that it
contains code which is a modified copy of an GPLed file. Which you not
did yet.

Best

Ole

[Paul Jakma]

Post by Ole Streicher
My example
#include <log.h>
int main(void) { zlog_rotate(); return 0; }
is not an adaption of any GPL code. It is fully written by my
own.

It is written by you, and you have copyright in it (in some way, I
have the vague idea there can be complex legal details in that).

However, assuming this "zlog_rotate" function is non-trivial and a
copyrightable work, then the holder of the copyright in "zlog_rotate"
/also/ has copyright in your work. For your work is based upon the
"zlog_rotate" work - it /is/ an adaptation of it.

I know there are many programmers who can't get their head around that,
however I don't believe that's at all contraversial amongst lawyers.

Post by Ole Streicher
Therefore, I don't need to respect the GPL to distribute it. The
same is true for the FRR code as far as I have seen it.

This is where you're at odds with the solicitors I have had advice from.

Post by Ole Streicher
Otherwise you must point to a certain code file and prove that it
contains code which is a modified copy of an GPLed file. Which you not
did yet.

I have given examples of files where the legal advice is that they are
derived works of the GPL code.

regards,

[Ole Streicher]

Post by Paul Jakma

Post by Ole Streicher
#include <log.h>
int main(void) { zlog_rotate(); return 0; }
is not an adaption of any GPL code. It is fully written by my
own.

It is written by you, and you have copyright in it (in some way, I
have the vague idea there can be complex legal details in that).
However, assuming this "zlog_rotate" function is non-trivial and a
copyrightable work, then the holder of the copyright in "zlog_rotate"
/also/ has copyright in your work. For your work is based upon the
"zlog_rotate" work - it /is/ an adaptation of it.

This work is completely based on my own, there is no intellectual
property of someone else in my source code.

Only the compilation step incorporates other code (via the #include
statement, and, when linked, the library), but this does affect only the
object and executable files.

Post by Paul Jakma

Post by Ole Streicher
Otherwise you must point to a certain code file and prove that it
contains code which is a modified copy of an GPLed file. Which you
not did yet.

I have given examples of files where the legal advice is that they are
derived works of the GPL code.

To comply with section 2, they must be "modified copies". So, please
show the files, the original files, and the modification.

Best

Ole

[Paul Jakma]

Post by Ole Streicher

Post by Ole Streicher
#include <log.h>
int main(void) { zlog_rotate(); return 0; }

This work is completely based on my own, there is no intellectual
property of someone else in my source code.

Except for the big "zlog_rotate" there that you're building on, provides
all the functionality, and which must be understood to understand what
this programme does.

Read Giacomo's email, with the fan fiction example.

Anyway, the advice I have is that the code at issue is a derived work of
GPL code I hold copyright in, and it must be distributed under the terms
of the GPL.

You have a view of copyright which seems at odds with the legal opinions
I'm aware of and there's no point us going in circles on that.

regards,

[Ole Streicher]

Post by Paul Jakma

Post by Ole Streicher

Post by Ole Streicher
#include <log.h>
int main(void) { zlog_rotate(); return 0; }

This work is completely based on my own, there is no intellectual
property of someone else in my source code.

Except for the big "zlog_rotate" there that you're building on,
provides all the functionality, and which must be understood to
understand what this programme does.

I do not build on anything. I wrote two lines of code. I even didn't
check whether it compiles.

*If* you are building a program out of that (compiling, linking with GPL
code), then the program should be under GPL, undoubtly.

But this is not what I did. I just wrote some source code, without using
external intellectual property. So, I am free to distribute that code
under any license I want. I did not use GPL code to write my example, so
I can't be bound to its conditions when I distribute my writing.

Best

Ole

[Andrew]

Hi Paul

I’ve watching this thread with interest, and I must admit I’m reluctant to get too involved, but there are a couple of things I thought it might be helpful (!) to point out.

Post by Paul Jakma

Post by Ole Streicher
My example
#include <log.h>
int main(void) { zlog_rotate(); return 0; }
is not an adaption of any GPL code. It is fully written by my
own.

It is written by you, and you have copyright in it (in some way, I
have the vague idea there can be complex legal details in that).
However, assuming this "zlog_rotate" function is non-trivial and a
copyrightable work, then the holder of the copyright in "zlog_rotate"
/also/ has copyright in your work. For your work is based upon the
"zlog_rotate" work - it /is/ an adaptation of it.
I know there are many programmers who can't get their head around that,
however I don't believe that's at all contraversial amongst lawyers.

This would only be true if the string of text “zlog_rotate” is itself copyrightable. And in all jurisdictions I’m aware of, it would fail that test.

Incorporating the functionality of a work by reference is something that lawyers have been doing for years. We will write building contracts incorporating JCT Minor works and financial contracts incorporating IFEMAs and ISDAs. JCTs, IFEMAs and ISDAs are all standard form contracts which are copyrighted works, but unless we copy any or all of the content of those standard works, then we are not required to pay any licensing fees for only referring to them and incorporating them by name.

There is an argument that the GPL overreaches copyright law, and says “if you incorporate a piece of GPLd work G into another work W, no matter how trivial that incorporation is, that other work must only be distributed under the GPL”. If that is true, then the distributing party may be in breach of its licence to work G, and may be at risk of having its licence to G terminated by its act of distributing work W, but the copyright owner of W will have no way of preventing the onward distribution of work W. There have been cases in the US which suggest that this sort of overreach is unacceptable (it’s essentially a way of trying to create new, more extensive copyright law by the back door), but I’m not a US lawyer, so can’t comment authoritatively.

If the GPL doesn’t overreach copyright law, then it’s fine to distribute W under whatever licence you want. Of course, this only applies to the source. If you distribute the object code, then you will have created a combined work (which Larry Rosen has argued, I believe, is collective work as you can still reverse engineer it to extract the two components, but that’s not an argument I’d like to rely on).

If, in order to write work W, you have to incorporate sufficient of work G (for example an interface definition) into it to make it work that some copyrightable part of G is incorporated, then this argument fails, but ONLY if the parts so copied are subject to the GPL. For example, imagine a program X uses plugins, and it has a published specification for the interface which is usable without licence (assuming either that the interface is not copyrightable, or there is an unrestricted licence) You write a piece of software to that specification, and release it under the GPL. Now it would be absurd to suggest that program X has to be released under the GPL, to comply with the licence of a piece of software which was written *after* it was written. Similarly, if I write another piece of software Y which uses your GPL plugin (thus replicating the plugin interface of program X), then there is no requirement on me to release my code under the GPL. I am copying X’s specification.

This does, of course, suggest a way of violating the spirit of the GPL by distributing non-GPL component X and component Y in source code as an aggregation, and then also sending over a script to the recipient which combines them. Since the combination occurs prior to distribution, the argument goes, then this is fine. There are a few counterarguments to this. The first is that there is some form of secondary infringement. I have difficulty with this argument: causing someone to do something which is perfectly legal for them to do seems to be a stretch. The second is more interesting, and that is that my causing the script to run on the recipients machine, the person sending the code somehow has control of the recipient’s machine, and is therefore for the period of time that the script is running, they are dong the combination, immediately following which the result is distributed, in violation of the GPL, to the recipient. Far fetched? Well, think about what would happen if the activity took place inside a VM running on the recipient’s machine to which the sender had root access, until the point at which the combination completed, and the sender granted root access to the recipient. The law doesn’t really have the tools to deal with these situations, as I discussed a couple of years ago in the Legal Devroom at FOSDEM. https://archive.fosdem.org/2016/schedule/event/triggering_copyleft/

Best


Andrew

Post by Paul Jakma

Post by Ole Streicher
Therefore, I don't need to respect the GPL to distribute it. The
same is true for the FRR code as far as I have seen it.

This is where you're at odds with the solicitors I have had advice from.

Unfortunately, solicitors don’t always give consistent advice...

Best



Andrew

Post by Paul Jakma

Post by Ole Streicher
Otherwise you must point to a certain code file and prove that it
contains code which is a modified copy of an GPLed file. Which you not
did yet.

I have given examples of files where the legal advice is that they are
derived works of the GPL code.
regards,
--
To provide weapons to a Spanish pickle.

[Ansgar Burchardt]

Post by Paul Jakma

Post by Ole Streicher
#include <log.h>
int main(void) { zlog_rotate(); return 0; }
is not an adaption of any GPL code. It is fully written by my
own.

It is written by you, and you have copyright in it (in some way, I
have the vague idea there can be complex legal details in that).
However, assuming this "zlog_rotate" function is non-trivial and a
copyrightable work, then the holder of the copyright in "zlog_rotate"
/also/ has copyright in your work. For your work is based upon the
"zlog_rotate" work - it /is/ an adaptation of it.
I know there are many programmers who can't get their head around
that, however I don't believe that's at all contraversial amongst
lawyers.

So any source code using OpenSSL is a derivative work of OpenSSL and the
terms of the OpenSSL license would apply? (Hah, no GPL with an
exception for linking OpenSSL will safe you now!)

Or any source code using the DirectX API is a derivative work of DirectX and
has to follow Microsoft terms for that? Even though it might just use
the alternative Vulkan implementation on Linux?

What about source code implementing an proprietary API? Would WINE be a
derivative work of Windows?

What about source code implementing an API described in a proprietary
document? Would it be a derivative work of said document?

I think the view that using an API in any way in source code makes a
work a derivative work of the API provider is not realistic; for
binaries it might be more complicated, but we aren't discussing that
here.

Ansgar

[Julian Andres Klode]

Post by Paul Jakma

Post by Ole Streicher
My example
#include <log.h>
int main(void) { zlog_rotate(); return 0; }
is not an adaption of any GPL code. It is fully written by my
own.

It is written by you, and you have copyright in it (in some way, I
have the vague idea there can be complex legal details in that).
However, assuming this "zlog_rotate" function is non-trivial and a
copyrightable work, then the holder of the copyright in "zlog_rotate"
/also/ has copyright in your work. For your work is based upon the
"zlog_rotate" work - it /is/ an adaptation of it.
I know there are many programmers who can't get their head around
that, however I don't believe that's at all contraversial amongst
lawyers.

Of course it is controversial, that was the whole point of the
Oracle vs Google trial. It was generally believed that API is not
copyrightable, for example, BSD had the same interfaces as UNIX,
but was not a derivative of UNIX; or Wine reimplements the Windows
APIs but is not a derivative of Windows.

Oracle challenged this in 2010, claiming that Google's reimplementation
of parts of Java is a derivative work of their Java API. The court unfortunately
agreed with this, despite all previous precedents, and despite this
causing severe issues for the field (as it prevents you from re-implementing
a proprietrary API not supported anymore by the vendor, for example, or
support for proprietrary file formats).

I'm not sure why you are supporting Oracle's position, but consider
the impact on the computing world of that position, and what trouble
it causes if it wins.

There is still some hope: The case is not closed - a second supreme
court petition was filed in January.

[Giacomo Tesio]

Post by Julian Andres Klode
I'm not sure why you are supporting Oracle's position, but consider
the impact on the computing world of that position, and what trouble
it causes if it wins.

I can't answer for Paul, and I really don't care about neither Oracle or Google.

But there is a huge difference between reimplementing a standard
interface like POSIX and depending on a creative work that is
original. Whenever a standard exists, anything that implement it, even
partially, is NOT subject to this issue.

And in the long run, throwing away the complexity of supporting old
proprietary formats that not even the original vendor actually support
anymore could improve the quality of the Free Software as a whole.

The WINE / ReactOS cases are unfortunate.

But in the long run, not being able to copy proprietary code might
greatly improve the innovation in Free Software while keeping such
innovation under Commons (with a strong copyleft, possibly with a
wider reach of AGPL), might invert the power dynamics between
independent innovative hackers and large corporations.
Don't forget that we are not in 1999 anymore.
Lots corporate code is "open source": OSS has become a fundamental
tool to gain market share and user trust.


On the other hand, if I donate original code to everybody, I don't
want it to be Embraced, Extended and Extinguished by any organization.


Informatics is still at a very early stage of its development.
As primitive as it is, most of proprietary software is crap and we all
know this despite trained to ignore its glitches "because worse is
better".

The future might be Free Software if no one could actually close it in any way.


Giacomo

[Ansgar]

Post by Giacomo Tesio

Post by Julian Andres Klode
I'm not sure why you are supporting Oracle's position, but consider
the impact on the computing world of that position, and what
trouble
it causes if it wins.

I can't answer for Paul, and I really don't care about neither Oracle or Google.
But there is a huge difference between reimplementing a standard
interface like POSIX and depending on a creative work that is
original. Whenever a standard exists, anything that implement it,
even partially, is NOT subject to this issue.

As far as I know POSIX isn't a new and original interface that was
designed in a clean room; it (in large parts) documents interfaces that
were available in proprietary operating systems.

So using POSIX interfaces would violate the original copyright on those
APIs (unless there is a license to allow using them).

Lots of free software also is very much inspired by proprietary works,
be they APIs, protocol or entire programs.

Ansgar

[Paul Tagliamonte]

Post by Ansgar
Lots of free software also is very much inspired by proprietary works,
be they APIs, protocol or entire programs.

http://docs.ceph.com/docs/mimic/radosgw/s3/

paultag

Post by Ansgar
Ansgar

[Steve Langasek]

Hi Paul,

Post by Ole Streicher
Those files do not use GPL code; they just refer to it. No line of that
code was originated in GPL licensed code.

Ah, you're in the "copyright only protects literal copying" camp, and you
don't acknowledge the concept of derived works.
There's little point discussing further with you, if so.

What is the point of this discussion, in general?

debian-legal is a public mailing list where individual Debian Developers
(and non-Debian Developers) opine on questions of licenses, with no legal
authority. Even if you manage to persuade some number of people here that
your position is correct, that doesn't translate to a change in Debian's
position on shipping the package in question.

You can file a severity: serious bug against the package and ask the Debian
FTP team to intervene; if they agree with you the package would be removed.

If you believe there is a license violation that needs to be addressed even
if the Debian ftp team don't agree with your and your lawyer's
interpretation of copyright law, then you should probably be having your
lawyer get in touch with Debian, and Debian's lawyers will review and
respond, and the matter will be adjudicated via the legal system - not via
an opt-in mailing list.

But as for the substance of your claim, what you are doing here is asserting
copyright on an interface. While there has been recent notable case law in
certain jurisdictions which wrongly supports the notion that interfaces
contain sufficient creativity to be copyrightable, that is an incredibly
toxic precedent to set in the Free Software world.

Copyright gives authors of works not just the right not to just control
literal copying, but also a controlling right in any adaptations of their
work (amongst other things). Whether you agree with this or not, various
variants of this concept are law in many countries around the world.

Coding to an interface is not "adaptation" of a copyrighted work. Your
interpretation of copyright law is inconsistent with how Debian has operated
for over 20 years, and I do not expect Debian to cede this position without
lawyers getting involved, or for Debian to be willing to distribute any of
your code, as part of frr or otherwise, at the end of the process.

[Giacomo Tesio]

Post by Steve Langasek
But as for the substance of your claim, what you are doing here is asserting
copyright on an interface. While there has been recent notable case law in
certain jurisdictions which wrongly supports the notion that interfaces
contain sufficient creativity to be copyrightable, that is an incredibly
toxic precedent to set in the Free Software world.

Technically, he is asserting that any text that use substantial
original words defined in another original copyrightable text is a
derivative work of such original text.

To be honest, the form of the text (in C, plain english, or
mechanically translated to an object form for mechanical consumption),
I'd say that it shouldn't change much.

All translations of a book are derivative work of the original, even
if they are ALSO copyright of the translators.

Since compilers are things and do not hold copyright, API or ABI
doesn't change much.



I agree that the course of action you suggest to Paul is correct, but
I'd really like if you might elaborate about your concerns about API
copyrightability.

I know that this is a widely minoritarian position, but I think that a
strong copyleft over innovative APIs might be very beneficial to Free
Software.

Most of commercial APIs are crap so we wouldn't lose much.
OTOH Free Software is strong enough to innovate and through a strong
enough copyleft, we might create a new and better stack that keep most
future software in the Commons, spreading knowledge and collaboration,
for the benefit of the whole Humanity.


So why do you think that this is a "toxic precedent"?


Giacomo

[Christian Kastner]

Post by Giacomo Tesio
Most of commercial APIs are crap so we wouldn't lose much.

You care confusing quality with popularity/success. POSIX has its own
share of crap interfaces, but they are prevalent.

Post by Giacomo Tesio
OTOH Free Software is strong enough to innovate and through a strong
enough copyleft, we might create a new and better stack that keep most
future software in the Commons, spreading knowledge and collaboration,
for the benefit of the whole Humanity.
So why do you think that this is a "toxic precedent"?

Because then you'd never be able to provide a compatible free software
alternative to *any* proprietary solution.

[Giacomo Tesio]

Post by Christian Kastner

Post by Giacomo Tesio
Most of commercial APIs are crap so we wouldn't lose much.

You care confusing quality with popularity/success. POSIX has its own
share of crap interfaces, but they are prevalent.

No, I know that crap is prevalent in our field.
Indeed I'm not much scared by the idea of throwing it all out with the windows
(pun intended :-D)

Post by Christian Kastner

Post by Giacomo Tesio
OTOH Free Software is strong enough to innovate and through a strong
enough copyleft, we might create a new and better stack that keep most
future software in the Commons, spreading knowledge and collaboration,
for the benefit of the whole Humanity.
So why do you think that this is a "toxic precedent"?

Because then you'd never be able to provide a compatible free software
alternative to *any* proprietary solution.

Correct.

We couldn't provide any COMPATIBLE alternative to proprietary
solutions (that do not implement standards).

But we could still provide BETTER alternatives!


But they couldn't provide any COMPATIBLE alternative to Free Software
solution either!


Given the amount of crap in legacy systems, this would resort into a
huge advantage for Free Software!


Giacomo

[Giacomo Tesio]

Post by Giacomo Tesio

Post by Christian Kastner

Post by Giacomo Tesio
So why do you think that this is a "toxic precedent"?

Because then you'd never be able to provide a compatible free software
alternative to *any* proprietary solution.

But they couldn't provide any COMPATIBLE alternative to Free Software
solution either!

Imagine for a moment if the Web was born under a similar legal framework.

Only Free Software browsers.
Only Free Software servers.
Only Free Software Web applications.
Only Free Software API.

You could ask to inspect the code that is executed for you by a SaaS
or move the whole application to a server under your physical control.

OTOH, SaaS providers would have a HUGE pressure to preserve their
customers' trust.


Now, you can see how Google is moving to replace HTTP with his own new kids.
So it IS still possible to change the status quo, simply because...
it's software! ;-)


Giacomo

[Giacomo Tesio]

Post by Giacomo Tesio
So why do you think that this is a "toxic precedent"?

No free software could run under Windows without proper Microsoft
licensing: Firefox, Libreoffice...
No free software could use or implement compatible Windows services,
either server or client, without proper Microsoft licensing: Samba,
rdesktop...

You are not looking at the whole picture. ;-)

Microsoft is distributing WSL.
Microsoft is distributing several Linux distros (which include
Firefox, Libreoffice...)
Microsoft is selling services based on Linux.
Microsoft even creating their own Linux distribution "Azure Sphere OS".

Europe taught Microsoft that they cannot abuse their dominant position.
Arguably other corporations need a recall on the topic too, despite
their OS being "open source". ;-)

That would make Linux and Windows ecosystems fully disjoint. This would
force me to use Windows to do the work I'm paid for and for which I've
been using Debian for 10 years.

Sorry but this is FUD.

Look at the whole picture.

Microsoft is not going to face European antitrust again.

OTOH, that would make the software patent problem fully irrelevant
because copyright would cover what currently is being enfonced by patent
licensing.

Indeed the current status is not free, despite the permissive licenses
and their rhetoric.


Giacomo

[David Lamparter]

Post by Giacomo Tesio
Technically, he is asserting that any text that use substantial
original words defined in another original copyrightable text is a
derivative work of such original text.

You can't copyright words. You probably can't even copyright a title
like "Harry Potter and the Sourcerer's Stone". You certainly can't
copyright the name "Harry Potter".

Copyright requires a creation of sufficient "height" of the work.
Neither a word nor a book title meets that requirement.

Literary characters _do_ meet the requirement since the character as a
whole is a complex creation. It has a backstory, attributes, flaws, -
that's what you can base a copyright claim against fan fiction on, if
you chose to do so. But if you put a character named "Harry Potter" in
a new novel that has nothing to do with JK Rowling's Potterverse, there
is no copyright issue.

There is however a trademark issue, at least the title is probably
trademarked (not sure if you can trademark the name alone.)

[Add.: apparently you can trademark the name -
https://register.dpma.de/DPMAregister/marke/register/300125666/DE ]

Post by Giacomo Tesio
To be honest, the form of the text (in C, plain english, or
mechanically translated to an object form for mechanical consumption),
I'd say that it shouldn't change much.

It changes by incorporating additional material. If a C file contains
no include statements, only the copyright of the source applies to the
object file. But creating an accumulative work is very much a legal
concept (in software as well as in art.)

Post by Giacomo Tesio
All translations of a book are derivative work of the original, even
if they are ALSO copyright of the translators.

Yes, translations of books are derivative. But a translation of a word,
or even a sentence, isn't. (Caveats apply - you can probably cram
enough content into a sentence to make it copyrightable. This boundary
is something that courts determine on a case-by-case basis.)

[...]

Post by Giacomo Tesio
I agree that the course of action you suggest to Paul is correct, but
I'd really like if you might elaborate about your concerns about API
copyrightability.

btw: the POSIX standards itself are copyrighted:
UNIX ® is a registered Trademark of The Open Group.
POSIX ® is a registered Trademark of The IEEE.
Copyright © 2001-2018 IEEE and The Open Group, All Rights Reserved

Just because it is a standard, that doesn't free you up from adhering to
their copyright. But as far as I'm concerned, implementing a standard
isn't derivative of the standard unless you start copying or deriving
actual content in your implementation.

There are actually legislations that have enshrined this in law, as a
reaction to Microsoft's marked position in the 90ies. They explicitly
specify that any parts of a system that are required for interoperation
with that system can be freely copied regardless of copyright or
license. Sometimes this also extends to reverse engineering.

(Take this as hearsay, I'm not a lawyer and I don't have time to double
check.)

Post by Giacomo Tesio
I know that this is a widely minoritarian position, but I think that a
strong copyleft over innovative APIs might be very beneficial to Free
Software.
Most of commercial APIs are crap so we wouldn't lose much.
OTOH Free Software is strong enough to innovate and through a strong
enough copyleft, we might create a new and better stack that keep most
future software in the Commons, spreading knowledge and collaboration,
for the benefit of the whole Humanity.
So why do you think that this is a "toxic precedent"?

I agree that this is a toxic precedent, because in your world we need to
reimplement everything from scratch at once.

This is, in my experience, neither how software development works, nor
is it doable. Essentially, your precedent would immediately shut down
most open source because it would no longer be able to mesh into the
existing world, however crappy it might be.

Sorry,


-David

[David Given]

[...]

Post by Ole Streicher

Post by Paul Jakma
Those files are derived works of the GPL code and must be distributed
according to the conditions of the GPL licence, if they are to be
distributed lawfully.

Those files do not use GPL code; they just refer to it. No line of that
code was originated in GPL licensed code.

I think what he's trying to argue is this:

- the BSD code has tight enough dependencies to the GPL code that it must
be considered a derived work, and therefore *because it's distributed* it's
implicitly licensed under the GPL. Therefore labelling it as BSD code is a
licensing violation (because it's really GPL).

His communication is very poor. However, he's not *necessarily* wrong. I
originally thought that Zebra was a library being accessed via its public
APIs, but it's not; it's a standalone program which doesn't have any public
APIs. So, FRR's use of it is dependent on internal implementation details.
So, yes, it's not beyond the bounds of possibility that FRR's BSD stuff
could be considered derived.

OTOH the bits of Zebra he pointed out to me are all standalone modules, and
FRR would be entirely within their rights to have pulled these out from the
original app and turned them into a GPL library, *with* public entry
points, and then ship that along with their code.

So... yeah, I dunno. The evidence he supplied wasn't particularly
convincing, but I can see where he's coming from.

[Paul Jakma]

Post by David Given
OTOH the bits of Zebra he pointed out to me are all standalone
modules,

There are further inter-dependencies between those modules. E.g,, things
like the API that provides the route-filtering relies upon the
event-handling system (lib/thread), etc.

You're welcome to try separating out the babeld/ and ldpd/ code that
depends on the GPL code, from the code that does not.

As I wrote before, I actually tried many years ago to do that with the
Quagga babeld port (now babeld/ in FRR), and I could only separate 3
sets of files (3 .c and their 3 corresponding .h).

But, have a go, and see how easy it is and how far you get.

(Also, at this stage, you may not even be able to fix the issue with
this approach anymore - consult a lawyer; but I did try to help them
avoid this mess, years ago).

Post by David Given
and FRR would be entirely within their rights to have pulled
these out from the original app and turned them into a GPL library,
*with* public entry points, and then ship that along with their code.

No, you can't just take GPL of code mine, libify it and say it's OK for
it be used in proprietary code, without my agreement.

Post by David Given
So... yeah, I dunno. The evidence he supplied wasn't particularly
convincing, but I can see where he's coming from.

Thanks.

regards,

[Paul Jakma]

Post by Paul Jakma
No, you can't just take GPL of code mine, libify it and say it's OK
for it be used in proprietary code, without my agreement.

Oh, and even if I myself have already put that GPL code in a library,
it's still not OK for you to say "You can use this with whatever code
you want, and ignore the GPL".

regards,

[David Given]

[...]

Post by Paul Jakma

Post by David Given
and FRR would be entirely within their rights to have pulled
these out from the original app and turned them into a GPL library,
*with* public entry points, and then ship that along with their code.

No, you can't just take GPL of code mine, libify it and say it's OK for
it be used in proprietary code, without my agreement.

That's not what I said.

- I *can* take your GPL code and turn it into a GPL library. That's what
the GPL is for. I don't even need to ask you about it.

- I *can* use this library in BSD code, and distribute both together as an
aggregate under the terms of the GPL --- because the BSD license conditions
are met by the GPL, so by distributing the whole under the terms of the GPL
I meet both sets of licensing terms, and so everything is fine.

- I *can't* use this library in closed source code, and distribute the
result as an aggregate --- because there is no license which can meet the
terms of the GPL *and* my closed source license.

- I *can* use this this library in closed source code, and distribute the
library and the closed source code *seperately* --- because they're not
being distributed together it's not an aggregation, and both sets of
licensing terms are being met independently.

- I *can't *modify your library, and distribute the modified version as
BSD, because the modifications are derived work, and therefore the result
is only distributable under the terms of the GPL.

What's under dispute here is whether FRR is an aggregation or a derivation.
And, TBH, the examples you've shown me are all pretty underwhelming ---
they're all standalone modules being used in a library context.

Your argument's plausible, but you need better evidence. Mostly what you're
saying now is too vague to be useful. You need actual files you can
actually point it that we can look at --- and I'm afraid you're the one
who's going to have to come up with this.

[Ole Streicher]

- I can't use this library in closed source code, and distribute the
result as an aggregate --- because there is no license which can meet
the terms of the GPL and my closed source license.
- I can use this this library in closed source code, and distribute
the library and the closed source code seperately --- because they're
not being distributed together it's not an aggregation, and both sets
of licensing terms are being met independently.

GPLv2, section 2 explicitly allows aggregation:

| In addition, mere aggregation of another work not based on the Program
| with the Program (or with a work based on the Program) on a volume of
| a storage or distribution medium does not bring the other work under
| the scope of this License.

Therefore, I would think that one *can* distribute both source codes
together, even when part of it is closed source.

Best

Ole

[Paul Jakma]

Post by Ole Streicher
| In addition, mere aggregation of another work not based on the Progra

How can this apply to a derived work, which is based on the GPL work?

regards,

[Ole Streicher]

Post by Paul Jakma

Post by Ole Streicher
| In addition, mere aggregation of another work not based on the Progra

How can this apply to a derived work, which is based on the GPL work?

The FRR code is not "derived work". It is not a modified copy of any GPL
code. Instead it aggregates the (changed? unchanged?) GPL code with code
that is written on its own. This code is not a modified copy of any GPL
code, therefore they can give any license to it.

"Modified copy" is the term which is used in GPL, and you should prove
that the code in question is a modified copy.

Again, I can put my mini-2-liner under any license, unaffected by the
GPL. Since it is not a modified copy of anything.

Best

Ole

[Paul Jakma]

Post by David Given
they're all standalone modules being used in a library context.

Derived works of GPL code must be licensed under the GPL too.

Whether that code has one kind of object file header or another
prepended to it is a low-level technical implementation detail which no
lawyer I've dealt with seems to think has much bearing on this.

regards,

[Paul Jakma]

Post by David Given
- I *can* take your GPL code and turn it into a GPL library. That's what
the GPL is for. I don't even need to ask you about it.

Agreed.

Post by David Given
- I *can* use this library in BSD code, and distribute both together
as an aggregate under the terms of the GPL --- because the BSD
license conditions are met by the GPL, so by distributing the whole
under the terms of the GPL I meet both sets of licensing terms, and
so everything is fine.

If by "use this library in BSD code" you mean modify and/or extend the
BSD code so it relied on the facilities of the GPL code, then you can
distribute my code under the GPL correct.

Those modified and extended portions are subject to the GPL, and can
only be distributed under the GPL - they can not be distributed under
the BSD licence (if that were possible, it would also be possible to
distribute it under proprietary licences).

Post by David Given
- I *can't* use this library in closed source code, and distribute the
result as an aggregate --- because there is no license which can meet the
terms of the GPL *and* my closed source license.

Agreed.

Post by David Given
- I *can* use this this library in closed source code, and distribute the
library and the closed source code *seperately* --- because they're not
being distributed together it's not an aggregation, and both sets of
licensing terms are being met independently.

Disagree.

Why would separate distribution affect derived work status? Nothing in
what I've heard from solicitors suggests that derived work status hinges
on whether the derived work has been distributed with the work it
derives from or not. ???

Post by David Given
- I *can't *modify your library, and distribute the modified version as
BSD, because the modifications are derived work, and therefore the result
is only distributable under the terms of the GPL.

Indeed. This is the same case as "use this library in BSD code", for me.
I see no way you can "use" a library without having adapted the code in
some way to introduce that "use", and those modifications are deriving
of the library.

regards,

[David Given]

[...]

Post by Paul Jakma

Post by David Given
- I *can* use this library in BSD code, and distribute both together
as an aggregate under the terms of the GPL --- because the BSD
license conditions are met by the GPL, so by distributing the whole
under the terms of the GPL I meet both sets of licensing terms, and
so everything is fine.

If by "use this library in BSD code" you mean modify and/or extend the
BSD code so it relied on the facilities of the GPL code, then you can
distribute my code under the GPL correct.

I got halfway through responding to this point-by-point until I realised
that you're assuming that all usage of someone else's API makes a derived
work --- everything you've said follows on logically from that.

Okay, here's a thought experiment. I'm writing a gawk script. I'm using the
GNU extensions, which only exist in the gawk version of the language. Is my
script a derived work of gawk or not? After all:

- the script is completely dependent on the gawk APIs (i.e. the published
language)
- the script relies on implementation details of gawk (i.e. the
non-standard extensions to the language)
- the script will not work on any other version of gawk
- the script requires gawk to be distributed along with it or it won't work

[Florian Weimer]

Post by Paul Jakma

Post by Roberto
On the other side, if I understood correctly, there are authors who
want to contribute their code under GPL exclusively, and they feel
that some of their changes got included into the bundled libraries
(and are significant enough to be covered by copyright), so those
libraries should be wrapped by the GPL as well.

1. There are GPL libraries (and associated support daemons), providing a
number of facilities.
2. There is BSD and MIT/X11 licensed code
3. People took the code of (2), and adapted that code - extensively and
explicitly - to make use of and rely upon the facilities of the code
of (1); facilities which were missing in the code of (2).
The people involved in (3) - Linux Foundation, Cumulus Networks, 6WIND,
Big Switch Networks, etc. - refuse to acknowledge the legal reality that
the code of (3) is covered by the GPL licence of the code of (2), and
refuse to honour the conditions required by the GPL - see David
Lamparter's mail.

Is there a Quagga or Zebra code base out there that is covered by
another license, and not the GPL?

Let's consider a different example why I think licensing GPL-dependent
code under a more permissive license makes sense. Suppose I write a
useful patch for Hotspot, a component of OpenJDK, which is licensed
under the GPL, version 2; exactly this version and no exception. I do
not wish to deal with hassles of the contributor agreement to OpenJDK,
so I release my patch under a HPND license. This covers two relevant
scenarios:

* Hotspot is relicensed under the GPL, version 3. My patch remains
usable. (I could have obtained the same result by using the GPL,
version 2, with some adjusted language that it is not in fact “at
your option”.)

* A recipient of my patch has obtained Hotspot under a license that is
different from the GPL, version 2. They can still apply my patch
and distribute Hotspot (if the terms of their alternative licensing
agreement permits this), as long they comply with the HPND
notification requirements.

Given these possibilities, I do not see a problem with releasing a
patch under HPND, even if the publicly available sources to which the
patch applies is available under a different (but compatible) license
only. (Let's not argue about patch context and the impact of
copyright on those, please.)

If I recall correctly, Zebra went proprietary at some point. Quagga
was started from the published GPL code base. The files you
identified mostly seem to date back to Zebra. Therefore, it is not
inconceivable that certain Quagga additions would be in the same
category as that hypothetical Hotspot patch (for the second reason:
the alternative licensing option for the baseline code).

Or put differently, why should someone who writes a Quagga extension
which happens to work with the proprietary Zebra code base, too, be
forced to license the extension in such a way that it cannot be used
with Zebra for legal reasons? That does not make any sense to me.

[Bradley M. Kuhn]

The respective original authors have expressed and reaffirmed their wishes
for the code to remain under a permissive license. . .. we have decided to
try and honour the original author's requests.

That's an odd request, since it contradicts the terms of the license
they offered the code under originally. In fact, it's quite typical for
projects to take non-copylefted code and bring it into a copylefted project
and make copylefted changes thereafter. This has been in GCC, Linux, and
many of the most famous copyleft projects in history. This is permitted and
encouraged by non-copyleft FOSS licenses.

Specifically, the original author's request, expressed through their choice
of a non-copyleft license, was that downstream should have permission to
relicense under nearly any sort of downstream licenses, including proprietary
ones, so it seems to me that the authors are being a bit unfair to your
copyleft project by making demands of you that they aren't (presumably)
making of proprietary combiners of the code (i.e., if they didn't want the
proprietary combiners to relicense under licenses other than theirs, they'd
have used copyleft in the first place themselves).

This is an example of a common trend I see: social pressure to keep
non-copylefted code under non-copyleft licenses, sometimes even escalating to
aggression (as the OpenBSD project did with Linux over wireless drivers),
while permitting and even encouraging licensors to incorporate the code
under proprietary licenses, which are much more restricted of copyleft.

P.S.: please Cc: me as I'm not subscribed to debian-legal.

Done.
--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/

[Florian Weimer]

Post by Bradley M. Kuhn

The respective original authors have expressed and reaffirmed their wishes
for the code to remain under a permissive license. . .. we have decided to
try and honour the original author's requests.

That's an odd request, since it contradicts the terms of the license
they offered the code under originally. In fact, it's quite typical for
projects to take non-copylefted code and bring it into a copylefted project
and make copylefted changes thereafter.

It is not always clear whether the changes are subject to the
surrounding project's license or the original (non-copyleft) license.

Post by Bradley M. Kuhn
Specifically, the original author's request, expressed through their
choice of a non-copyleft license, was that downstream should have
permission to relicense under nearly any sort of downstream
licenses, including proprietary ones, so it seems to me that the
authors are being a bit unfair to your copyleft project by making
demands of you that they aren't (presumably) making of proprietary
combiners of the code (i.e., if they didn't want the proprietary
combiners to relicense under licenses other than theirs, they'd have
used copyleft in the first place themselves).

The behavior becomes much more reasonable if you assume that a
proprietary variant of the code exists somewhere, and the authors hope
to merge back contributions into it, under the original non-copyleft
license.

[Giacomo Tesio]

Post by Bradley M. Kuhn
This is an example of a common trend I see: social pressure to keep
non-copylefted code under non-copyleft licenses, sometimes even escalating
to aggression (as the OpenBSD project did with Linux over wireless drivers),
while permitting and even encouraging licensors to incorporate the code
under proprietary licenses, which are much more restricted of copyleft.

Very well put. Thanks.

But there is an important difference here that make things even worse.

The code distributed under a non-copyleft license depends heavily on
copylefted one, so much that it's not possible to run (or even
compile) it without the pre-existing copylefted one (that includes C
headers that are not described by any standard).

So in a way OpenBSD's social pressure might be interpreted as an
attempt to keep a reciprocity of contribution (you got our code this
way, give back your change that same way) in a context where OpenBSD's
favourite license do not grant such reciprocity.
This is somewhat ironic, but it's not what is happening here.

Post by Bradley M. Kuhn
The behavior becomes much more reasonable if you assume that a
proprietary variant of the code exists somewhere, and the authors hope
to merge back contributions into it, under the original non-copyleft
license.

That's why I said they could (at most, but I guess Bradley can correct
me) double license the modifications, say as GPL and BSD or MIT.

Downstream, developers of a compatible proprietary variants might then
chose to terminate their own GPL license on both FRR and Quagga and
adapt those specific patches to that tool.
The cons of this is that they are not going to ever be able to
distribute or modify these projects without violating the authors'
copyright.

And tbh, I don't know if such voluntary termination of a copyleft
license can be done privately or should be publicly declared somehow.


Giacomo

[David Lamparter]

Post by Giacomo Tesio
The code distributed under a non-copyleft license depends heavily on
copylefted one, so much that it's not possible to run (or even
compile) it without the pre-existing copylefted one (that includes C
headers that are not described by any standard).

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.

While this is, legally, an open question (no court has ruled on it to my
knowledge), there are at least several observations that support our
viewpoint:

- as Florian brought up in his mail dated 19.3. 18:55, there is actually
a commercial variant of Zebra, sold as "ZebOS" by IPInfusion. As
weird as it may sound, a lot of the library facilities (especially the
CLI) are still mostly compatible. babeld could likely be made to work
with ZebOS with only a small effort. Isn't that a clear indication of
it not being derivative?

- the ongoing Oracle vs. Google lawsuit is looking at whether APIs can
even be copyrighted to begin with. If they couldn't, this would end
the entire discussion right there, but unfortunately courts said the
API itself can be copyrighted. They're now discussing fair use on
that (and Google has re-requested the USSC to look at it.) That said,
the OvG case is about Google copying the API itself, not making use of
it.

- the LGPL also makes some statements about this, specifically:

"When a program is linked with a library, whether statically or
using a shared library, the combination of the two is legally
speaking a combined work, a derivative of the original library. The
ordinary General Public License therefore permits such linking only
if the entire combination fits its criteria of freedom. The Lesser
General Public License permits more lax criteria for linking other
code with the library."

(this is from LGPL v2.1, which is easier to read since LGPL v3.0
cross-references GPL v3.0 for a lot of its "meat")

To me, it clearly seems that the authors of the license were working
with the assumption that the source code, using headers from a library
and containing function names from it, wouldn't be derivative of the
library. It explicitly says that the /combined work/ is derivative.

This also makes sense from another perspective: the LGPL does require
the library itself to remain under the terms of the LGPL. This is
worded like this:

""The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or
translated straightforwardly into another language. (Hereinafter,
translation is included without limitation in the term
"modification".)""

So if an application using a library were a derived work of the
library - the LGPL wouldn't even make sense to exist. Its terms would
apply to the application... and if the application falls under the
LGPL, that makes the license pointless. The LGPL text really
implies/assumes that a library can be used without being derivative of
it.

[...]

Post by Giacomo Tesio
That's why I said they could (at most, but I guess Bradley can correct
me) double license the modifications, say as GPL and BSD or MIT.

This doesn't really work. A dual license is an "or" construct, meaning
a consumer of the code can choose one of the licenses (and even drop the
other license completely.) If the code cannot be under the MIT license,
it cannot be under a dual GPL/MIT license either.

Cheers,


-David

[Giacomo Tesio]

Post by David Lamparter

Post by Giacomo Tesio
The code distributed under a non-copyleft license depends heavily on
copylefted one, so much that it's not possible to run (or even
compile) it without the pre-existing copylefted one (that includes C
headers that are not described by any standard).

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?

Can you remove the reference to libfrr without breaking the build?

If you couldn't have written the new code if libfrr did not existed in
the first place, that code is a derivative of libfrr.

Just like if I write a couple of new chapter for, say, "Harry Potter
and the Half-Blood Prince" it's a derivative work of it unless no
place, character or mechanics of it is present into my new chapter.

Post by David Lamparter
We (FRR) believe it isn't. That's why we think we can still distribute
babeld and ldpd under their permissive licenses.

And I think you are wrong for the reason mentioned above.

Obviously only a court might really state if you are right or not.
And IMHO, Paul could go down this path to get the termination of your
license recognised.

But frankly, I'd really prefer to see this matter settled friendly.

I think that having several collaborative forks of a code base that
experiment different paths is healthy for Free Software and should be
always encouraged.

So I hope FRR won't lose their ability to modify and distribute their own fork.

OTOH, Paul's complaints are well founded.
The GPL is reciprocal and requires derivative works to be licensed in
the same way.
Not doing so is a violation of it, and should either be fixed (as soon
as possible) or sanctioned, in the interest of the whole Free Software
community.

Post by David Lamparter
While this is, legally, an open question (no court has ruled on it to my
knowledge), there are at least several observations that support our
[...lot interesting stuff whose analysis would take us too offtopic...]
To me, it clearly seems that the authors of the license were working
with the assumption that the source code, using headers from a library
and containing function names from it, wouldn't be derivative of the
library. It explicitly says that the /combined work/ is derivative.

Yes, it say so.
But this doesn't EXCLUDE that something that is written after and
heavily depends on the library whose header are original copyrightable
work is derivative work too.

And I'd argue that it doesn't explicitly say so, because it's obvious,
while the combined work being derivative despite the parts combined
being INDEPENDENT different works might not be that obvious.

Post by David Lamparter
This also makes sense from another perspective: the LGPL does require
the library itself to remain under the terms of the LGPL. This is
""The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or
translated straightforwardly into another language. (Hereinafter,
translation is included without limitation in the term
"modification".)""
So if an application using a library were a derived work of the
library - the LGPL wouldn't even make sense to exist. Its terms would
apply to the application... and if the application falls under the
LGPL, that makes the license pointless. The LGPL text really
implies/assumes that a library can be used without being derivative of
it.

No.

LGPL say: your application IS a derivative or this library, but this
license let you modify and distribute such application under any
license, AS LONG AS you distribute any modification to this library
under LGPL.

Its purpose is to restrict the reach of the copyleft to the library
only, exactly because, by default, it would apply to the depending on
the library too.

Post by David Lamparter

Post by Giacomo Tesio
That's why I said they could (at most, but I guess Bradley can correct
me) double license the modifications, say as GPL and BSD or MIT.

This doesn't really work. A dual license is an "or" construct, meaning
a consumer of the code can choose one of the licenses (and even drop the
other license completely.) If the code cannot be under the MIT license,
it cannot be under a dual GPL/MIT license either.

Again, maybe a lawyer might correct me on this.

But I think that the GPL says that you have to distribute any derived
work as GPL.
It doesn't say that you have to distribute the derived work as GPL only.

Violating the GPL terms would terminate the license itself, but in
theory, if the copyright owner gave you a different license too and
you have a compatible codebase that is legally sound (unlikely, as it
should NOT use ANY GPL covered code your code depends upon, not even
the headers, but maybe possible if it provides completely different
interfaces), nothing prevent you to use such different license to
adapt and merge the derivative work to it.

It goes without saying you would lose any grant on the code covered by GPL.


But, to my knowledge, the resulting work would still be legally distributable.


Giacomo

[Giacomo Tesio]

Post by Giacomo Tesio
But I think that the GPL says that you have to distribute any derived
work as GPL.
It doesn't say that you have to distribute the derived work as GPL only.

Badly expressed sorry.

I mean, if the derived work contains GPL-only code, it must be
distributed as GPL only.

What I mean that a copyright holder of a new piece of code (eg a new C
file) that is a derivative of GPL only code, might decide to
distribute the new C file under GPL and MIT.

The whole application linking the GPL only code AND the "GPL and MIT"
one would be GPL-only.

And to use the MIT license of the new C file, anyone would have to
renounce to the GPL grants on the whole application and all of it's
dependencies (as he would be violating the GPL license).


But while this is a very risky approach I woudn't suggest to anyone (I
would not renounce to tons of GPL code for few C files), it looks
legally sound (from my developer perspective, obviously! :-D).


Giacomo

[David Lamparter]

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 :)

Post by David Lamparter
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.)

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

[David Lamparter]

Post by Bradley M. Kuhn

The respective original authors have expressed and reaffirmed their wishes
for the code to remain under a permissive license. . .. we have decided to
try and honour the original author's requests.

That's an odd request, since it contradicts the terms of the license
they offered the code under originally.

I've probably been a bit unclear here. The request wasn't about the
code; they understand perfectly well that people can take their code and
pretty much do most things with it.

This was about them continuing to invest time into the code. It was
them who ported the code to make use of the Quagga/FRR infrastructure,
and they intended to continue maintaining, updating, and enhancing the
code inside Quagga/FRR.

[...]

Post by Bradley M. Kuhn
so it seems to me that the authors are being a bit unfair to your
copyleft project by making demands of you that they aren't
(presumably) making of proprietary combiners of the code (i.e., if
they didn't want the proprietary combiners to relicense under
licenses other than theirs, they'd have used copyleft in the first
place themselves).

They're happy if someone proprietary takes up their code, but they won't
give /them/ any support. They would've been happy to work with us very
closely, but they do insist that their ongoing work is kept under the
license they have chosen (and which they have their reasons for.)

By relicensing their code to GPL, Quagga had essentially shunted itself
down to the position of any random proprietary relicensor.

Post by Bradley M. Kuhn
This is an example of a common trend I see: social pressure to keep
non-copylefted code under non-copyleft licenses, sometimes even escalating to
aggression (as the OpenBSD project did with Linux over wireless drivers),
while permitting and even encouraging licensors to incorporate the code
under proprietary licenses, which are much more restricted of copyleft.

FWIW, in this case the OpenBSD people (where ldpd was taken from) were
more relaxed. But since we're having the discussion anyway for babeld
we might as well keep ldpd under its permissive license too.

Post by Bradley M. Kuhn

P.S.: please Cc: me as I'm not subscribed to debian-legal.

Done.

Thanks, you're the first person on this thread to do so :)

-David

[Giacomo Tesio]

Post by David Lamparter
By relicensing their code to GPL, Quagga had essentially shunted itself
down to the position of any random proprietary relicensor.

I guess you mean that Quagga renounced to further contribution from
these people.

But the point is that Quagga is clearly abiding to the GPL, while FRR
compliance is... arguable.

While they are distributing the whole as GPL (which is correct) they
are actively stating that people can take a part of it that can only
be used as GPL and use it under a different license, while whoever do
so automatically terminates their own license on the whole FRR.


I think it's an interesting corner case.

I guess that if FRR writes a LICENSE.notice that say: "whatever the
files license header says, every single file of this code must be
treated as GPL", they would strengthen their own position without
violating the letter of their contributor request.

It goes without saying that adding a GPL header to those files that
need it would be totally equivalent and more fool-proof.


Giacomo

[Ole Streicher]

Post by Giacomo Tesio
While they are distributing the whole as GPL (which is correct) they
are actively stating that people can take a part of it that can only
be used as GPL and use it under a different license, while whoever do
so automatically terminates their own license on the whole FRR.

A downstream could remove the GPL dependencies (for example by replacing
it with a [dummy] re-implementation, or by removing any references) and
legally redistribute the result under a non-GPL license.

The current construct allows this, and this seems to be the intention of
the copyright owners of the questioned code. You may not like it, but
since the code writers do not derived from GPL code when they wroteg
their source (the GPL code is only used when it is compiled/linked),
they are free to do so.

Best

Ole

[Paul Jakma]

Post by Ole Streicher
A downstream could remove the GPL dependencies (for example by
replacing it with a [dummy] re-implementation, or by removing any
references) and legally redistribute the result under a non-GPL
license.

I advised the people, who are now FRR, that this would be one way
forward, *many years* ago - before this mess was in full bloom. It would
have taken time, but it would have been possible (I'd not have spent my
time doing this for free or on a low-wage though).

They rejected taking this approach.

Whether it is possible for FRR to /now/ try to re-implement the GPL
portions and get out of their legal mess, I would want to take advice
on. Even if they did so, it would not excuse them from the years of
infringement they have already carried out, which remains ongoing.

regards,

[Ole Streicher]

Post by Paul Jakma

Post by Ole Streicher
A downstream could remove the GPL dependencies (for example by
replacing it with a [dummy] re-implementation, or by removing any
references) and legally redistribute the result under a non-GPL
license.

I advised the people, who are now FRR, that this would be one way
forward, *many years* ago - before this mess was in full bloom. It
would have taken time, but it would have been possible (I'd not have
spent my time doing this for free or on a low-wage though).
They rejected taking this approach.

They don't need to do that themself, but they may want to keep that path
open for downstream. And so their license allows that.

Best

Ole

[Paul Jakma]

Post by Ole Streicher
They don't need to do that themself, but they may want to keep that
path open for downstream. And so their license allows that.

Their licence on their portion of the work, perhaps.

However, the work *also* requires a licence from the copyright holders
of the GPL licence they have based their work on, to be distributed or
used, as required by copyright law (whether you like that aspect of
copyright or not). They have deliberately rejected the GPL licence that
was on offer to them, ignored the conditions required by the GPL, and
distributed the code anyway.

As a result, any GPL licence available to them terminated, and no
further offer of a GPL licence is available to them, at this time,
unless this matter is resolved to my satisfaction.

You simply can not obtain their code (the code at issue) from them (or
anyone) under the GPL, therefore /you/ can not distribute or use it
under the GPL either.

And this is not about some concern for some (MIT/X11, BSD) free software
authors - they've fought this tooth and nail for their own commercial
reasons: to try strip copyleft from GPL software they do not have rights
to, for their own financial benefit.

regards,

[Paul Jakma]

You cannot terminate GPL granted to someone without a violation. There
clearly is no violation in the case you’re describing. Your legal
advice is invalid.

I have legal advice, two independent sets, from qualified solicitors
that there is a violation.

You're a software engineer.

regards,

[Andrej Shadura]

Post by Paul Jakma

You cannot terminate GPL granted to someone without a violation. There
clearly is no violation in the case you’re describing. Your legal
advice is invalid.

I have legal advice, two independent sets, from qualified solicitors
that there is a violation.

Apparently they’re not qualified in software licenses and copyrights.
Sorry I have to say that.

[Andrej Shadura]

Post by Andrej Shadura
Apparently they’re not qualified in software licenses and copyrights.
Sorry I have to say that.

You're a software engineer, with no legal qualifications or experience
listed in your LinkedIn. They are qualified, practicing solicitors.

I do not have a LinkedIn account.

If all you're going to do is inject reason-free arguments to your own
authority, then I'll stick with their authority.

Reasoned argument have already been given to you multiple times by
many people, which you have chosen to ignore.

[Andrej Shadura]

Post by Paul Jakma
As a result, any GPL licence available to them terminated, and no
further offer of a GPL licence is available to them, at this time,
unless this matter is resolved to my satisfaction.

You cannot terminate GPL granted to someone without a violation. There
clearly is no violation in the case you’re describing. Your legal
advice is invalid.

[Giacomo Tesio]

Post by Ole Streicher

Post by Giacomo Tesio
While they are distributing the whole as GPL (which is correct) they
are actively stating that people can take a part of it that can only
be used as GPL and use it under a different license, while whoever do
so automatically terminates their own license on the whole FRR.

A downstream could remove the GPL dependencies (for example by replacing
it with a [dummy] re-implementation, or by removing any references) and
legally redistribute the result under a non-GPL license.

As things stands now, anyone using that code would violate the GPL license.

To gain that effect, I think your only solution is to double license
your patches as GPL and whatever license you prefer.
The custom license would only apply to your contributions, not to the
whole application but to get advantage of it a downstream would have
to terminate all GPL grants on all code that your contributions
depends upon.

Post by Ole Streicher
The current construct allows this, and this seems to be the intention of
the copyright owners of the questioned code.

No.

The current construct is a violation of the GPL term as that code is
derivative of GPL code for all intents and purposes. So much that it
cannot even compile without the GPL code.

Post by Ole Streicher
You may not like it, but
their source (the GPL code is only used when it is compiled/linked),
they are free to do so.

It's not what I like that matter.

But I think your interpretation is very arguable.

If the new code depends on GPL headers, call GPL functions and use GPL
data structures that are original copyrightable code, it is a
derivative work.

Much like if I write an original novel containing the characters and
places of Harry Potter, it's a derivative work of Rowling's one.
And I guess that I couldn't print and sell it without paying right to her.


Giacomo

[Ole Streicher]

Post by Giacomo Tesio
The current construct is a violation of the GPL term as that code is
derivative of GPL code for all intents and purposes. So much that it
cannot even compile without the GPL code.

For the license of source code, it is not required that it compiles.

And, taking out a portion of the code (a single algorithm or so) that
does not depend on GPL code and to re-use it elsewehere is a normal and
intended use for an open source program. It is one of the goals of
having a program open source.

And if the code is a modified copy (this is what the GPL actually
protects), you should prove that: show the code in question, show the
original (GPL) code and show how it was modified.

Best

Ole

[Giacomo Tesio]

Hi,

Post by Giacomo Tesio
The current construct is a violation of the GPL term as that code is
derivative of GPL code for all intents and purposes. So much that it
cannot even compile without the GPL code.

I don't understand what does this matter. Copyright apply to thing
independently of whether they compile or not. [...]

Harry Potter is not Pulcinella.
Hermion is not Colombina.

If you use these names you do not borrow from Commons, from cultural
archetypes and characters known to the public, but to specific Rowling
creations.

Arguing that your work is not derivative of Rowling one would sound
ridiculous to any judge.

This doesn't rule out your fandom by itself, but it IS a derivative work.

Law might permit it or not, Rowling might tolerate it or not, but it
IS evidently a derivative work. Just like if you take the Rowling book
and want to write the script of a Hollywood film about the same
history, you need her permission


How this relates to compilation?

If the GPL header at
https://github.com/FRRouting/frr/blob/master/lib/command.h is required
by https://github.com/FRRouting/frr/blob/master/babeld/babel_interface.c
it means that it depends on its text, whose copyright holder gave you
the right to use according to the GPL.

It's exactly like using Harry Potter into your own fandom porn novel.
Rowling might have something to object. ;-)

Since you can't remove, say, INTERFACE_NODE from its
babel_interface.c, and you got INTERFACE_NODE as GPL in command.h,
babel_interface.c is a derivative of command.h and thus has to be
released under GPL.

So this example really convinces me that FRR people are doing right, and
there is no reason for Debian to change anything there.

Well... I hope to have clarified the misunderstanding, now. ;-)


Giacomo

[Christian Kastner]

Post by Giacomo Tesio
How this relates to compilation?

It doesn't. Nobody is disputing that the compiled result is GPL.

The question at hand is the licensing of the source. These are two
separate issues.

Post by Giacomo Tesio
If the GPL header at
https://github.com/FRRouting/frr/blob/master/lib/command.h is required
by https://github.com/FRRouting/frr/blob/master/babeld/babel_interface.c

It's not required. I can download and read the babel_interface.c
source, which itself is already a copyrightable work, just fine.

The compiler requires *a* command.h to compile babel_interface.c into
a binary result, but this command.h could theoretically be provided by
another implementation, licensed under different terms.

Hence why Steve wrote that this amounts to "[...] asserting copyright
on an interface."

[Giacomo Tesio]

Post by Christian Kastner

Post by Giacomo Tesio
How this relates to compilation?

It doesn't. Nobody is disputing that the compiled result is GPL.
The question at hand is the licensing of the source. These are two
separate issues.

Sure, I was talking exactly about the licensing of the derived source.

Post by Christian Kastner

Post by Giacomo Tesio
If the GPL header at
https://github.com/FRRouting/frr/blob/master/lib/command.h is required
by https://github.com/FRRouting/frr/blob/master/babeld/babel_interface.c

It's not required. I can download and read the babel_interface.c
source, which itself is already a copyrightable work, just fine.
The compiler requires *a* command.h to compile babel_interface.c into
a binary result, but this command.h could theoretically be provided by
another implementation, licensed under different terms.

Another implementation that uses all of the same texts invented by the
command.h authors and licensed under GPL.

What you say is: I could replace the "Harry Potter and the Sorcerer's
Stone" with another novel under the same name "Harry Potter and the
Sorcerer's Stone" and with the same characters (data structures,
enums...) and places (functions, macros...) AND and a compatible plot
that wouldn't completely change the meaning of the following Rowling's
books WITHOUT complying with Rowling copyright.


I think you are a bit... confused if you think so. :-)

command.h is copyrightable text in itself: it contains macro, data
structures, enums and so on that have been released under GPL.

babel_interface.c is another copyrightable text, but it uses the text
of command.h and could not even exist if command.h didn't existed in
the first place.
Thus babel_interface.c IS a derivative work of command.h: because it
came later and refers heavily to the characters and places provided by
command.h.

babel_interface.c's authors hold the copyright on their own code, but
they received the right to build a derivative work of comand.h's text
under GPL, so they have to abide to the GPL.

Post by Christian Kastner
These requirements apply to the modified work as a whole.
IF identifiable SECTIONS of that work ARE NOT DERIVED
FROM THE PROGRAM, AND CAN BE REASONABLY
CONSIDERED INDEPENDENT AND SEPARATE WORKS
IN THEMSELVES, then this License, and its terms, do not
apply to those sections when you distribute them as separate
works.

You don't need a programmer to find the text of command.h into
babel_interface.c thus babel_interface cannot be reasonably considered
independent and separate work from command.h.

As such, it can only be distributed under GPLv2.


Q.E.D. ;-)

Post by Christian Kastner
Hence why Steve wrote that this amounts to "[...] asserting copyright
on an interface."

As I said, I'm not sure that asserting copyright on an interface is
something that would hurt free software.

But in this case, this looks as FUD.

Those file are not independent section of FRR, they are derivative of
GPL code and thus distributing them code under a different license is
a violation of GPL terms that cause instant and irrevocable
termination.

Paul might need a court to get this termination enforced.
But you just need to read the license and the code to see the violation.


Giacomo

[Paul Jakma]

Post by Giacomo Tesio
What you say is: I could replace the "Harry Potter and the Sorcerer's
Stone" with another novel under the same name "Harry Potter and the
Sorcerer's Stone" and with the same characters (data structures,
enums...) and places (functions, macros...) AND and a compatible plot
that wouldn't completely change the meaning of the following Rowling's
books WITHOUT complying with Rowling copyright.

The structure and the plot of a (non-trivial) novel is subject to
copyright. Similarly, the architecture or structure of a computer
programme may be subject to copyright (in England, and places that may
pay some heed to reasoning in judgements there; e.g, Ibcos .. v Barclays
1994). Copying these can infringe copyright - without /any/ literal
copying, without any explicit referencing.

regards,

[Paul Jakma]

Post by Giacomo Tesio
It goes without saying that adding a GPL header to those files that
need it would be totally equivalent and more fool-proof.

If that had been done at the outset...

After X years of not doing so, denying the applicability of the GPL to
files which are explicitly dependent on GPL code for function and
comprehension, refusing to implement conditions required by the GPL, and
organising a corner-of-industry attack on the career and employment of
one of the GPL copyright holders who objected (and objected in helpful
ways, providing constructive ways forward repeatedly): Just adding a
header will no longer solve this.

Also, if 3rd parties were to do this, outside of a wider agreement with
copyright holders that would resolve all this, it would likely just
aggravate the situation further.

regards,

[Giacomo Tesio]

Post by Paul Jakma

Post by Giacomo Tesio
It goes without saying that adding a GPL header to those files that
need it would be totally equivalent and more fool-proof.

After X years of not doing so, denying the applicability of the GPL to
files which are explicitly dependent on GPL code for function and
comprehension, refusing to implement conditions required by the GPL, and
organising a corner-of-industry attack on the career and employment of
one of the GPL copyright holders who objected (and objected in helpful
ways, providing constructive ways forward repeatedly): Just adding a
header will no longer solve this.

While I understand your frustration and agree with your overall
interpretation of the issue, I think that this can only be established
in a court.

Given the dimension and power of the counter parts you cite, this is
going to be a steep road.

When something similar happened to me (see
https://medium.com/@giacomo_59737/what-i-wish-i-knew-before-contributing-to-open-source-dd63acd20696
for details), I decided to build enough evidences that they violated
my copyright to protect my codebase, but to not go to fight in court
despite the evidence (IMO) of the termination of their GPL license on
their own codebase.

That's for two reasons.
First of the counterparts was going to be Google and another would
have been SFC.
But more importantly, I didn't really want to hurt or risk to end
Harvey development, as an alternative exploration of the Plan 9
legacy. As I said, the more forks, the better: more roads explored,
more knowledge gain for the whole humanity.

Here I suggest you all to find a friendly solution anyway for the same reason.

Post by Paul Jakma
Also, if 3rd parties were to do this, outside of a wider agreement with
copyright holders that would resolve all this, it would likely just
aggravate the situation further.

Sorry, but I don't think so.

If that code is GPL (as you say, and as I agree), adding a GPL header
to it doesn't aggravate anything. It would just prevent people to
violate the GPL and terminate their own grants on the whole GPL
projects it derives by using it under a different license.


Giacomo

[Paul Jakma]

Post by Giacomo Tesio
Here I suggest you all to find a friendly solution anyway for the same reason.

I tried for years to find friendly solutions. Many of the things others
have suggested in this thread I already suggested/explored years and
years ago with the people who are now FRR.

If you or anyone else wants to help find a solution, you have my email.

Post by Giacomo Tesio

Post by Paul Jakma
Also, if 3rd parties were to do this, outside of a wider agreement with
copyright holders that would resolve all this, it would likely just
aggravate the situation further.

Sorry, but I don't think so.

You can seek your advice on that, and I'll take my own.

I would not consider that a solution, and not helpful or friendly.

regards,