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: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
On 21/03/2019, Christian Kastner wrote: > On 2019-03-20 16:46, Giacomo Tesio wrote: >> 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. >> 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. Indeed GPLv2 § 2 states: > 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. ;-) > 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
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 2019-03-20 16:46, Giacomo Tesio wrote: > 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. > 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." -- Christian Kastner
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 20/03/2019, Giovanni Mascellani wrote: > Hi, > > Il 20/03/19 12:25, Giacomo Tesio ha scritto: >> 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
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
Hi, Il 20/03/19 12:25, Giacomo Tesio ha scritto: > 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. If I write a lot of broken C code in a file, but do so without copying anything from elsewhere, that is just a new work that does not depend on anything. The intent with which I write it or the possibility to merge it with other code to make something working is irrelevant. And that does not depend on any license: this is just how copyright laws work (by the simple fact that copyright laws make no mention of what "compiling" and "linking" are what the writer's intentions are). > 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. If anything, that proves the opposite of what you sating, namely that FRR is right: there are tons of fandom works based on characters, places and concepts introduced by Rowling in her works, both with and without modifications. They do not appear to be illegal at all, and it never occurred to me to learn that the authors of such works are being or could be prosecuted. Copyright does not protect ideas or concepts, it protects expressed works. I could rewrite the whole of Harry Potter's seven books off my mind, without directly copying the original ones, and it would be perfectly legal, although I admit it could be an interesting case how to prove that I did not actually copy from the original books. For similar reasons, people who write programs starting from reverse engineered information need to be really sure that they can prove they are not copying (i.e., they are doing a clean room implementation), but other than that there is nothing preventing them to do so. ReactOS people know something about this. So this example really convinces me that FRR people are doing right, and there is no reason for Debian to change anything there. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
Here are a few snippets out of a private mail on this topic; I've removed the original mail and paraphrased its contents since I firmly believe in not publishing any content (incl. metadata) from private e-mails that isn't my own :) - Forwarded message from David Lamparter - Someone wrote: > On Wed, 20 Mar 2019, David Lamparter wrote: > > That is really the crux of the question here. The code does contain > > /references/ to libfrr functions and data structures. But it doesn't > > contain any code that was copied/moved/directly derived from GPL > > functionality. Is it still considered derivative? > > > > We (FRR) believe it isn't. That's why we think we can still distribute > > babeld and ldpd under their permissive licenses. > [Someone cited section 2b of the GPL here] > > "You must cause any work that you distribute or publish, that in > whole or in part contains or is derived from the Program or any part > thereof, to be licensed as a whole at no charge to all third parties > under the terms of this License." > > [Someone argues here that since babeld is distributed with FRR, the > whole work falls under the GPL] I understand your argument, and it has indeed come up before, and you need to continue reading the GPL. Section 4 reads: 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. Note that it says here "the Program", not "work [...] that in whole or in part contains [...] the Program". While section 2b that you cited requires cost-free distribution and GPL license of any additional parts of the larger work, it does not exclude that larger work from being licensed more permissively. That requirement against more permissive licensing is only established in section 4 above, and only for "the Program" (which includes derivatives of it per the definition of section 0, but not collective works.) > [Someone linked to: > https://repository.jmls.edu/cgi/viewcontent.cgi?article=1014=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 -
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
Giacomo Tesio writes: > 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
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 at 13:10, Paul Jakma wrote: > > On Wed, 20 Mar 2019, Andrej Shadura wrote: > > > 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. -- Cheers, Andrej
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: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
On 20/03/2019, Ole Streicher wrote: > Giacomo Tesio writes: >> 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. > 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. > You may not like it, but > since the code writers do not derived from GPL code when they wrote > 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
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
Paul Jakma writes: > 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. 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
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 20/03/2019, Paul Jakma wrote: > 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. > > 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. > 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
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 20/03/2019, Giacomo Tesio wrote: > 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
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 20/03/2019, David Lamparter wrote: > On Wed, Mar 20, 2019 at 09:17:32AM +0100, Giacomo Tesio wrote: >> 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. > 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. > 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: > > [...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. > 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. 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. >> 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,
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: 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: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
Giacomo Tesio writes: > 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
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, Mar 20, 2019 at 09:17:32AM +0100, Giacomo Tesio wrote: > 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. [...] > 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
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 20/03/2019, David Lamparter wrote: > 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
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 20/03/2019, Bradley M. Kuhn wrote: > 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. On 20/03/2019, Florian Weimer wrote: > 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
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 Tue, Mar 19, 2019 at 05:28:05PM -0700, Bradley M. Kuhn wrote: > David Lamparter wrote: > > 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. [...] > 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. > 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. > > 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
Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
* Bradley M. Kuhn: > David Lamparter wrote: >> 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. > 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.
no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
David Lamparter wrote: > 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/
