Re: FRR package in Debian violates the GPL licence
On March 21, 2019 4:21:22 PM UTC, David Lamparter wrote: >You can't copyright words. Not words, but as you say, you can copyright characters. And characters have names. And such names are the first expressions of the copyright, that is called copy-right because if regulate the copy of those expression: guess what? In a textual work, the first sign of a copyright violation is the presence of those names. You can name ONE character of a completely unrelated novel "Harry Potter" (suppose no trademarks were involved), but if your novel also have an "Hermione Granger", a "Ron Weasley", a "Draco Malfoy" and a "Tom Riddle", it's probable that any Judge would take your argument "it's just a name" as outrageous, an insult to their intelligence. Now count how many names defined in GPL code are used babeld files not distributed as GPL. How many names defined in command.h are used in babel_interface.c? >> To be honest, the form of the text (in C, plain english, or >> mechanically translated to an object form for mechanical >consumption), >> I'd say that it shouldn't change much. > >It changes by incorporating additional material. If a C file contains >no include statements, only the copyright of the source applies to the >object file. But creating an accumulative work is very much a legal >concept (in software as well as in art.) FRR isn't an anthology of different unrelated works. >> All translations of a book are derivative work of the original, even >> if they are ALSO copyright of the translators. > >Yes, translations of books are derivative. But a translation of a >word, >or even a sentence, isn't. (Caveats apply - you can probably cram >enough content into a sentence to make it copyrightable. This boundary >is something that courts determine on a case-by-case basis.) And what about a sequel? It's a totally new work and yet it is a derivative work. Your babel_interface.c is just like a sequel of command.h >There are actually legislations that have enshrined this in law, as a >reaction to Microsoft's marked position in the 90ies. They explicitly >specify that any parts of a system that are required for interoperation >with that system can be freely copied regardless of copyright or >license. Sometimes this also extends to reverse engineering. This is a good objection and I'll take it at heart for my project of conquering the world with Free Software. But I think it would hard to sustain in a court that the internal headers of FRR (a GPL work) marked as GPL code themselves are a system interface needed for interoperability. >> So why do you think that this is a "toxic precedent"? > >I agree that this is a toxic precedent, because in your world we need >to reimplement everything from scratch at once. Thanks for your opinion. I'll seriously take it into account. For now I don’t agree. Note however that linking this FRR violation of section 2 of GPLv2 with the Oracle vs Google case is convenient FUD but very arguable. The FRR code evolved as a whole, the lib/ folder is not really a public API, but a collection of utilities for internal use within the project. GPLv2 section 2 explicitly exclude any section of a covereed work that is INDEPENDENT from the GPL code, and give you the right to modify the program as a whole, adding, changing and removing files according to the license itself. You can add original AND independent work as new files under any license just because of it. And you can add original BUT derivative work as new files too, but only under GPL. By violating this second condition you terminated your license on the GPL code without affecting any third party. You can bet Paul won't sue you. You might be right or wrong. You can bet nobody would help him to enforce the GPL because of fear of the API copyright issue. I guess you are right on this: it's more likely that "free lobbist-activists" will start to blame the victim, calling him copyright troll or something like that. But your license has been terminated and anyone dustributing your code without changing the broken headers is going to terminate their own license too. I still think you can practically fix the issue by changing the license of those derivative files to GPL. But beware that a Judge might disagree and simple impose you to chease and desist any further activity on the FRR codebase. Anyway please, stop arguing that babel_interface.c is not a derivative work of control.h. Argue that it's fair use or something, but don't negate the evidence. Such kind of behaviour hurts the credibility of our whole profession. 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 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 Thu, Mar 21, 2019 at 11:17:23AM +0100, Giacomo Tesio wrote: > Technically, he is asserting that any text that use substantial > original words defined in another original copyrightable text is a > derivative work of such original text. You can't copyright words. You probably can't even copyright a title like "Harry Potter and the Sourcerer's Stone". You certainly can't copyright the name "Harry Potter". Copyright requires a creation of sufficient "height" of the work. Neither a word nor a book title meets that requirement. Literary characters _do_ meet the requirement since the character as a whole is a complex creation. It has a backstory, attributes, flaws, - that's what you can base a copyright claim against fan fiction on, if you chose to do so. But if you put a character named "Harry Potter" in a new novel that has nothing to do with JK Rowling's Potterverse, there is no copyright issue. There is however a trademark issue, at least the title is probably trademarked (not sure if you can trademark the name alone.) [Add.: apparently you can trademark the name - https://register.dpma.de/DPMAregister/marke/register/300125666/DE ] > To be honest, the form of the text (in C, plain english, or > mechanically translated to an object form for mechanical consumption), > I'd say that it shouldn't change much. It changes by incorporating additional material. If a C file contains no include statements, only the copyright of the source applies to the object file. But creating an accumulative work is very much a legal concept (in software as well as in art.) > All translations of a book are derivative work of the original, even > if they are ALSO copyright of the translators. Yes, translations of books are derivative. But a translation of a word, or even a sentence, isn't. (Caveats apply - you can probably cram enough content into a sentence to make it copyrightable. This boundary is something that courts determine on a case-by-case basis.) [...] > I agree that the course of action you suggest to Paul is correct, but > I'd really like if you might elaborate about your concerns about API > copyrightability. btw: the POSIX standards itself are copyrighted: UNIX ® is a registered Trademark of The Open Group. POSIX ® is a registered Trademark of The IEEE. Copyright © 2001-2018 IEEE and The Open Group, All Rights Reserved Just because it is a standard, that doesn't free you up from adhering to their copyright. But as far as I'm concerned, implementing a standard isn't derivative of the standard unless you start copying or deriving actual content in your implementation. There are actually legislations that have enshrined this in law, as a reaction to Microsoft's marked position in the 90ies. They explicitly specify that any parts of a system that are required for interoperation with that system can be freely copied regardless of copyright or license. Sometimes this also extends to reverse engineering. (Take this as hearsay, I'm not a lawyer and I don't have time to double check.) > I know that this is a widely minoritarian position, but I think that a > strong copyleft over innovative APIs might be very beneficial to Free > Software. > > Most of commercial APIs are crap so we wouldn't lose much. > OTOH Free Software is strong enough to innovate and through a strong > enough copyleft, we might create a new and better stack that keep most > future software in the Commons, spreading knowledge and collaboration, > for the benefit of the whole Humanity. > > > So why do you think that this is a "toxic precedent"? I agree that this is a toxic precedent, because in your world we need to reimplement everything from scratch at once. This is, in my experience, neither how software development works, nor is it doable. Essentially, your precedent would immediately shut down most open source because it would no longer be able to mesh into the existing world, however crappy it might be. Sorry, -David
Re: FRR package in Debian violates the GPL licence
On 21/03/2019, Eloi wrote: > El 21/3/19 a les 11:17, Giacomo Tesio ha escrit: >> So why do you think that this is a "toxic precedent"? > > No free software could run under Windows without proper Microsoft > licensing: Firefox, Libreoffice... > > No free software could use or implement compatible Windows services, > either server or client, without proper Microsoft licensing: Samba, > rdesktop... You are not looking at the whole picture. ;-) Microsoft is distributing WSL. Microsoft is distributing several Linux distros (which include Firefox, Libreoffice...) Microsoft is selling services based on Linux. Microsoft even creating their own Linux distribution "Azure Sphere OS". Europe taught Microsoft that they cannot abuse their dominant position. Arguably other corporations need a recall on the topic too, despite their OS being "open source". ;-) > That would make Linux and Windows ecosystems fully disjoint. This would > force me to use Windows to do the work I'm paid for and for which I've > been using Debian for 10 years. Sorry but this is FUD. Look at the whole picture. Microsoft is not going to face European antitrust again. > OTOH, that would make the software patent problem fully irrelevant > because copyright would cover what currently is being enfonced by patent > licensing. Indeed the current status is not free, despite the permissive licenses and their rhetoric. Giacomo
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: FRR package in Debian violates the GPL licence
El 21/3/19 a les 11:17, Giacomo Tesio ha escrit: > So why do you think that this is a "toxic precedent"? No free software could run under Windows without proper Microsoft licensing: Firefox, Libreoffice... No free software could use or implement compatible Windows services, either server or client, without proper Microsoft licensing: Samba, rdesktop... That would make Linux and Windows ecosystems fully disjoint. This would force me to use Windows to do the work I'm paid for and for which I've been using Debian for 10 years. OTOH, that would make the software patent problem fully irrelevant because copyright would cover what currently is being enfonced by patent licensing.
Re: FRR package in Debian violates the GPL licence
On 21/03/2019, Giacomo Tesio wrote: > On 21/03/2019, Christian Kastner wrote: >>> So why do you think that this is a "toxic precedent"? >> >> Because then you'd never be able to provide a compatible free software >> alternative to *any* proprietary solution. > > But they couldn't provide any COMPATIBLE alternative to Free Software > solution either! Imagine for a moment if the Web was born under a similar legal framework. Only Free Software browsers. Only Free Software servers. Only Free Software Web applications. Only Free Software API. You could ask to inspect the code that is executed for you by a SaaS or move the whole application to a server under your physical control. OTOH, SaaS providers would have a HUGE pressure to preserve their customers' trust. Now, you can see how Google is moving to replace HTTP with his own new kids. So it IS still possible to change the status quo, simply because... it's software! ;-) Giacomo
Re: FRR package in Debian violates the GPL licence
On 21/03/2019, Christian Kastner wrote: > On 2019-03-21 11:17, Giacomo Tesio wrote: >> Most of commercial APIs are crap so we wouldn't lose much. > > You care confusing quality with popularity/success. POSIX has its own > share of crap interfaces, but they are prevalent. No, I know that crap is prevalent in our field. Indeed I'm not much scared by the idea of throwing it all out with the windows (pun intended :-D) >> OTOH Free Software is strong enough to innovate and through a strong >> enough copyleft, we might create a new and better stack that keep most >> future software in the Commons, spreading knowledge and collaboration, >> for the benefit of the whole Humanity. >> >> So why do you think that this is a "toxic precedent"? > > Because then you'd never be able to provide a compatible free software > alternative to *any* proprietary solution. Correct. We couldn't provide any COMPATIBLE alternative to proprietary solutions (that do not implement standards). But we could still provide BETTER alternatives! But they couldn't provide any COMPATIBLE alternative to Free Software solution either! Given the amount of crap in legacy systems, this would resort into a huge advantage for Free Software! Giacomo
Re: FRR package in Debian violates the GPL licence
On 2019-03-21 11:17, Giacomo Tesio wrote: > Most of commercial APIs are crap so we wouldn't lose much. You care confusing quality with popularity/success. POSIX has its own share of crap interfaces, but they are prevalent. > OTOH Free Software is strong enough to innovate and through a strong > enough copyleft, we might create a new and better stack that keep most > future software in the Commons, spreading knowledge and collaboration, > for the benefit of the whole Humanity. > > So why do you think that this is a "toxic precedent"? Because then you'd never be able to provide a compatible free software alternative to *any* proprietary solution. -- 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 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: Re: FRR package in Debian violates the GPL licence
On March 21, 2019 12:04:36 PM UTC, Paul Tagliamonte wrote: >> >> Lots of free software also is very much inspired by proprietary >works, >> be they APIs, protocol or entire programs. > >http://docs.ceph.com/docs/mimic/radosgw/s3/ Is Amazon S3 the best possible interface one could think of? For sure it's not the simplest. Giacomo
Re: Re: FRR package in Debian violates the GPL licence
On March 21, 2019 11:55:04 AM UTC, Ansgar wrote: >As far as I know POSIX isn't a new and original interface that was >designed in a clean room; it (in large parts) documents interfaces that >were available in proprietary operating systems. As long as the original vendors recognised the standard (eg by selling their own OS as POSIX compliant) or joined the standard body to lobby for their own extensions to be included, they wouldn't have much ground to complain. Through the standard's document they waived any copyright claim they could have against the competitors implenting such standard. Now, just to be clear, POSIX is not such a great standard (to use an euphemism :-D). But the point stands. Implementing a standard that exists to be implemented independently, does not require copyright permission, as it's a derivative work of the standard document itself. >Lots of free software also is very much inspired by proprietary works, >be they APIs, protocol or entire programs. True. Indeed the peace of true innovation in Free Software is only kept high by the most crazy hackers out there who actually try to invent new things. In the camp of Open Source instead, whereever there's actual innovation, corporations resort to patents. They SAY that it's just "defensive patent trolling" but you can never know what happens if your fork of their open source OS or browser get a chance of challenging their businesses model! So ultimately innovative Free Software hackers have no protection against bad actors that EEE their creations, exploiting their gift as free (highly qualified) labor. OTOH corporate open source is well protected in a number of ways (high technical complexity, social anathema on forkers and last but not least patents). This asymmetry is acceptable only if you think that profit is the ultimate goal of everything. Which is actually an opinion with many and strong supporters. It's the "Spirit of Capitalism" as Weber used to call it. But to those who follow a different ethics, who care about knowledge and freedom, this asymmetry is not acceptable at all. Because it let people exploit us, our gifts and our work. To us it's not even a sustainability issue: there is no price a corp could afford, the code is knowledge and it must be free. Giacomo
Re: Re: FRR package in Debian violates the GPL licence
On 21/03/2019, Julian Andres Klode wrote: > I'm not sure why you are supporting Oracle's position, but consider > the impact on the computing world of that position, and what trouble > it causes if it wins. I can't answer for Paul, and I really don't care about neither Oracle or Google. But there is a huge difference between reimplementing a standard interface like POSIX and depending on a creative work that is original. Whenever a standard exists, anything that implement it, even partially, is NOT subject to this issue. And in the long run, throwing away the complexity of supporting old proprietary formats that not even the original vendor actually support anymore could improve the quality of the Free Software as a whole. The WINE / ReactOS cases are unfortunate. But in the long run, not being able to copy proprietary code might greatly improve the innovation in Free Software while keeping such innovation under Commons (with a strong copyleft, possibly with a wider reach of AGPL), might invert the power dynamics between independent innovative hackers and large corporations. Don't forget that we are not in 1999 anymore. Lots corporate code is "open source": OSS has become a fundamental tool to gain market share and user trust. On the other hand, if I donate original code to everybody, I don't want it to be Embraced, Extended and Extinguished by any organization. Informatics is still at a very early stage of its development. As primitive as it is, most of proprietary software is crap and we all know this despite trained to ignore its glitches "because worse is better". The future might be Free Software if no one could actually close it in any way. Giacomo
Re: Re: FRR package in Debian violates the GPL licence
Paul Jama wrote:
> 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.
Of course it is controversial, that was the whole point of the
Oracle vs Google trial. It was generally believed that API is not
copyrightable, for example, BSD had the same interfaces as UNIX,
but was not a derivative of UNIX; or Wine reimplements the Windows
APIs but is not a derivative of Windows.
Oracle challenged this in 2010, claiming that Google's reimplementation
of parts of Java is a derivative work of their Java API. The court unfortunately
agreed with this, despite all previous precedents, and despite this
causing severe issues for the field (as it prevents you from re-implementing
a proprietrary API not supported anymore by the vendor, for example, or
support for proprietrary file formats).
I'm not sure why you are supporting Oracle's position, but consider
the impact on the computing world of that position, and what trouble
it causes if it wins.
There is still some hope: The case is not closed - a second supreme
court petition was filed in January.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Re: FRR package in Debian violates the GPL licence
On 21/03/2019, Steve Langasek wrote: > But as for the substance of your claim, what you are doing here is asserting > copyright on an interface. While there has been recent notable case law in > certain jurisdictions which wrongly supports the notion that interfaces > contain sufficient creativity to be copyrightable, that is an incredibly > toxic precedent to set in the Free Software world. Technically, he is asserting that any text that use substantial original words defined in another original copyrightable text is a derivative work of such original text. To be honest, the form of the text (in C, plain english, or mechanically translated to an object form for mechanical consumption), I'd say that it shouldn't change much. All translations of a book are derivative work of the original, even if they are ALSO copyright of the translators. Since compilers are things and do not hold copyright, API or ABI doesn't change much. I agree that the course of action you suggest to Paul is correct, but I'd really like if you might elaborate about your concerns about API copyrightability. I know that this is a widely minoritarian position, but I think that a strong copyleft over innovative APIs might be very beneficial to Free Software. Most of commercial APIs are crap so we wouldn't lose much. OTOH Free Software is strong enough to innovate and through a strong enough copyleft, we might create a new and better stack that keep most future software in the Commons, spreading knowledge and collaboration, for the benefit of the whole Humanity. So why do you think that this is a "toxic precedent"? Giacomo
Re: FRR package in Debian violates the GPL licence
Paul Jakma writes:
> On Wed, 20 Mar 2019, Ole Streicher wrote:
>> #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.
So any source code using OpenSSL is a derivative work of OpenSSL and the
terms of the OpenSSL license would apply? (Hah, no GPL with an
exception for linking OpenSSL will safe you now!)
Or any source code using the DirectX API is a derivative work of DirectX and
has to follow Microsoft terms for that? Even though it might just use
the alternative Vulkan implementation on Linux?
What about source code implementing an proprietary API? Would WINE be a
derivative work of Windows?
What about source code implementing an API described in a proprietary
document? Would it be a derivative work of said document?
I think the view that using an API in any way in source code makes a
work a derivative work of the API provider is not realistic; for
binaries it might be more complicated, but we aren't discussing that
here.
Ansgar
Re: FRR package in Debian violates the GPL licence
Hi Paul, On Wed, Mar 20, 2019 at 10:54:12AM +, Paul Jakma wrote: > 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. What is the point of this discussion, in general? debian-legal is a public mailing list where individual Debian Developers (and non-Debian Developers) opine on questions of licenses, with no legal authority. Even if you manage to persuade some number of people here that your position is correct, that doesn't translate to a change in Debian's position on shipping the package in question. You can file a severity: serious bug against the package and ask the Debian FTP team to intervene; if they agree with you the package would be removed. If you believe there is a license violation that needs to be addressed even if the Debian ftp team don't agree with your and your lawyer's interpretation of copyright law, then you should probably be having your lawyer get in touch with Debian, and Debian's lawyers will review and respond, and the matter will be adjudicated via the legal system - not via an opt-in mailing list. But as for the substance of your claim, what you are doing here is asserting copyright on an interface. While there has been recent notable case law in certain jurisdictions which wrongly supports the notion that interfaces contain sufficient creativity to be copyrightable, that is an incredibly toxic precedent to set in the Free Software world. > Copyright gives authors of works not just the right not to just control > literal copying, but also a controlling right in any adaptations of their > work (amongst other things). Whether you agree with this or not, various > variants of this concept are law in many countries around the world. Coding to an interface is not "adaptation" of a copyrighted work. Your interpretation of copyright law is inconsistent with how Debian has operated for over 20 years, and I do not expect Debian to cede this position without lawyers getting involved, or for Debian to be willing to distribute any of your code, as part of frr or otherwise, at the end of the process. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP 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)
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: FRR package in Debian violates the GPL licence
Paul Jakma writes:
> 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.
I do not build on anything. I wrote two lines of code. I even didn't
check whether it compiles.
*If* you are building a program out of that (compiling, linking with GPL
code), then the program should be under GPL, undoubtly.
But this is not what I did. I just wrote some source code, without using
external intellectual property. So, I am free to distribute that code
under any license I want. I did not use GPL code to write my example, so
I can't be bound to its conditions when I distribute my writing.
Best
Ole
Re: FRR package in Debian violates the GPL licence
Hi Paul
I’ve watching this thread with interest, and I must admit I’m reluctant to get
too involved, but there are a couple of things I thought it might be helpful
(!) to point out.
> On 20 Mar 2019, at 13:53, Paul Jakma wrote:
>
> 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.
This would only be true if the string of text “zlog_rotate” is itself
copyrightable. And in all jurisdictions I’m aware of, it would fail that test.
Incorporating the functionality of a work by reference is something that
lawyers have been doing for years. We will write building contracts
incorporating JCT Minor works and financial contracts incorporating IFEMAs and
ISDAs. JCTs, IFEMAs and ISDAs are all standard form contracts which are
copyrighted works, but unless we copy any or all of the content of those
standard works, then we are not required to pay any licensing fees for only
referring to them and incorporating them by name.
There is an argument that the GPL overreaches copyright law, and says “if you
incorporate a piece of GPLd work G into another work W, no matter how trivial
that incorporation is, that other work must only be distributed under the GPL”.
If that is true, then the distributing party may be in breach of its licence to
work G, and may be at risk of having its licence to G terminated by its act of
distributing work W, but the copyright owner of W will have no way of
preventing the onward distribution of work W. There have been cases in the US
which suggest that this sort of overreach is unacceptable (it’s essentially a
way of trying to create new, more extensive copyright law by the back door),
but I’m not a US lawyer, so can’t comment authoritatively.
If the GPL doesn’t overreach copyright law, then it’s fine to distribute W
under whatever licence you want. Of course, this only applies to the source. If
you distribute the object code, then you will have created a combined work
(which Larry Rosen has argued, I believe, is collective work as you can still
reverse engineer it to extract the two components, but that’s not an argument
I’d like to rely on).
If, in order to write work W, you have to incorporate sufficient of work G (for
example an interface definition) into it to make it work that some
copyrightable part of G is incorporated, then this argument fails, but ONLY if
the parts so copied are subject to the GPL. For example, imagine a program X
uses plugins, and it has a published specification for the interface which is
usable without licence (assuming either that the interface is not
copyrightable, or there is an unrestricted licence) You write a piece of
software to that specification, and release it under the GPL. Now it would be
absurd to suggest that program X has to be released under the GPL, to comply
with the licence of a piece of software which was written *after* it was
written. Similarly, if I write another piece of software Y which uses your GPL
plugin (thus replicating the plugin interface of program X), then there is no
requirement on me to release my code under the GPL. I am copying X’s
specification.
This does, of course, suggest a way of violating the spirit of the GPL by
distributing non-GPL component X and component Y in source code as an
aggregation, and then also sending over a script to the recipient which
combines them. Since the combination occurs prior to distribution, the argument
goes, then this is fine. There are a few counterarguments to this. The first is
that there is some form of secondary infringement. I have difficulty with this
argument: causing someone to do something which is perfectly legal for them to
do seems to be a stretch. The second is more interesting, and that is that my
causing the script to run on the recipients machine, the person sending the
code somehow has control of the recipient’s machine, and is therefore for the
period of time that the script is running, they are dong the combination,
immediately following which the result is distributed, in violation of the GPL,
to the recipient. Far fetched? Well, think about what would happen if the
activity took place inside a VM running on the recipient’s machine to which the
sender had root access, until the point at which the combination
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
Paul Jakma writes:
> On Wed, 20 Mar 2019, Ole Streicher wrote:
>> #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.
This work is completely based on my own, there is no intellectual
property of someone else in my source code.
Only the compilation step incorporates other code (via the #include
statement, and, when linked, the library), but this does affect only the
object and executable files.
>> Otherwise you must point to a certain code file and prove that it
>> contains code which is a modified copy of an GPLed file. Which you
>> not did yet.
>
> I have given examples of files where the legal advice is that they are
> derived works of the GPL code.
To comply with section 2, they must be "modified copies". So, please
show the files, the original files, and the modification.
Best
Ole
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: 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 at 14:00 Paul Jakma wrote: > On Wed, 20 Mar 2019, David Given wrote: [...] > > - I *can* use this library in BSD code, and distribute both together > > as an aggregate under the terms of the GPL --- because the BSD > > license conditions are met by the GPL, so by distributing the whole > > under the terms of the GPL I meet both sets of licensing terms, and > > so everything is fine. > > If by "use this library in BSD code" you mean modify and/or extend the > BSD code so it relied on the facilities of the GPL code, then you can > distribute my code under the GPL correct. > I got halfway through responding to this point-by-point until I realised that you're assuming that all usage of someone else's API makes a derived work --- everything you've said follows on logically from that. Okay, here's a thought experiment. I'm writing a gawk script. I'm using the GNU extensions, which only exist in the gawk version of the language. Is my script a derived work of gawk or not? After all: - the script is completely dependent on the gawk APIs (i.e. the published language) - the script relies on implementation details of gawk (i.e. the non-standard extensions to the language) - the script will not work on any other version of gawk - the script requires gawk to be distributed along with it or it won't work
Re: FRR package in Debian violates the GPL licence
Paul Jakma writes: > 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? The FRR code is not "derived work". It is not a modified copy of any GPL code. Instead it aggregates the (changed? unchanged?) GPL code with code that is written on its own. This code is not a modified copy of any GPL code, therefore they can give any license to it. "Modified copy" is the term which is used in GPL, and you should prove that the code in question is a modified copy. Again, I can put my mini-2-liner under any license, unaffected by the GPL. Since it is not a modified copy of anything. Best Ole
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
David Given writes: > - I can't use this library in closed source code, and distribute the > result as an aggregate --- because there is no license which can meet > the terms of the GPL and my closed source license. > > - I can use this this library in closed source code, and distribute > the library and the closed source code seperately --- because they're > not being distributed together it's not an aggregation, and both sets > of licensing terms are being met independently. GPLv2, section 2 explicitly allows aggregation: | In addition, mere aggregation of another work not based on the Program | with the Program (or with a work based on the Program) on a volume of | a storage or distribution medium does not bring the other work under | the scope of this License. Therefore, I would think that one *can* distribute both source codes together, even when part of it is closed source. Best Ole
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)
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: FRR package in Debian violates the GPL licence
Paul Jakma writes:
> 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.
In the GPL case, it protects /modified/ code copies.
| 2. You may modify your copy or copies of the Program or any portion
| of it, thus forming a work based on the Program, and copy and [...]
The example I brought, was written from scratch, it was therefore not a
"modified copy".
> Copyright gives authors of works not just the right not to just
> control literal copying, but also a controlling right in any
> adaptations of their work (amongst other things).
My example
#include
int main(void) { zlog_rotate(); return 0; }
is not an adaption of any GPL code. It is fully written by my
own. Therefore, I don't need to respect the GPL to distribute it. The
same is true for the FRR code as far as I have seen it.
Otherwise you must point to a certain code file and prove that it
contains code which is a modified copy of an GPLed file. Which you not
did yet.
Best
Ole
Re: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019 at 12:26 Paul Jakma wrote: > On Wed, 20 Mar 2019, David Given wrote: > [...] > > and FRR would be entirely within their rights to have pulled > > these out from the original app and turned them into a GPL library, > > *with* public entry points, and then ship that along with their code. > > No, you can't just take GPL of code mine, libify it and say it's OK for > it be used in proprietary code, without my agreement. > That's not what I said. - I *can* take your GPL code and turn it into a GPL library. That's what the GPL is for. I don't even need to ask you about it. - I *can* use this library in BSD code, and distribute both together as an aggregate under the terms of the GPL --- because the BSD license conditions are met by the GPL, so by distributing the whole under the terms of the GPL I meet both sets of licensing terms, and so everything is fine. - I *can't* use this library in closed source code, and distribute the result as an aggregate --- because there is no license which can meet the terms of the GPL *and* my closed source license. - I *can* use this this library in closed source code, and distribute the library and the closed source code *seperately* --- because they're not being distributed together it's not an aggregation, and both sets of licensing terms are being met independently. - I *can't *modify your library, and distribute the modified version as BSD, because the modifications are derived work, and therefore the result is only distributable under the terms of the GPL. What's under dispute here is whether FRR is an aggregation or a derivation. And, TBH, the examples you've shown me are all pretty underwhelming --- they're all standalone modules being used in a library context. Your argument's plausible, but you need better evidence. Mostly what you're saying now is too vague to be useful. You need actual files you can actually point it that we can look at --- and I'm afraid you're the one who's going to have to come up with this.
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: 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: 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: FRR package in Debian violates the GPL licence
On Wed, 20 Mar 2019 at 11:48 Ole Streicher wrote: > Paul Jakma writes: > [...] > > Those files are derived works of the GPL code and must be distributed > > according to the conditions of the GPL licence, if they are to be > > distributed lawfully. > > Those files do not use GPL code; they just refer to it. No line of that > code was originated in GPL licensed code. > I think what he's trying to argue is this: - the BSD code has tight enough dependencies to the GPL code that it must be considered a derived work, and therefore *because it's distributed* it's implicitly licensed under the GPL. Therefore labelling it as BSD code is a licensing violation (because it's really GPL). His communication is very poor. However, he's not *necessarily* wrong. I originally thought that Zebra was a library being accessed via its public APIs, but it's not; it's a standalone program which doesn't have any public APIs. So, FRR's use of it is dependent on internal implementation details. So, yes, it's not beyond the bounds of possibility that FRR's BSD stuff could be considered derived. OTOH the bits of Zebra he pointed out to me are all standalone modules, and FRR would be entirely within their rights to have pulled these out from the original app and turned them into a GPL library, *with* public entry points, and then ship that along with their code. So... yeah, I dunno. The evidence he supplied wasn't particularly convincing, but I can see where he's coming from.
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: 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 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: FRR package in Debian violates the GPL licence
Paul Jakma writes:
> 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?
Section 1 handles the case of unmodified files, and this is what I
referred to.
> I have explained several times now that this concerns files which were
> created outside of Quagga [...]
>
> Those files are derived works of the GPL code and must be distributed
> according to the conditions of the GPL licence, if they are to be
> distributed lawfully.
Those files do not use GPL code; they just refer to it. No line of that
code was originated in GPL licensed code.
If someone compiles the code, then the compiler merges the GPL licensed
header, creating an object file that drives from GPL (and must be
distributed as such). But this applies to the object file, not to the
source.
> The GPL licence requires appropriate copyright notices in Section
> 1. Section 1 applies to unmodified files, and it also applies to
> modified files and derived works (see Section 2).
Files written from scratch are not derived works. When I write the
following lines:
#include
int main(void) { zlog_rotate(); return 0; }
then this is my own code, not derived from any GPL code. I can
distribute this code under any license I want, even when it is meant to
be used with the Zebra log implementation, and even when it has no
meaning outside of this.
The created *object* file must be under GPL, if zebra's log.h was used
to create it -- since log.h is GPL.
Best
Ole
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: 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: 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: FRR package in Debian violates the GPL licence
Giacomo Tesio writes: > On 20/03/2019, Ole Streicher wrote: >> This does not match section 1, which allows the distribution of >> unmodified files along with the proper license information. >> >> Again: Could you please point to the section in the GPL that is >> violated? > > The "with the proper license" part. ;-) As far as I checked, all unmodified GPL licensed files keep the short GPL statement in the file, and are accompanied with a copy of the GPL in the project's root directory. To cite the relevant section from GPL: | 1. You may copy and distribute verbatim copies of the Program's source | code as you receive it, in any medium, provided that you conspicuously | and appropriately publish on each copy an appropriate copyright notice | and disclaimer of warranty; keep intact all the notices that refer to | this License and to the absence of any warranty; and give any other | recipients of the Program a copy of this License along with the Program. | | You may charge a fee for the physical act of transferring a copy, and | you may at your option offer warranty protection in exchange for a fee. This all is respected, for each unchanged file. I don't see a violation here. Best Ole
Re: FRR package in Debian violates the GPL licence
On 20/03/2019, Ole Streicher wrote: > This does not match section 1, which allows the distribution of > unmodified files along with the proper license information. > > Again: Could you please point to the section in the GPL that is > violated? The "with the proper license" part. ;-) Giacomo
Re: FRR package in Debian violates the GPL licence
Paul Jakma writes: > On Tue, 19 Mar 2019, Ole Streicher wrote: >> Paul Jakma writes: >>> b) They are not complying with Section 1. >> >> In GPLv2, section 1 allows the distribution of unmodified source code, >> if the license information is distributed unmodified as well. > >> Which unmodified GPL source code do they distribute without the >> licensing information? > > They are distributing files which were created outwith of Quagga, > which explicitly refer to, make use of and rely upon facilities > provided by GPL code obtained from Quagga (which obtained code from > GNU Zebra before it). This does not match section 1, which allows the distribution of unmodified files along with the proper license information. Again: Could you please point to the section in the GPL that is violated? Best regards Ole
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: 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: 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/
Re: FRR package in Debian violates the GPL licence
* Paul Jakma: > 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. Is there a Quagga or Zebra code base out there that is covered by another license, and not the GPL? Let's consider a different example why I think licensing GPL-dependent code under a more permissive license makes sense. Suppose I write a useful patch for Hotspot, a component of OpenJDK, which is licensed under the GPL, version 2; exactly this version and no exception. I do not wish to deal with hassles of the contributor agreement to OpenJDK, so I release my patch under a HPND license. This covers two relevant scenarios: * Hotspot is relicensed under the GPL, version 3. My patch remains usable. (I could have obtained the same result by using the GPL, version 2, with some adjusted language that it is not in fact “at your option”.) * A recipient of my patch has obtained Hotspot under a license that is different from the GPL, version 2. They can still apply my patch and distribute Hotspot (if the terms of their alternative licensing agreement permits this), as long they comply with the HPND notification requirements. Given these possibilities, I do not see a problem with releasing a patch under HPND, even if the publicly available sources to which the patch applies is available under a different (but compatible) license only. (Let's not argue about patch context and the impact of copyright on those, please.) If I recall correctly, Zebra went proprietary at some point. Quagga was started from the published GPL code base. The files you identified mostly seem to date back to Zebra. Therefore, it is not inconceivable that certain Quagga additions would be in the same category as that hypothetical Hotspot patch (for the second reason: the alternative licensing option for the baseline code). Or put differently, why should someone who writes a Quagga extension which happens to work with the proprietary Zebra code base, too, be forced to license the extension in such a way that it cannot be used with Zebra for legal reasons? That does not make any sense to me.
Re: FRR package in Debian violates the GPL licence
Paul Jakma writes: > 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. 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?
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
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? Ole
Re: FRR package in Debian violates the GPL licence
On Tue, Mar 19, 2019 at 02:22:08PM +, Paul Jakma wrote: > 3. People took the code of (2), and adapted that code - extensively and >explicitly - to make use of and rely upon the facilities of the code >of (1); facilities which were missing in the code of (2). > > The people involved in (3) - Linux Foundation, Cumulus Networks, 6WIND, Big > Switch Networks, etc. - refuse to acknowledge the legal reality that the > code of (3) is covered by the GPL licence of the code of (2), and refuse to > honour the conditions required by the GPL - see David Lamparter's mail. Well, that's more complicated than I've thought. Under my point of view, those companies are right, sorry to say that.
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 Sun, Mar 17, 2019 at 02:08:38PM +0100, David Lamparter wrote: > The respective original authors have expressed and reaffirmed their > wishes for the code to remain under a permissive license. While we > could obviously just slap GPL on top, we have decided to try and honour > the original author's requests. Indeed, when including external libraries/files into a software project, I was always encouraged to contribute my changes under the same license of each individual part, for polite reasons. So, I am somewhat puzzled about this issue. On the other side, if I understood correctly, there are authors who want to contribute their code under GPL exclusively, and they feel that some of their changes got included into the bundled libraries (and are significant enough to be covered by copyright), so those libraries should be wrapped by the GPL as well. Maybe those external libraries should not be imported in the first place, to respect all authors' wishes seems imposible when they are mutually exclusive, and that's looks "murky" even if allowed by the license.
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
❦ 18 mars 2019 15:45 +00, Paul Jakma : >> Being merely dependent on third-party code is not, to my >> understanding, sufficient to be considered derived code. > > If code which is written to depend explicitly and heavily on the APIs > and frameworks provided by GPL is /not/ considered subject to the GPL, > but 'mere' 'aggregration', one would wonder why the LGPL would ever > have been drafted. One would wonder why readline was ever an issue for > the BSDs. etc., etc. IMO because the definition of derived work comes from binary linking (static or dynamic). There are libreadline alternatives licensed under a BSD-like license (like libedit or libeditline). There are API-compatible, not ABI-compatible. If you link the program with libreadline, you have to distribute the result under the GPL. If you link it with libedit, you don't have to. The source code of the program is exactly the same. Is it GPL or is it not? The API exposed by Quagga could be provided by another project using another license. > 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. -- Let the machine do the dirty work. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
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, Giacomo wrote: On March 18, 2019 4:44:09 PM UTC, Paul Jakma wrote: 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. You might want to have a look at [1]. Each module might have its own license but the whole work has to be licensed under GPL. Maybe [2] helps as well when you replace "public domain" by MIT license. Thorsten [1] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#IfLibraryIsGPL [2] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#CombinePublicDomainWithGPL
Re: FRR package in Debian violates the GPL licence
On March 18, 2019 4:44:09 PM UTC, Paul Jakma wrote: >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. I've got similar legal advice several years ago in a totally equivalent situation. If the code X cannot even be written without the preexisting code Y, and the code Y is under GPLv2 (that was the case back then), the copyright holder of X cannot distribute the code under a different license. By trying to do so, the copyright holder on Y would terminate all his license on X but he could still further distribute Y, but only under GPLv2 as Y IS a Derived Work of X. This however would not affect any third party who received X and Y and was compliant with GPLv2 on X+Y and on Y itself (on this Paul's advice doesn't match the one I did received). My interpretation of this last advice is that, even if the author of Y do not distribute Y anymore since his license on X terminate, once it exists, anyone with a copy can still distribute it under the proper GPLv2 license. Another thing the lawyer said back then is that if the violating party does not recognise a license violation Termination of the License can only be enforced in court. This means that, in practice, both FRRouting and Debian CAN fix the issue before being sued. In case of a process, the faster the fix, the better the outcome. Your mileage may vary. ;-) Giacomo
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
Hi, Il 18/03/19 16:45, Paul Jakma ha scritto: > 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. My guess is that LGPL was introduced to allow LGPL libraries to be linked by software licensed under more restrictive licenses. There is no need for special provisions when linking GPL software with more liberal licenses, in my understanding of the things (and in basically every use case I've always heard about). > 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. As far as I know, the formal legal advice you received is not in line with how maybe half of the free software ecosystem works. I think I have seen MIT/BSD pieces of code in most of the GPL projects I have looked into. > I will stick with the views of those qualified solicitors, over the view > of a software engineer, at least on legal matters. Absolutely sensible. Then why are you asking on a mailing list of programmers? Maybe asking on a mailing list of qualified solicitors would give you more satisfaction. Cheers, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
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 at 13:09 Paul Jakma wrote: [...] > Anyway, a small, non-exhaustive sampling with rough, incomplete notes - > for the sake of speed: > Thanks! I may be missing something here, but none of the examples you gave show any signs of being derived code. They *use* vty.[ch], but do not include any of their code (bear in mind that I'm not familiar with either code base). Being merely dependent on third-party code is not, to my understanding, sufficient to be considered derived code. It looks like this is a clearcut case of aggregation: somepackage/gpllibrary/COPYING.GPL somepackage/bsdlibrary/COPYING.BSD somepackage/COPYING.GPL bsdlibrary can be distributed *on its own* under the terms of the BSD, but if it's distributed along with gpllibrary, then the combined licensing terms of both libraries can only be met by the combined package being distributed under the terms of the GPL. In FRR's case, the combined repository is clearly labelled as being distributable under the terms of the GPL. This all looks fine to me.
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 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?
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
David Lamparter writes: > We expressly acknowledge that FRR binary packages must be distributed in > their entirety under GPLv2 or newer, and this is what I thought is > indicated in the Debian package too. Debian does not attach *any* license to a binary package. It just documents the licenses of the sources. There is however no way (except carefully going through the [documented] build process) to find out, under which conditions a binary files can be used/(re)distributed/modified. Best Ole
Re: FRR package in Debian violates the GPL licence
I didn't look at the code (sorry), but those files that depends on GPL code (either by calling GPL functions that are not described by a standard, or using data structures defined in GPL code or using global variables there defined), can only be licensed as GPL. You cannot build a (say) MIT derivative of a GPL library, for example. What you can do (I imagine) is to double license your new files as MIT and GPL, so that if all the GPL code is replaced with MIT code that do not violates the original copyright (that is, the whole application is rewritten from scratch IN A TOTALLY DIFFERENT WAY) the future contributor can decide to terminate their own GPL license on those files and leverage only the MIT one during their migration to the new codebase. As of today, if those file depend on GPL code, the authors can't distribute them under a different license. Actually they might have terminated their right to create a derived work by doing so. This wouldn't affect (AFAIK) people who receive such GPL derivative and threat it as GPL derivative, though. So adding the missing header WHERE the GPL dependency actually exists (that can only be known by carefully analyzing each file source), might be a simple and effective fix to settle the matter. Giacomo
Re: FRR package in Debian violates the GPL licence
Hi Paul, a question: given you agree that the code without proper license header must be under GPL as derived work of GPL code, 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? While I am just another non-lawyer on the Internet, I'm not much convinced that if a distributor violates the GPL causing its termination, downstream receivers of the software doesn't receive a license themselves. AFAIK the GPL license is always direct and not revocable from the copyright holder to the user: the compliance of middlemen doesn’t affect users. 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! People can introduce (say) MIT code in a GPL software and while the software as a whole is GPL, that MIT code remains MIT until modified with a patch under GPL. The ambiguity the upstream devs are trying to exploit is another thing, so I agree that they might be violating the GPL if they don't clearly states that all files lacking any header is to be considered under GPL (but they could argue that this is actually the default, meaning you are debating about file details but not really the licensing... and I don’t think so). 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. What's your opinion on this? Giacomo
Re: FRR package in Debian violates the GPL licence
> My understanding is that those files in themselves are not derivative > works of GPLed source code, but the entire FRR project is. At least, > that's the judgment of the project in > https://github.com/FRRouting/frr/issues/1923 For the record, with both my hats as the Debian maintainer for the frr source package as well as a TSC member on the FRRouting project, I would like to note that this is indeed my/our understanding of our licensing situation. We expressly acknowledge that FRR binary packages must be distributed in their entirety under GPLv2 or newer, and this is what I thought is indicated in the Debian package too. (If I have messed that up, I sincerely apologize and will fix that as soon as possible - please point me in the appropriate direction.) We do not believe any of the _source_code_ in ldpd or babeld is derivative of Quagga (or other) GPL source code. The respective original authors have expressed and reaffirmed their wishes for the code to remain under a permissive license. While we could obviously just slap GPL on top, we have decided to try and honour the original author's requests. We would also have liked to comply with Paul's wishes as an author on Quagga. However, since the two are mutually exclusive, and Paul's wishes are applying to other people's code while ldpd & babeld are about the respective author's wishes for their own code, the latter seemed the more appropriate choice. As we don't understand the code in question to be derivative, we don't see a legal obligation in this choice. Cheers, -David P.S.: please Cc: me as I'm not subscribed to debian-legal.
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, Paul Jakma wrote: > 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. That's in the binary package and source package that Debian distributes; we don't distribute files separately. > I am going to stick with the legal advice I have received, including > from a solicitor specialising in copyright, over the belief of someone > with no qualifications in this area and no experience other than > having read some stuff on the Internet. This *is* debian-legal; if anything anyone said here was actually qualified legal advice, it wouldn't be given in this forum. It certainly wouldn't be given by me. Since there's not much more debian-legal can do for you, please seek out a resource with legal representation like the Software Freedom Conservancy who has expertise in copyright law and its application to free software/open source. Best of luck. -- Don Armstrong https://www.donarmstrong.com The solution to a problem changes the problem. -- Peer's Law
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, Paul Jakma wrote: > The GPL stipulates that the distributor must "appropriately publish on > each copy an appropriate copyright notice". Debian does, in /usr/share/doc/frr/copyright. > This is very deliberate, as FRR denies the applicablility of the GPL > to those files, even though these files are dependent on the GPL > source code for function and comprehension and these files are derived > works of the GPL source code, according to legal advice. My understanding is that those files in themselves are not derivative works of GPLed source code, but the entire FRR project is. At least, that's the judgment of the project in https://github.com/FRRouting/frr/issues/1923 > The Debian project can not magically grant itself a GPL licence for > this infringing code, when the FRR project have none to give. As long as Debian is complying with the GPL, whether the FRR project is or is not complying is irrelevant according to GPL-2 §4: parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. I'm afraid that the underlying issue here is a dispute between the Quagga project and the FRR fork of the Quagga project;[1] Debian isn't a party to this dispute, and it's not Debian's job to choose a winner. I hope that the parties to the dispute will compete on the merits or even better, collaborate in the future. Best of luck. 1: https://lists.quagga.net/pipermail/quagga-users/2017-August/014815.html -- Don Armstrong https://www.donarmstrong.com life's not a paragraph And death i think is no parenthesis -- e.e. cummings "Four VII" _is 5_
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.
Re: FRR package in Debian violates the GPL licence
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. > It is - I am advised - not permitted by the GPL and infringing of my > copyright in thise code-base, and also incitement to commit copyright > infringement. As such, the termination clause of the GPL became > applicable to FRR. The termination clause of the GPL applies to entities who are redistributing FRR not to the code base in general; as Debian redistributes in compliance with the GPL (and presumably the FRR project on github does as well), Debian hasn't activated GPL-2 §4. I suggest reaching out to Richard Fontana (or your own legal representation) if any of this is unclear; https://github.com/FRRouting/frr/issues/1923 has the start of covering some of this. 1: Or at least, we should be; if not, please file the bug so it can be fixed. -- Don Armstrong https://www.donarmstrong.com The game of science is, in principle, without end. He who decides one day that scientific statements do not call for any further test, and that they can be regarded as finally verified, retires from the game. -- Sir Karl Popper _The Logic of Scientific Discovery_ §11
Re: FRR package in Debian violates the GPL licence
Hi Paul, On Sat, 16 Mar 2019 at 14:19, Paul Jakma wrote: > It is - I am advised - not permitted by the GPL and infringing of my > copyright in thise code-base, and also incitement to commit copyright > infringement. As such, the termination clause of the GPL became > applicable to FRR. > > Use and distribution is unlicensed. I’m afraid your understanding of how the GPL works is incorrect. -- Cheers, Andrej
