Re: [Fedora-legal-list] Re: The license of OpenMotif (Open Group Public License)
On Mon, Mar 18, 2019 at 9:11 PM Richard Fontana wrote: > , and it's possible to read it as prohibting, for example, running Open >> Motif on a privately-modified version of Debian or Fedora. >> > > Richard > > Or more applicably to the modern world, perhaps running it in a Docker container that happens to be running on WSL (Windows Subsystem for Linux) would be problematic since the underlying kernel is not open source? To answer a question earlier in the thread, I firmly believe that such usage must be allowed (especially as it involves no "porting" of any nature) in order to qualify as free software.
Re: [Fedora-legal-list] The license of OpenMotif (Open Group Public License)
> > On Sat, Oct 27, 2018 at 3:36 AM Florian Weimer wrote: > > > Is it necessary that an open source license must allow porting to > > proprietary systems? I don't think so today. But based on what I > > found out about the OpenMotif license, people actually thought that > > back then. This surprises me. Has this changed? I'm not sure if this was at all a concern in the past, but the license is confusing in how it states the "open source" operating system limitation, and it's possible to read it as prohibting, for example, running Open Motif on a privately-modified version of Debian or Fedora. Richard
Re: FRR package in Debian violates the GPL
On Mon, Mar 18, 2019 at 7:36 PM David Lamparter wrote: > Huh. This is slightly surprising to me, I thought binaries always need > a license attached too. But now that I think about it, indeed I don't > even know how I would get a license "label" for a random binary .deb... > (as you say, the shipped copyright file documents its sources...) There is a debhelper feature that lets you put different copyright files into each binary package. I've used it in the past where a utils package had a different license to the library package. We certainly don't systematically do this, as there is simply no way to determine what file in the binary package is derived from what file(s) in the source package and what command produced them. -- bye, pabs https://wiki.debian.org/PaulWise
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
> > We expressly acknowledge that FRR binary packages must be > > distributed in their entirety under GPLv2 or newer, and this is what > > I thought is indicated in the Debian package too. > > Debian does not attach *any* license to a binary package. Huh. This is slightly surprising to me, I thought binaries always need a license attached too. But now that I think about it, indeed I don't even know how I would get a license "label" for a random binary .deb... (as you say, the shipped copyright file documents its sources...) > It just documents the licenses of the sources. There is however no way > (except carefully going through the [documented] build process) to > find out, under which conditions a binary files can be > used/(re)distributed/modified. Well. Presumably that should yield the same result. Either way I'll add some extra comments/docs. Cheers, -David
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.
