Re: Missing source in firefox-esr: EME module
❦ 4 juin 2019 15:23 -04, Nat Tuck : > The firefox-esr package in Buster includes the encrypted media > extension functionality, which relies on library called "wildvine". > Source for this library is not included in the firefox-esr source > package. Encrypted Media Extensions are also needed to play free content. Implementations of HLS and MPEG-DASH both need these extensions. -- Use the fundamental control flow constructs. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
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: Source files
❦ 15 octobre 2015 10:26 +1100, Ben Finney : >> > I am personally convinced that nowadays the definition of source >> > should *no longer* be regarded as an open question: I think that the >> > most commonly used and accepted definition of source code is the one >> > found in the GNU GPL license. >> >> It is a commonly used and accepted definition, but as evidenced by >> this conversation and the others which have occurred on Debian >> recently, it is too vague to be easily applied. > > That's not true. There are many cases that are clarified by that > definition, to the point of clear resolution. The recent discussions on debian-devel@ shows that not everybody agree with this definition. Notably, several persons think the source code for one project should depend on the user, not on the developer. -- Write clearly - don't be too clever. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Python GPL-3+ program w/o OpenSSL exception using python-requests
❦ 18 janvier 2015 12:16 +0100, "W. Martin Borgert" : >> Then as is, the software can't go into Debian. Maybe you could try >> contacting upstream to ask them for an OpenSSL exception? > > Upstream has been contacted. So far they seem to think, that > this is a Debian internal issue and don't want to add anything > to their license (GPL-3+). I'll try again. From: https://www.gnu.org/licenses/quick-guide-gplv3.html > GPLv3 has adjusted the definition of System Library to include > software that may not come directly with the operating system, but > that all users of the software can reasonably be expected to have. For > example, it now also includes the standard libraries of common > programming languages such as Python and Ruby. Of course, in the actual license, there is no word about "Python". -- question = ( to ) ? be : ! be; -- Wm. Shakespeare signature.asc Description: PGP signature
Re: Python GPL-3+ program w/o OpenSSL exception using python-requests
❦ 17 janvier 2015 19:14 +0100, "W. Martin Borgert" : > sorry, if this question has been discussed before. > Python program or library "X" is licensed under GPL3+ without > OpenSSL exception. "X" does use the python-requests library, > which on load dynamically links the Python interpreter with the > OpenSSL library. This is "X": A close issue has already been discussed [1] but it was mostly ignored. Doing "import readline" and "import ssl" triggers the problem without introducing a third-party program. Running "python" interactively loads the "readline" module. Just typing "import ssl" here is a license violation. Running "ipython" loads both "readline" and "ssl" module. My conclusion is that if you have a GPL program importing the "ssl" module, you can ignore the licensing issue on either the ground that nobody really cares or the fact that OpenSSL should be considered as a system library (and this is easier with GPLv3 than it was with GPLv2). [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498857 -- Let the machine do the dirty work. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Perforce distribution license
❦ 9 mai 2014 11:26 -0700, Walter Landry : > I do not see any permission to redistribute. Many organizations want > to be the sole source of their software, so redistribution is not > something you should assume. So this license will not work. You > could ask Perforce to give Debian permission to distribute. Or anyone since redistribution must be allowed for anyone to be in non-free. -- Don't stop at one bug. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Lawyer request stop from downloading Debian
OoO En cette nuit nuageuse du dimanche 24 avril 2011, vers 00:07, Ken
Arromdee disait :
>> The lawyer wants the poster to pay 700 Euro and stop uploading of Debian.
>> -
>> My opion is that this behavior is not good for Debian's reputation
>> and the project should take legal action against the lawyer and this
>> company.
> It's my understanding that in Germany lawyers can do this to copyright
> violators even though they are not the copyright holder. And it's very likely
> he's a copyright violator, so there's not much Debian can do. No, really.
> The GPL V2 requires that if you distribute, you either
> a) accompany a binary with the source code
> b) accompany it with a written offer to give everyone a copy of the source
> code for three years, or
> c) accompany it with an offer to distribute source code, if it's noncommercial
> distribution and you received the program inder b).
> It's very unlikely that b or c applies, and most people who torrent Linux
> don't put a copy of the source code in the torrent, so a is unlikely. The
> problem is that on Bittorrent, everyone who downloads also uploads. This
> makes it illegal to download just a binary, since if you do that you're also
> uploading just a binary, and uploading just a binary is a form of distribution
> the GPL doesn't allow.
In the case of Debian distribution, the source code is available at
http://www.debian.org which fullfils section a) since it is a "medium
customarily used for software interchange".
--
printk("Cool stuff's happening!\n")
2.4.3 linux/fs/jffs/intrep.c
pgpNiQvwU3Ywr.pgp
Description: PGP signature
Re: Bug#498477: GPL-compatiblity of python licenses
OoO Pendant le temps de midi du dimanche 28 septembre 2008, vers 12:45, Matthias Klose <[EMAIL PROTECTED]> disait : > severity 498857 important > severity 498477 important > thanks >> I don't know the real implication on the license > if you're unsure then don't make it RC in the first place There *is* a licensing problem that should be solved by at least by fixing debian/copyright. This is a RC bug (policy violation, doesn't respect DFSG by requiring the user to be bound to additional license terms, i.e GPL ones). You are hiding the problem by downgrading severity. What I am not sure of is that mixing GPL licensed code and OpenSSL derived code prevent Python to be distributed in this form or just programs using both pieces of code to be distributed. -- I AM NOT A LICENSED HAIRSTYLIST I AM NOT A LICENSED HAIRSTYLIST I AM NOT A LICENSED HAIRSTYLIST -+- Bart Simpson on chalkboard in episode AABF04 pgp6cGX9YPGUT.pgp Description: PGP signature
Re: GPL-compatiblity of python licenses
reopen 498857 reopen 498477 thanks OoO En cette nuit nuageuse du vendredi 19 septembre 2008, vers 00:53, Thomas Viehmann <[EMAIL PROTECTED]> disait : > Hi Vincent, > thanks for looking into licensing issues in Debian. > How exactly is the python license GPL-incompatible? > If you scroll down a screen or two on the license[1] and move your > attention to the right column, you will find the assertion that all > recent versions of python have a GPL-compatible license, even indicating > where the FSF's opinion differs from the python copyright holders. > In particular, all python versions from oldstable onwards are > undisputedly GPL-compatible. Hi Thomas! I did not say that python license is GPL-incompatible. There are two problems: - the fact that readline.so module is linked to GNU Readline is not mentioned in debian/copyright where it should because if the user uses this module in some non-GPL work and distribute it, it will break GPL because GNU Readline is GPL. - _ssl.so is linked with OpenSSL and hence is incompatible with GPL without an exception that is not granted in GNU Readline. Therefore, a program cannot be linked to both readline.so and _ssl.so. GPL compatibility only says that you can mix Python code with GPL code and get a valid GPL code (first footnote in debian/copyright highlights the meaning of "GPL compatible"). Python license is GPL compatible however not every piece of Python is licensed under Python license. debian/copyright contains some exceptions. readline.so is another exception that should be noted in debian/copyright. The rest of the world don't believe there is no problem with this. Apple removed GNU Readline of its Python and replaced it with editline (which causes some incompatibilities). About the second problem, as both readline.so and _ssl.so are optional module, I am not really sure if this is a serious problem or if a note could be dropped in debian/copyright about the fact that a program using both _ssl.so and readline.so cannot be distributed. I am putting debian-legal@ in copy to those bugs to get some additional insights on this matter. I am not a lawyer. -- I WILL NOT AIM FOR THE HEAD I WILL NOT AIM FOR THE HEAD I WILL NOT AIM FOR THE HEAD -+- Bart Simpson on chalkboard in episode 8F13 pgpxwFa3GpQBd.pgp Description: PGP signature
Re: Is AGPLv3 DFSG-free?
OoO En cette fin de nuit blanche du samedi 16 août 2008, vers 06:47, "Miriam Ruiz" <[EMAIL PROTECTED]> disait : > Do you think AGPLv3 is DFSG-free? Hi Miriam! Some discussions have already taken place here. The outcome was AGPLv3 was not DFSG free, but it wasn't really a sharp statement. See for example: http://www.mail-archive.com/debian-legal@lists.debian.org/msg38650.html Since I was not convinced, I was planning to upload clipperz, an AGPLv3 licensed password manager and let ftp-masters decide if AGPLv3 is OK for Debian. Unfortunately, there is another licensing problem (GPLv2 only files) with it and I did not upload it. I am not aware of software already in Debian and licensed with AGPLv3. -- I WILL NOT CARVE GODS I WILL NOT CARVE GODS I WILL NOT CARVE GODS -+- Bart Simpson on chalkboard in episode 8F11 pgpi9vWmnuNth.pgp Description: PGP signature
Re: Should copyright information for automake generated files be added to debian/copyright?
OoO Pendant le repas du lundi 12 mai 2008, vers 19:03, Evgeni Golov <[EMAIL PROTECTED]> disait: > I have adopted some packages (unshield, dynamite, orange) and while I > looked for a sponsor on debian-mentors, Vincent Bernat said, I should > include the copyright of "ltmain.sh and all other generated files". > For unshield that would be a couple of Makefile.in, aclocal.m4, > config.guess, config.rpath, config.sub, configure, depcomp, install-sh, > ltmain.sh and missing. Since you get no answer, this seems to be a gray area. If nobody disagrees, for better readibility of debian/copyright, I think that you may ignore those files. -- Arrêtez de poster des AAD, cela encombre le forum. -+- EN in: Guide du Cabaliste Usenet - fufer en nettoyant -+- pgpxexqPg3WxB.pgp Description: PGP signature
About AGPLv3
Hi! AGPLv3 license has been discussed in this list some time ago: http://lists.debian.org/debian-legal/2007/11/msg00232.html However, no final conclusion was drawn. Would a web application licensed with AGPLv3 meet DFSG conditions? Thanks. -- Don't comment bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Nikto license on data files
OoO Peu avant le début de l'après-midi du samedi 05 avril 2008, vers 13:00, "Paul Wise" <[EMAIL PROTECTED]> disait: > First try to get the data licence fixed upstream. Unfortunately, upstream does not want to relicense those files yet. Therefore, I have prepared an upload for non-free. -- Don't over-comment. - The Elements of Programming Style (Kernighan & Plauger) pgpT2OHOY4IPc.pgp Description: PGP signature
Re: Nikto license on data files
OoO Peu avant le début de l'après-midi du samedi 05 avril 2008, vers 13:00, "Paul Wise" <[EMAIL PROTECTED]> disait: > First try to get the data licence fixed upstream. I have sent him a mail about this matter. > If that doesn't work, either put it in non-free or strip the non-free > data and put it in contrib. You cannot put a non-free orig.tar.gz in > main. OK. Another question: nikto has been removed but is still present in stable. It contains the same non-free data. Since the package has been orphaned, who should I contact about this? ftp-master? Thanks. -- BOFH excuse #126: it has Intel Inside -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Nikto license on data files
Hi! Nikto is a security web scanner licensed under GPLv2 only. It was orphaned some time ago and I am packaging the new upstream version. http://packages.qa.debian.org/n/nikto.html While nikto.pl (the executable) is licensed under GPLv2, the data files that are used have a pretty restrictive license: # This file may only be distributed and used with the full Nikto package. # This file may not be used with any software product without written permission from cirt.net. # (c) 2001-2005 cirt.net, All Rights Reserved # By sending any database updates to cirt.net, it is assumed that you # grant cirt.net the unlimited, non-exclusive right to reuse, modify and relicense the changes. I can still put it in non-free but can I leave it in main, providing I don't ship (in the binary package) files with the restrictive license. nikto will then be unusable but the user can retrieve the files by himself using "nikto -update" command (and I will explain this in README.Debian, with a message in postinst and with a message when launching nikto.pl). In this case, can I leave those files in the orig.tar.gz or should it be repackaged? Or will I need to put it in contrib (because it cannot work without the non-free stuff)? Thanks for any insight on this matter. -- BOFH excuse #176: vapors from evaporating sticky-note adhesives pgpHDrOzc8bOt.pgp Description: PGP signature
