Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
On Thu, 21 Mar 2019, Giacomo Tesio wrote: 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 | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Boob's Law: You always find something in the last place you look.
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019, Ole Streicher wrote:
Paul Jakma writes:
On Wed, 20 Mar 2019, Ole Streicher wrote:
#include
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,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
"The great question... which I have not been able to answer... is, `What does
woman want?'"
-- Sigmund Freud
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019, Ole Streicher wrote:
My example
#include
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.
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.
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,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Armadillo:
To provide weapons to a Spanish pickle.
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019, Ole Streicher wrote: GPLv2, section 2 explicitly allows aggregation: | 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: The public is an old woman. Let her maunder and mumble. -- Thomas Carlyle
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019, David Given wrote: 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 | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: But what can you do with it? -- ubiquitous cry from Linux-user partner
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019, David Given wrote: - 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. - 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). - 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. - 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. ??? - 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: E Pluribus Unix
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
On Wed, 20 Mar 2019, Andrej Shadura wrote: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Why are you so hard to ignore?
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
On Wed, 20 Mar 2019, Giacomo Tesio wrote: 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. 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: The truth about a man lies first and foremost in what he hides. -- Andre Malraux
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
On Wed, 20 Mar 2019, Ole Streicher wrote: 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 | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019, Paul Jakma wrote: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: serendipity, n.: The process by which human knowledge is advanced.
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019, David Given wrote: 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). 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. 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 | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Excusing bad programming is a shooting offence, no matter _what_ the circumstances. -- Linus Torvalds, to the linux-kernel list
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019, Ole Streicher wrote: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Interference between the keyboard and the chair.
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
On Wed, 20 Mar 2019, Ole Streicher wrote: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Exercise caution in your daily affairs.
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019, Ole Streicher wrote: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Al didn't smile for forty years. You've got to admire a man like that. -- from "Mary Hartman, Mary Hartman"
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
On Wed, 20 Mar 2019, Giacomo Tesio wrote: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Mencken and Nathan's Second Law of The Average American: All the postmasters in small towns read all the postcards.
Re: FRR package in Debian violates the GPL licence
On Tue, 19 Mar 2019, Ole Streicher wrote: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: If Nvidia would like to pay me as much as Microsoft is paid for driver certification then I might be able to find the time - Alan Cox on linux-kernel
Re: FRR package in Debian violates the GPL licence
On Tue, 19 Mar 2019, Ole Streicher wrote: Paul Jakma writes: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: People will buy anything that's one to a customer.
Re: FRR package in Debian violates the GPL licence
Correction: On Tue, 19 Mar 2019, Paul Jakma wrote: On Tue, 19 Mar 2019, Roberto wrote: 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 s/of (2)/of (1)/ copyright holders objected to what the people of (3) were doing. regards, regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: There isn't any problem
Re: FRR package in Debian violates the GPL licence
On Tue, 19 Mar 2019, Roberto wrote: 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 | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: The typical page layout program is nothing more than an electronic light table for cutting and pasting documents.
Re: FRR package in Debian violates the GPL licence
On Mon, 18 Mar 2019, Vincent Bernat wrote: 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. 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. 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Someone is broadcasting pigmy packets and the router dosn't know how to deal with them.
Re: FRR package in Debian violates the GPL licence
On Mon, 18 Mar 2019, Thorsten Alteholz wrote: [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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: I have a better idea: force CONFIG_DEBUG_* if CONFIG_DEVFS_FS had been set _and_ taint the kernel with new flag - Known_Crap - Al Viro on irc
Re: FRR package in Debian violates the GPL licence
On Mon, 18 Mar 2019, Giovanni Mascellani wrote: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Everyone talks about apathy, but no one does anything about it.
Re: FRR package in Debian violates the GPL licence
On Mon, 18 Mar 2019, David Given wrote: 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 | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Cohen's Law: There is no bottom to worse.
Re: FRR package in Debian violates the GPL licence
On Mon, 18 Mar 2019, David Given wrote:
On Mon, 18 Mar 2019 at 11:10 Paul Jakma wrote:
[...]
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,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
This fortune is encrypted -- get your decoder rings ready!
Re: FRR package in Debian violates the GPL licence
On Sun, 17 Mar 2019, Giacomo wrote: Hi Paul, a question: 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Don't hit the keys so hard, it hurts.
Re: FRR package in Debian violates the GPL licence
On Sat, 16 Mar 2019, Don Armstrong wrote: 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). 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 | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Executive ability is deciding quickly and getting somebody else to do the work. -- John G. Pollard
Re: FRR package in Debian violates the GPL licence
On Sat, 16 Mar 2019, Don Armstrong wrote: Debian does, in /usr/share/doc/frr/copyright. That is not one of the files at issue. 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. 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: 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. 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). 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. 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Tuesday After Lunch is the cosmic time of the week.
Re: FRR package in Debian violates the GPL licence
On Sat, 16 Mar 2019, Don Armstrong wrote: On Sat, 16 Mar 2019, Paul Jakma wrote: 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. 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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Death before dishonor. But neither before breakfast.
FRR package in Debian violates the GPL licence
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, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: "What I've done, of course, is total garbage." -- R. Willard, Pure Math 430a
Re: Hacking License
On Tue, 11 Dec 2018, Paul Jakma wrote: Much easier would be a licence where all you had to show was that the software was passed on, and that that act on its own was sufficient to trigger the general source distribution requirement (modulo "desert island", etc., which pretty obviously do not apply to the general corporate abusers). To clarify: The abusive cases are far from the grey lines, so there is little need to worry about /exactly/ where they lie - and ultimately that comes down to a judge. The abusive cases are exploiting grey lines in the /current/ copyleft licences. We can move the grey lines so those cases are much further from the grey lines, by making public source distribution a requirement, upon distribution - modulo "desert island" and "dissident" escape clauses. I want to have a copyleft licence available that does that, for next time I want to distribute code under copyleft terms. The Hacking licence proposed is intriguing, but doesn't quite do that for me (along with some other issues), as it stands, AFAICT. regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: The goal of science is to build better mousetraps. The goal of nature is to build better mice.
Re: Hacking License
On Tue, 11 Dec 2018, Eloi Notario wrote: Furthermore, these patches will be protected by the GPLv3 and even if publicly available Sencha will be unable to sell them, Probably you know this, and you meant "sell them exclusively or somesuch", but just to note: Nothing in the GPL prevents one from selling GPL source code. ;) regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Life is divided into the horrible and the miserable. -- Woody Allen, "Annie Hall"
Re: Hacking License
On Tue, 11 Dec 2018, Giacomo Tesio wrote: On Tue, 11 Dec 2018 at 13:06, Paul Jakma wrote: On Tue, 11 Dec 2018, Giacomo Tesio wrote: Unless there is some really compelling reason the modifier can not make their changes available (desert island, dissident), why not just require they make the changes available - given how easy it is to distribute software these days? This is not a binary state, either easy to distribute or impossible to. The world is large and the bandwidth you assume is not cheap or easily available to everyone. That may be true, but there may come a point where a line must be drawn. Either the distributor does have sufficient Internet access to not meet some "desert island" clause, or they do not. Either there is sufficient risk to meet some "dissident" clause, or there is not. The world may not be binary, but in the event of a dispute sufficient to take the matter to court, a judge will draw that line, according to the context, in terms of the parties involved (not the world). (This is also why it is important to use terms that the legal world prefers and has already reasoned about, rather than inventing your own). If someone can download copies of software I have made available, and if they are able to distribute their modifications to others using the Internet, then they are going to have a hard-time arguing that they could not also upload the software to, say, either GitHub, or else my instance of gogs with free hosting for modified versions of said software (specifically there to facilitate that licence requirement). The corporate abusers I have in mind are very clearly not on a desert island, very clearly are active on the Internet, very clearly are fully capable of making their modifications available to all. That's why the Hacking License give right upstream. In the moment an abuser abuse the license, all his rights are terminated. The GPL also terminates. The GPLv2 has very strong termination conditions even. That's not what happens though, the abuser finds a loophole, to carry out their abuse (not giving back) in a way that can be argued to not violate the licence. Making available != getting integrated upstream. This is an oversimplification: by making available a severe zero-day fix that would likely to get lost among the thousands of "newly available" patches of the week, you might set up a blame campaign on the upstream hackers that are "unable to live up to their success". Free Software is a gift. I want it to remain a gift. As such it cannot become a burden on those who donate. I don't see how it could be a burden, if one is openly distributing modified versions of some copylefted work on an ongoing basis, to also be required to upload a copy to any of a number of free open-source source code hosting sites. AGPLv3 also poses a condition to the execution: beyond the wording, if you make a covered work available across a network (a use) you have to make the sources available to the users. The Hacking License is simpler: as a condition to the all the grants provided, you should make the source available to any User (as defined in the License itself). The corporate abusers I have in mind would be able to fulfill that condition. And I'm back to square one, with the same problem I have with the GPL. The Users have a disincentive to pass the source on, through side-contracts. And I'm in the same position as before with the GPLv2: The question of whether those side-contracts are at odds with the licence, or whether they are orthogonal and wholly separate things, does not have an obvious answer. Much easier would be a licence where all you had to show was that the software was passed on, and that that act on its own was sufficient to trigger the general source distribution requirement (modulo "desert island", etc., which pretty obviously do not apply to the general corporate abusers). Same for your grampa. When it stop being a personal hack and you have to publish the patch somehow? I don't know. There is some line though, and - if it comes down to it - a judge can draw that line. Just as the corporate abusers are obviously not on a desert island, these abusive cases generally do not involve people distributing a hack to their granda via SSH access. The abusive cases are far from the grey lines, so there is little need to worry about /exactly/ where they lie - and ultimately that comes down to a judge. Despite its evidence, may people cannot see the parallel between writing in Ancient Egypt and information technology today. So they tend to discard issues that will arise when programming will be easy and diffused as it's writing today. The legal system will find a way of deciding these matters though, where people care enough to bring them to a court. No, the modifier must make the modifications available only to their Users.
Re: Hacking License
On Tue, 11 Dec 2018, Giacomo Tesio wrote: On Tue, 11 Dec 2018 at 12:22, Paul Jakma wrote: Personally, I want a copyleft for the 'gitlab/github/gogs' era: Source must be made available, unless you're on a desert island or there is a credibly physical risk of imprisonment or harm to individuals by disclosing their identity. The point is, made available to whom? To anyone. Unless there is some really compelling reason the modifier can not make their changes available (desert island, dissident), why not just require they make the changes available - given how easy it is to distribute software these days? The more options are given for not distributing modifications widely, the more opportunity there is for abusers to find loop-holes. To the users? Sure. Upstream? In a world where people happily hack their own software, this might open a can of worms upstream and downstream: - it would impose a review process (and infrastructure) for patches that would slow down development Making available != getting integrated upstream. - it would disincentive hack for personal purpose for the burden to prepare a 3rd party readable patch No. Copyleft usually only regulates and imposes conditions upon distribution (so long as the licence is adhered to generally). The conditions on making the sources available are imposed only if one wishes to distribute the work. If "personal hack" means "no distribution to others", then there's no obligation to make the modifications public. In both case, strictly applied, such rule would create weird practical issues to free software. I think you're objections were not with what I had imagined. ;) That's why the Hacking License assigns copyright and patent license upstream but without turning upstream copyright holders into Users. That does not require the modifier to make the modifications available to the upstream, or anyone though. They can also become users, obviously, but they can also just benefit from the copyright assignment and patent license to reimplement similar behavior without legal issues. How would I benefit from copyright assignment in modifications to my code, if I can never get (perhaps never even know about) those modifications? Note that one _already_ gets a copyright interest in any modifications to one's work (GPLed or whatever), if those modifications constitute a derived work. (In at least some jurisdictions). Just being a copyright holder in some derived work of one's own work is not per se sufficient to ensure one can get access to that derived work though. regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Another hour, another error report... - Eric S. Raymond on linux-kernel
Re: Hacking License
On Tue, 11 Dec 2018, Paul Wise wrote: If you are talking about grsecurity, Had more personally significant cases in mind, not GrSec per se, but GrSecurity is an example, on the contract side. That said, wrt "abusive corporates", I'd put GrSec more on the /victim/ side, and I have some sympathy for them, but that's another discussion. ;) the contract from 2017 was on their website, is now on archive.org but the current version is not public: https://web.archive.org/web/20170805231029/https://grsecurity.net/agree/agreement.php That looks like the kind of side-agreement that would be good to clearly make impermissible or impossible to hold people to, while also wanting to avail of a copyleft licence - to me. Personally, I want a copyleft for the 'gitlab/github/gogs' era: Source must be made available, unless you're on a desert island or there is a credibly physical risk of imprisonment or harm to individuals by disclosing their identity. I think that would depend on the protocol used and that many of them would have room for extensions that could include instructions for obtaining source code. If you add an extension, how do you know the other supports that extension and showing it to the user? How do you show the user "interacted" with your software? Seems unreliable / risky / unlikely to achieve the goal, if tested. regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Conceit causes more conversation than wit. -- LaRouchefoucauld
Re: Hacking License
On Mon, 10 Dec 2018, Ian Jackson wrote: Or are you really convinced that these other issues are showstoppers and that without handling them in your licence, downstreams will abuse their position ? Frankly that doesn't seem particularly likely. Without denigrating what you're saying on compatibility and understanding (as below)... There is an issue with the GPL style copyleft of abuse by corporates. In particular, abusing the ability to discharge source distribution privately, and then using various forms of side-contracts to (indirectly) "discourage" recipients from exercising their GPL rights. As this all happens in private, it makes it hard for copyright holders to take action. It can be hard to gather basic facts (e.g. the side contracts). The recipients - who are potentially having their GPL rights impinged - are not necessarily willing to even tell the copyright holders about this, never mind co-operate. Etc. Then there's the more general issue that the AGPL doesn't really work for non-interactive distributed-system software, should you want your distributed-system software to have its source be made available to anyone operating other bits (or implementations of) the distributed system. I think maybe you are seriously undervaluing the benefits of using a licence that everyone already knows and that is compatible with many other Free Software licences. regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Look out! Behind you!
Re: Cisco EIGRP patent licence and the GPLv2 licence
On Tue, 4 Jul 2017, Walter Landry wrote: "For any claims of any Cisco patents that are necessary for practicing the Enhanced Interior Gateway Routing Protocol specification , any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the specification. This means that Cisco's patent grant only applies if you are implementing EIGRP. So that feels incompatibile. With that said, the usual approach that Debian follows is that if the patent is not being actively enforced, Debian does not worry about them. Otherwise, Debian would not be able to ship anything. Since you claim later It's hard to know. Cisco do have a history of initiating patent enforcement actions though. E.g.: https://blogs.cisco.com/news/protecting-innovation-itc-945-initial-determination How much that would concern one would depend on one's situation. Personally, I don't have an issue with that style of licence cause it only limits those who want to sue over patents. Which seems fine to me. What I've gotten from those exchanges suggests there is little reason to be concerned about the Cisco patent or the licence. then it would be fine for Debian. That's on the concern about the patent and its licence. Which is where most people I've talked to stop the analysis. However, the concern that's been raised is on the other side. The concern raised is about the /copyright/ holders in the other GPLv2+ licensed code, on which the EIGRP GPLv2 code depends. The concern is those other copyright holders could object that the EIGRP code that depends on their code is patent encumbered, with potential royalties, and hence incompatible with the licence they gave on the use of their code. At a practical level, are those concerns founded, and what degree of caution on such concerns is warranted? Both in terms of reasonable protection against hostile copyright holders (e.g. SCO situations where copyrights fall into wrong hands) and deference to the wishes of friendly copyright holders who object to patent encumberances; but without unreasonably restricting others' ability to distribute code they have written? (On whether concerns are founded: The brief informal legal advice I've had seemed to suggest maybe - your reply above seems to too; what I can't get clarity on is that issue of the reasonable degree of caution, and the appropriate balance between different interests). regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: If you don't have time to do it right, where are you going to find the time to do it over?
Cisco EIGRP patent licence and the GPLv2 licence
Hi, I have a question I have not been able to get a conclusion to, regarding the compatibility of the licence Cisco have given to their EIGRP patents, by way of their declaration under the IETF "IPR" process. That declaration being: https://datatracker.ietf.org/ipr/2236/ The relevant grant/licence text being: "For any claims of any Cisco patents that are necessary for practicing the Enhanced Interior Gateway Routing Protocol specification , any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the specification. The reasonable non-discriminatory terms are: Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the Enhanced Interior Gateway Routing Protocol specification , provided, however that Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title or against any products or services of Cisco or any products or services of any of Cisco's affiliates either alone or in combination with other products or services. Royalty-bearing licenses will be available to anyone who prefers that option." A GPLv2+ implementation of EIGRP exists, which itself depends on other pieces of GPLv2+ code in Quagga. The question that's been raised with me is whether or not a free software project such as Quagga could distribute such an implementation? Are there any compatibility issues between the patent licence and the GPLv2 licence to worry about? In particular, to any degree that would cause a problem for a mainstream Linux distributions such as Debian? I've had some exchanges with a number of people about this. Including luminaries in the free software world, legal experts around free software, as well as quick and informal advice from a solicitor I know. What I've gotten from those exchanges suggests there is little reason to be concerned about the Cisco patent or the licence. It's less clear to me though whether there is an issue on the copyright and GPLv2+ licence side. The concern that has been raised with me is that the Cisco grant is conditional and revocable with potential royalties applying, while the GPLv2+ seems to require unconditional, non-revocable patent grant. "7. ... For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program." (Personally, I don't have a moral problem with a patent holder retaining the right to sue anyone who sues them over patents; but my opinion on that doesn't have a bearing on the GPLv2). So, would distributing a GPLv2+ EIGRP implementation which, in turn, depends on other GPLv2+ licensed code belonging to a diverse set of copyright holders, cause any issues for Debian? Does the answer to that question change in any way if it is the GPLv3+ instead? Thanks, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: The faster we go, the rounder we get. -- The Grateful Dead
