Re: Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work
On Sat, Jul 11, 2020 at 03:36:04PM +0200, Francesco Poli wrote: > On Fri, 10 Jul 2020 18:33:32 -0400 Nicholas D Steeves wrote: >... > Well, as far as I can say, the 4-clause BSD license is considered > acceptable for Debian main. > It is also [considered] a free software license by the FSF, although it > is considered GPL-incompatible, ugly and strongly recommended against > (for people who are choosing a license to release new software under). >... > It would therefore be safer to not include 4-clause BSD licensed > material in a package where other parts (or libraries) are under the > GNU GPL. The main point here is that there is no legal problem that needs fixing, so let's not use words like "safer" that would imply otherwise. I am not disputing the "ugly and strongly recommended against". >... > • try and get in touch with OmniTI Computer Consulting and persuade >them to re-license the dprof2calltree converter under the terms of >the 3-clause BSD license (which does not include the deprecated OAC >and is indeed GPL-compatible), but persuade them on the ground of >GPL-incompatibility, deprecation, and practical issues of the OAC >(not on the ground of a DFSG-freeness issue, since there is no such >issue!) OmniTI was bought by credativ, if anyone thinks it is worth the effort they do employ some DDs. > • try and find a GPL-compatible replacement for dprof2calltree >... These are 2 scripts with a combined 350 LOC, if anyone really cares it is likely fastest to rewrite from scratch. cu Adrian
Re: Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work
On Fri, Jul 10, 2020 at 07:48:31PM -0400, Nicholas D Steeves wrote: > Hi Adrian, Hi Nicholas, >... > Did you read the text at that link? yes. > "it *does* cause practical > problems, including incompatibility with the GNU GPL [emphasis mine]" DFSG free code does not have to be GPL compatible. >... > Were you to provide proof from a legal team that the BSD-4-clause was > somehow GPL-compatible, GPL compatibility is only relevant for for code linked with GPLed code. I fail to see how it would be relevant for the code in question.[1] GPL-incompatible licencing of software like OpenSSL is not a DFSG problem, only a practical problem. > it would still not be DFSG-free, because it > fails the "desert island test" for snail mail. Were OmniTI Computer > Consulting would accept email, it would also fail the "dissident test". This is the first time I see someone claiming BSD-4-clause would not be distributable. > Finally, BSD-4-clause is not an approved license in KDE projects > https://community.kde.org/Policies/Licensing_Policy Policies for new source code added in KDE are not relevant in Debian. > Feel free to escalate this issue...I'm humble and am comfortable with > being shown the error of my ways, but I believe this is a genuine > problem. Yes, it would be good if other people from debian-legal would comment. > Regards, > Nicholas cu Adrian [1] https://sources.debian.org/src/kcachegrind/4:19.08.1-1/converters/dprof2calltree/
Re: Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work
On Fri, Jul 10, 2020 at 06:33:32PM -0400, Nicholas D Steeves wrote: > Hi Adrian, > > Adrian Bunk writes: > > > On Fri, Jul 10, 2020 at 03:38:57PM -0400, Nicholas D Steeves wrote: > >>... > >> * Neither name of the company nor the names of its contributors may be > >> used to endorse or promote products derived from this software without > >> specific prior written permission. > >> > >> I'm not 100% certain that bundling dprof2calltree with kcachegrind > >> constitutes a "product[s] derived from this software", because I'm also of > >> the opinion that bundling != derivation, but it seems like a lawyer might > >> argue the it does. So kcachegrind and any distributions' package would > >> also need written persmission from OmniTI Computer Consulting. > >>... > > > > You are arguing the 3-Clause BSD License would be non-free? > > No, because dprof2calltree is modified 4-Clause BSD. dprof2calltree uses a verbatim copy of 4-Clause BSD (except for filling the company placeholders). This clause is one of the 3 clauses that are identical in 3-clause and 4-clause BSD. > > On Fri, Jul 10, 2020 at 03:53:48PM -0400, Nicholas D Steeves wrote: > >>... > >> At the very least, it appears that the advertising clauses make > >> dprof2calltree not DFSG-free, > > > > It does not: > > https://www.debian.org/legal/licenses/ > > > >> because they fail the "desert island test". > >>... > > > > It does not. > > > > If you choose to advertise the use of this software on your desert > > island, you have to include the acknowledgement in your advertisement. > > It fails the "desert island test" because > > 1. Any mention of the features or use of this software requires > user-facing display of the text "This product includes software > developed by OmniTI Computer Consulting". > > 2. OmniTI Computer Consulting's name cannot be used to "without specific > prior written permission" > > The desert island does not have the paper snailmail service required to > fulfil #2 (4th clause of the license). The 4-clause BSD license is around for 30 years, everyone else (including the FSF[1]) does not interpret it the way you do that there would be a conflict between these two clauses. > Regards, > Nicholas cu Adrian [1] https://www.gnu.org/licenses/license-list.html#OriginalBSD
Re: Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work
On Fri, Jul 10, 2020 at 03:38:57PM -0400, Nicholas D Steeves wrote: >... > * Neither name of the company nor the names of its contributors may be used > to endorse or promote products derived from this software without specific > prior written permission. > > I'm not 100% certain that bundling dprof2calltree with kcachegrind > constitutes a "product[s] derived from this software", because I'm also of > the opinion that bundling != derivation, but it seems like a lawyer might > argue the it does. So kcachegrind and any distributions' package would also > need written persmission from OmniTI Computer Consulting. >... You are arguing the 3-Clause BSD License would be non-free? On Fri, Jul 10, 2020 at 03:53:48PM -0400, Nicholas D Steeves wrote: >... > At the very least, it appears that the advertising clauses make > dprof2calltree not DFSG-free, It does not: https://www.debian.org/legal/licenses/ > because they fail the "desert island test". >... It does not. If you choose to advertise the use of this software on your desert island, you have to include the acknowledgement in your advertisement. cu Adrian
Bug#737395: funny-manpages: Copyright problem
Package: funny-manpages Version: 1.3-5 Severity: serious The contents of /usr/share/doc/funny-manpages/copyright does not at all look as if the package would be DFSG-free: -- snip -- This package was debianized by Pawel Wiecek co...@pwr.wroc.pl on Wed, 10 Dec 1997 01:10:17 +0100. This set of manpages was collected from all over the net. No specific location can be given. Copyright: To the best of my knowledge all of these manpages are free to use and redistribute. The authors are: baby.1fun - unknown, based on man page by Joe Beck b...@cs.ualberta.ca celibacy.1fun - unknown condom.1fun - Ken Maupin mau...@cs.washington.edu flame.1fun - unknown flog.1fun - unknown gong.1fun - unknown grope.1fun - unknown party.1fun - unknown rescrog.1fun- unknown rtfm.1fun - unknown sex.1fun- unknown tm.1fun - unknown xlart.1fun - James McPherson date.1fun - Glen Overby ove...@sendit.nodak.edu echo.1fun - unknown rm.1fun - Matthew Farwell dy...@ibmpcug.co.uk strfry.3fun - ch...@druco.att.com xkill.1fun - Claudio Calvelli clau...@edinburgh.ac.uk uubp.1fun - unknown -- snip -- -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140202125609.23331.99631.reportbug@localhost
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
[ lintian maintainer added to Cc ] On Sat, Apr 04, 2009 at 11:43:53AM +0200, Cristian Greco wrote: On Sat, Apr 04, 2009 at 12:00:56PM +0800, LI Daobing wrote: On Sat, Apr 4, 2009 at 05:06, Cristian Greco cristian.deb...@gmail.com wrote: [ CCing debian-legal for comments ] On Fri, Apr 03, 2009 at 10:37:49PM +0300, Adrian Bunk wrote: The libcurl case might be easy to resolve, but I don't know anything about the libtorrent-rasterbar. It might be required that you get all copyright holders to agree on a licence exception. The point is that qbittorrent doesn't directly link against libssl and the source code doesn't really use that library. Is it really necessary to add the exception? I'm not sure if the executable linking is caused by libtorrent-rasterbar (BSD code linked against libssl) or some other required libraries/headers. In the former case, if linking is caused by the torrent library, all of its clients should add such exception. My thought is that qbittorrent shouldn't be affected by this problem because it doesn't really link against libssl. And BTW, the source code includes licenses such as LGPL, BSD and MIT, so it shouldn't need the exception anyway. I think it need an exception. GPL licensed code and OpenSSL licensed code should not run in the same process. I can confirm that linking against libssl is caused by libtorrent-rasterbar, which is compiled with encryption support and causes inclusion of some OpenSSL headers. I'm wondering: ... 2) Why doesn't lintian complain about the exception if the source code contains GPL + another different license (this is the case with qbittorrent)? First of all, please try to understand the differences between the following completely different cases: - program with different licences, that effectively mean the whole program is licenced under one specific licence (e.g. combining BSD and GPL licenced code results in the program being GPL licenced) - package contains different programs under different licences - dual-licenced code Why lintian doesn't find these cases: - Catching some of the simpler cases is not too hard. Handling all details of existing open source licencing would be very hard. - As far as I understand the code in lintian, it only parses the dependency information of the package. That would have worked for indirect dependencies 10 years ago when dependencies were created using ldd, but indirect dependencies cannot be found this way today. But lintian is anyway just a tool to find some errors, it can never be used to prove that a package is correct. Thanks, cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why is OpenSSL not in non-free?
On Thu, Feb 26, 2009 at 01:36:29PM +, MJ Ray wrote: Adrian Bunk b...@stusta.de wrote: Could someone update http://wiki.debian.org/DFSGLicenses and http://www.debian.org/legal/licenses/ accordingly? Currently both pages sound as if it the 4-clause BSD licence would not meet the DFSG. I'd happily update http://www.debian.org/legal/licenses/ but I can't see how it makes it sounds as if 4-clause BSD wouldn't meet DFSG. Can you clarify? -- snip -- This site presents the opinion of debian-legal contributors on how certain licenses follow the Debian Free Software Guidelines (DFSG). ... Licenses currently found in Debian main include: ... - Modified BSD License ... -- snip -- This excludes the unmodified BSD License. If the 4-clause BDS License is considered to meet the DFSG, then this should be something like 4-clause, 3-clause and 2-clause BSD License. Or just BSD License. I don't want to encourage it because it has practical problems when combined with the GPLs, but it's OK for main. The encouragement is already split from the listing of what is considered to meet the DFSG below. In we encourage most maintainers to use one of the common licenses: GPL, LGPL, BSD, or Artistic you can change the BSD to something like 3-clause or 2-clause BSD. I can't update http://wiki.debian.org/DFSGLicenses well and everyone should be very reluctant to use an unattributed wiki as a primary source. I didn't find much there about 4-clause BSD either, really. ... -- snip -- === The Big DFSG-compatible Licenses ... == The 3-clause BSD License ... (This is distinct from the original, 4-clause BSD license that included an advertising requirement. The original license is now deprecated even by the BSD project.) ... -- snip -- That's the only mentioning of it. Either the 3-clause restriction should there be dropped, or the 4-clause BSD License should be listed separately (e.g. under Minor DFSG-Capable Licenses). cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Why is OpenSSL not in non-free?
- the 3-clause BSD license is considered free - the 4-clause BSD license with the advertising clause is considered non-free - both the OpenSSL License and the Original SSLeay License in /usr/share/doc/libssl0.9.8/copyright contain the BSD advertising clause in its exact wording Does OpenSSL have to go to non-free, or do I miss anything? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why is OpenSSL not in non-free?
On Wed, Feb 25, 2009 at 12:23:56PM +0100, Josselin Mouette wrote: Le mercredi 25 février 2009 à 12:46 +0200, Adrian Bunk a écrit : - the 4-clause BSD license with the advertising clause is considered non-free No. Ah, OK. Could someone update http://wiki.debian.org/DFSGLicenses and http://www.debian.org/legal/licenses/ accordingly? Currently both pages sound as if it the 4-clause BSD licence would not meet the DFSG. Even the FSF considers it free. The FSF also considers the GFDL with invariant sections as free... cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Inconsistent handling of sourceless packages in main
On Thu, May 19, 2005 at 10:12:43AM +0200, Goswin von Brederlow wrote: ... And all have problems: package | danger -+-- kernel-image*| kernel-source* update replaces source | rebuild differs | but old version is retrievable through included patches ... Silly question: Is e.g. kernel-source-2.6.8 2.6.8-15 in sarge really sufficient to satisfy the GPL requirements for kernel-image-2.6.8-sparc 2.6.8-6 in sarge built against kernel-source-2.6.8 2.6.8-11? IANAL, but I'd have said this was a violation GPL section 3 . MfG Goswin cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 08:31:22PM -0400, Raul Miller wrote: On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote: If Debian was at least consistent. Why has Debian a much more liberal interpretation of MP3 patent issues than RedHat? It's impossible to treat patents consistently. The U.S. patent office, at least, has granted patents on natural laws, on stuff that's already patented, on stuff with clear prior art, on trivial math operations and so on. Patents are being granted so quickly there's no way of even knowing what's patented. Or were you hoping that Debian would follow Red Hat's lead? Even RedHat with a stronger financial background than Debian considered the MP3 patents being serious enough to remove MP3 support. Yes, Debian can choose to put a higher risk on their distributors and mirrors - there's nothing wrong with this. Note that this is a respose to Josselin's statement: -- snip -- When there are several possible interpretations, you have to pick up the more conservative one, as it's not up to us to make the interpretation, but to a court. -- snip -- It's simply silly to be extremely picky on copyright issues while being extremely liberal on patent issues - the risk of a Debian distributor being sued for patent violations (no matter how the lawsuit might end) is definitely present. As for this particular patent, I'm not really sure what's being patented. ... Which one of the 23 patents they list do you call this particular patent? Raul cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 08:54:40AM +0200, Sven Luther wrote: On Fri, Apr 08, 2005 at 02:31:36AM +0200, Adrian Bunk wrote: On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote: On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: ... If your statement was true that Debian must take more care regarding legal risks than commercial distributions, can you explain why Debian exposes the legal risks of distributing software capable of decoding MP3's to all of it's mirrors? I don't know and don't really care. I don't maintain any mp3 player (err, actually i do, i package quark, but use it mostly to play .oggs, maybe i should think twice about this now that you made me aware of it), but in any case, i am part of the debian kernel maintainer team, and as such have a responsability to get those packages uploaded and past the screening of the ftp-masters. I believe the planned solution is vastly superior to the current one of simply removing said firmware blobs from the drivers, which caused more harm than helped, which is why we are set to clarifying this for the post-sarge kernels. Debian doesn't seem to care much about the possible legal problems of patents. patents are problematic, and upto recently there where no software patents in europe, so i don't really care. I am not sure about the details of the above problem you mention, could you provide me some link to the problem at hand. I http://www.mp3licensing.com/ The patent problems in the USA alone should impose enough legal risks. IANAL, but even RedHat considers them to be serious problems. And note that most of their patents are also valid in the EU. If they are enforcible is a different question, but it might be enough to become a legal risk that a lawsuit might be started against e.g. a mirror. also believe that in the larger scheme restriction of this kind, as is the US restriction on distribution to cuba and everything else, is not-right and even immoral, and *I* personally would fight back if i was ever sued for such things, and there may be higher courts involved than just the US judicial system, which is for sale anyway, where redhat is dependent on. I cannot talk Which court is higher ... than just the US judicial system? If you are in the USA, there's no legal instance between the US supreme court and god. about the whole of debian on this though, and i feel it is for someone else to tackle and handle. If you feel strongly about this, you are free to go take it over with whoever handles this, post to debian-legal and debian-project about it, and help get the issue solved. (/me believes such restrictions of the above are a violation of the elemental human rights to go where one wants and run what operating system on wants). ... Unfortunately, life isn't fair. It's Debian's choice how cautiously or brave they are regarding legal risks. But it has to be consistent. Debian simply needs an overall policy for this. But if you say that you want to avoid any legal risks in one area while saying these are not my packages about perhaps even more likely legal risks in other areas doesn't help anyone. Friendly, Sven Luther cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 09:22:00AM +0200, Josselin Mouette wrote: Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit : You are mixing apples and oranges. The fact that the GFDL sucks has nothing to do with the firmware issue. With the current situation of firmwares in the kernel, it is illegal to redistribute binary images of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still be willing to distribute such binary images, but it isn't our problem. It's a grey area. debian-legal did pick one of the possible opinions on this matter. When there are several possible interpretations, you have to pick up the more conservative one, as it's not up to us to make the interpretation, but to a court. If Debian was at least consistent. Why has Debian a much more liberal interpretation of MP3 patent issues than RedHat? ... Instead of babbling, some people have started to discuss this with upstream, and are trying to come up with a GPLed documentation for GCC. This is much more constructive than repeating again and again Bleh, Debian are a bunch of bigots who don't care of the compiler being documented. Will the replacement documentation for all affected software be available before the GFDL documentation gets removed? At least theoretically, the users are a priority for Debian equally to free software. Is it true, that Debian will leave users with hardware affected by the firmware problem without a working installer in Debian 3.1? The case of hardware really needing a firwmare to work *and* needed at installation time is rare. I've only heard of some tg3-based cards. Most of them will work without the firmware, and for the few remaining ones, it only means network installation won't work. How do you install Debian on a harddisk behind a SCSI controller who's driver was removed from the Debian kernels due to it's firmware? The point is simply, that Debian does more and more look dogmatic at it's definition of free software without caring about the effects to it's users. Being careless in the definition of free software is a real disservice to users. It makes them rely on e.g. non-free documentation for everyday use. ... Documentation is software? Non-free documentation is better than no documentation. Non-free software has several problems, but some of them like the right to do modifications are less important for documentation, since e.g. fixes for security bugs are not an issue. Removing the available documentation without an equal replacement is a real disserve for your users. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 07:42:51PM +0200, Josselin Mouette wrote: Le vendredi 08 avril 2005 à 19:34 +0200, Adrian Bunk a écrit : When there are several possible interpretations, you have to pick up the more conservative one, as it's not up to us to make the interpretation, but to a court. If Debian was at least consistent. Why has Debian a much more liberal interpretation of MP3 patent issues than RedHat? Because we already know that patents on MP3 decoders are not enforceable. Furthermore, the holders of these patents have repeatedly How do you know the patents aren't enforceable? stated they won't ask for fees on MP3 decoders. http://www.mp3licensing.com/royalty/index.html talks about 0.75 Dollar for a decoder. How do you install Debian on a harddisk behind a SCSI controller who's driver was removed from the Debian kernels due to it's firmware? Which SCSI controller are you talking about? Quoting README.Debian of the Debian kernel sources: -- snip -- * QLA2XXX firmware, driver disabled: . drivers/scsi/qla2xxx/*_fw.c -- snip -- There are a few other SCSI controllers where even the Debian kernel sources still ship both the drivers and the firmware. I do not claim to understand the latter... Being careless in the definition of free software is a real disservice to users. It makes them rely on e.g. non-free documentation for everyday use. ... Documentation is software? Sure. Every book in my book shelf is software? That doesn't match how people outside of Debian use the word software. Non-free documentation is better than no documentation. Non-free software has several problems, but some of them like the right to do modifications are less important for documentation, since e.g. fixes for security bugs are not an issue. Removing the available documentation without an equal replacement is a real disserve for your users. GFDL documentation will still be available in the non-free archive. Assuming you have an online connection and a friend told you how to manually edit your /etc/apt/sources.list for non-free. But where's the documentation if you don't have an online connection but only the dozen binary CDs of Debian? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 03:57:01PM +0200, Sven Luther wrote: ... The other point is that other entities, like redhat, or suse (which is now novel and thus ibm) and so have stronger backbones, and can more easily muster the ressources to fight of a legal case, even one which is a dubious one, especially given the particularities of the US judicial system, where it is less important to be right, and more important to have lot of money to throw at your legal machine. Debian has nothing such, and SPI which would stand for this, is not really upto it either, so in this case, apart from all ideology and fanatism, it is for purely pragmatic reasons that they don't distribute undistributable files from the non-free part of our archive. You would do the same in their case. ... There are many possible legal risks for a Linux distribution. This thread is about one. Another one is that RedHat removed MP3 support in their distribution from programs like xmms ages ago because of the legal risks due to patents. The Debian distribution still contains software that is capable of playing MP3's. I'd say of the two above cases, the MP3 patents are far more likely to cause a lawsuit. YMMV. If your statement was true that Debian must take more care regarding legal risks than commercial distributions, can you explain why Debian exposes the legal risks of distributing software capable of decoding MP3's to all of it's mirrors? Friendly, Sven Luther cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote: Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit : On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote: On Apr 04, Greg KH [EMAIL PROTECTED] wrote: What if we don't want to do so? I know I personally posted a solution Then probably the extremists in Debian will manage to kill your driver, like they did with tg3 and others. And as they are doing with e.g. the complete gcc documentation. No documentation for the C compiler (not even a documentation of the options) will be neither fun for the users of Debian nor for the Debian maintainers - but it's the future of Debian... You are mixing apples and oranges. The fact that the GFDL sucks has nothing to do with the firmware issue. With the current situation of firmwares in the kernel, it is illegal to redistribute binary images of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still be willing to distribute such binary images, but it isn't our problem. ... It's a grey area. debian-legal did pick one of the possible opinions on this matter. The similarities between the GFDL and the firmware discussion can be described with the following two questions: Is it true, that the removal of much of the documentation in Debian is scheduled soon because it's covered by the GFDL, that this is called an editorial change, and that Debian doesn't actually care that this will e.g. remove all documentation about available options of the standard C compiler used by and shipped with Debian? Is it true, that Debian will leave users with hardware affected by the firmware problem without a working installer in Debian 3.1? The point is simply, that Debian does more and more look dogmatic at it's definition of free software without caring about the effects to it's users. As a contrast, read the discussion between Christoph and Arjan in a part of this thread how to move firmware out of kernel drivers without problems for the users. This might not happen today, but it's better for the users. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote: On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: ... If your statement was true that Debian must take more care regarding legal risks than commercial distributions, can you explain why Debian exposes the legal risks of distributing software capable of decoding MP3's to all of it's mirrors? I don't know and don't really care. I don't maintain any mp3 player (err, actually i do, i package quark, but use it mostly to play .oggs, maybe i should think twice about this now that you made me aware of it), but in any case, i am part of the debian kernel maintainer team, and as such have a responsability to get those packages uploaded and past the screening of the ftp-masters. I believe the planned solution is vastly superior to the current one of simply removing said firmware blobs from the drivers, which caused more harm than helped, which is why we are set to clarifying this for the post-sarge kernels. Debian doesn't seem to care much about the possible legal problems of patents. The firmware issues are an urgent real problem? Debian should define how much legal risk they are willing to impose on their mirrors and distributors and should act accordingly in all areas. But ignoring some areas while being more religious than RMS in other areas is simply silly. That said, i was under the understanding that after the SCO disaster, clarification of licencing issues and copyright attributions was a welcome thing here, but maybe i misunderstood those whole issues. SCO disaster? It is a disaster for SCO. Friendly, Sven Luther cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote: On Apr 04, Greg KH [EMAIL PROTECTED] wrote: What if we don't want to do so? I know I personally posted a solution Then probably the extremists in Debian will manage to kill your driver, like they did with tg3 and others. And as they are doing with e.g. the complete gcc documentation. No documentation for the C compiler (not even a documentation of the options) will be neither fun for the users of Debian nor for the Debian maintainers - but it's the future of Debian... The Debian Social Contract says: Our Priorities are Our Users and Free Software The next editorial changes to your social contract might remove the Our Users and... Seriously: There might be real problems with non-distributable firmware, but the known extremist position of Debian on such issues produces negative emotions if something like this comes from Debian. This sucks, yes. Agreed. ciao, Marco (@debian.org) cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote: On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: Mmm, probably that 2001 discussion about the keyspan firmware, right ? http://lists.debian.org/debian-legal/2001/04/msg00145.html Can you summarize the conclusion of the thread, or what you did get from it, please ? That people didn't like the inclusion of firmware, I posted how you can fix it by moving it outside of the kernel, and asked for patches. Yeah, that is a solution to it, and i also deplore that none has done the job to make it loadable from userland. For now, debian is satisfied by moving the whole modules involved to non-free, and this has already happened in part. Does this imply your installer will use these non-free modules? If the driver for the controller your harddisk is behind is not used by the installer you could simply remove these modules instead of moving them to non-free. None have come. So I refuse to listen to talk about this, as obviously, no one cares enough about this to actually fix the issue. Well, i disagree with the above analysis. The problem is not so much that the firmware violate the GPL, as it constitutes mere agregation, but that the actual copyright statement of the files containing the firmware blobs place them de-facto under the GPL, which i doubt is what was intented originally, don't you think. And *I* do care about this issue, and will follow up this issue with mails to the individual copyright holders of the file, to clarify the situation. People drag this up about once a year, so you are just following the trend... Nope, i am aiming to clarify this issue with regard to the debian kernel, so that we may be clear with ourselves, and actually ship something which is not of dubious legal standing, and that we could get sued over for GPL violation. ... If it was a GPL violation, it wasn't enough to contact only the small subset of copyright holders that worked on this specific file since this file might be compiled statically into the GPL'ed kernel. Friendly, Sven Luther cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 10:23:08PM +0200, Sven Luther wrote: On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote: On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote: On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: Mmm, probably that 2001 discussion about the keyspan firmware, right ? http://lists.debian.org/debian-legal/2001/04/msg00145.html Can you summarize the conclusion of the thread, or what you did get from it, please ? That people didn't like the inclusion of firmware, I posted how you can fix it by moving it outside of the kernel, and asked for patches. Yeah, that is a solution to it, and i also deplore that none has done the job to make it loadable from userland. For now, debian is satisfied by moving the whole modules involved to non-free, and this has already happened in part. Does this imply your installer will use these non-free modules? The installer already has provision for loading additional .udebs from floppy or net, not sure about other media, and we don't build yet non-free d-i images with those non-free modules builtin, but it could be arranged. This is post-sarge issues though, and we still have some time to solve them. If the driver for the controller your harddisk is behind is not used by the installer you could simply remove these modules instead of moving them to non-free. yeah, the problem is a whole bunch of people have tg3 network cards it seem :) I was more thinking about SCSI controllers, but tg3 is also interesting. Additional non-free d-i images will for sure be required, or several hardware setups might make installation of Debian impossible without bootstrapping through a different OS or distribution. Nope, i am aiming to clarify this issue with regard to the debian kernel, so that we may be clear with ourselves, and actually ship something which is not of dubious legal standing, and that we could get sued over for GPL violation. ... If it was a GPL violation, it wasn't enough to contact only the small subset of copyright holders that worked on this specific file since this file might be compiled statically into the GPL'ed kernel. That is not a problem, since even if the firmware is built into the same executable as the rest of the kernel code, it still constitutes only mere agregation, where the kernel is the distribution media, in the GPL sense. Please read the mail i linked too in the original mail for detailed argumentation of this. The only problem to it constituting mere agregation is that the firmware blob is not clearly identified as such in the tg3.c file (for example), and that there is no licencing condition allowing their distribution apart the GPL, which these firmware blobs where evidently not meant to be put under. This is one possible legal interpretation of mere aggregation. Whether judges in all jurisdictions of the world follow this interpretation or an interpretation of the GPL in one direction or another is the more interesting question. Friendly, Sven Luther cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#223961: libdvdread3: makes download of possibly illegal libdvdcss too easy
On Tue, Dec 16, 2003 at 09:42:43AM +0100, Andreas Metzler wrote: ... However if you copy copy-protected CD foo with program bar at home you won't be persecuted by criminal law, but the manufacturar might start private action against you, claiming compensation. Now try to apply the latter on playing a DVD with xine using libdvdcss2 instead of copying a CD, I really cannot see which damage the DVD manufacturarer could claim compensation for. It enough if they sue you for Unterlassung (you have to sign that you'll never do it again) - the costs for the lawyer that sued you will be significant. cu andreas cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#223961: libdvdread3: makes download of possibly illegal libdvdcss too easy
On Sun, Dec 14, 2003 at 11:16:11PM +0100, Andreas Metzler wrote: Adrian Bunk wrote: Package: libdvdread3 Version: 0.9.4-3 Severity: critical The debconf note says: -- snip -- Many DVDs use css. To play these, a special library is needed to read them, libdvdcss. Debian cannot distribute this library according to some laws, but it is available on other places on the internet for download. Run `/usr/share/doc/libdvdread3/examples/install-css.sh' to download and install it. -- snip -- These some laws not only prevent distribution of libdvdcss, they also disallow the use of libdvdcss in some countries (e.g. in Germany). [...] It is rather dubious and not proven in court that using libdvdcss for *playing* DVDs (not copying them) is indeed illegal in Germany. I suggest further discussion on -legal. It's at least a grey area, and most likely in more countries than just Germany. If you as a private person say I think it is legal to use libdvdcss for playing DVDs, it's your choice. But for a user, it should be very clear that there are legal risks when using libdvdcss. Besides this, is it 100% clear that the debconf note and install-css.sh couldn't fall under some forbidden promotion or distribution clause in Germany or other countries which would also bring legal risks for all mirrors and distributors of Debian [1]? Note that I'm not happy with the legal situation of libdvdcss, but even if it would succeed in the end, a lawsuit with it's costs against users, mirrors and/or distributors of Debian would cause serious harm for Debian. @Nathanael: The German copyright law was changed, and it does now prohit the circumvention of copyright protection. You might be sued by the copyright holder (with at least the costs of the lawsuit), and if you do it not only for your private use, the penalty is up to one year in prison. I'm referring to the German Gesetz ueber Urheberrecht und verwandte Schutzrechte, especially the paragraphs 95a, 97 and 108b. cu andreas cu Adrian [1] in Germany, it's not clear to me how much a judge _might_ interpret into paragraph 95a (3) of the German copyright law BTW: Please Cc me on replies, I'm not subscribed to debian-legal. -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#223961: libdvdread3: makes download of possibly illegal libdvdcss too easy
On Mon, Dec 15, 2003 at 11:37:38PM +, Brian M. Carlson wrote: On Mon, Dec 15, 2003 at 06:50:10PM +0100, Adrian Bunk wrote: On Sun, Dec 14, 2003 at 11:16:11PM +0100, Andreas Metzler wrote: Adrian Bunk wrote: Package: libdvdread3 Version: 0.9.4-3 Severity: critical This is not a critical bug. This is a serious bug. The definition of a critical bug is: critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. The definition of a serious bug is: serious is a severe violation of Debian policy (that is, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. I assume, therefore, that your objection is based on policy 2.3, which reads in part as follows: We reserve the right to restrict files from being included anywhere in our archives if * their use or distribution would break a law, * there is an ethical conflict in their distribution or use, * we would have to sign a license for them, or * their distribution would conflict with other project policies. because you did not include a Justification: header. Please state if this is not so. My objection is based on the first half of your Our Priorities are Our Users and Free Software If you want to nitpick, you could try to discuss whether it's critical or grave or serious, but it's definitely RC. The debconf note says: -- snip -- Many DVDs use css. To play these, a special library is needed to read them, libdvdcss. Debian cannot distribute this library according to some laws, but it is available on other places on the internet for download. Run `/usr/share/doc/libdvdread3/examples/install-css.sh' to download and install it. -- snip -- These some laws not only prevent distribution of libdvdcss, they also disallow the use of libdvdcss in some countries (e.g. in Germany). [...] It is rather dubious and not proven in court that using libdvdcss for *playing* DVDs (not copying them) is indeed illegal in Germany. I suggest further discussion on -legal. It's at least a grey area, and most likely in more countries than just Germany. If you as a private person say I think it is legal to use libdvdcss for playing DVDs, it's your choice. But for a user, it should be very clear that there are legal risks when using libdvdcss. Ignorance of the law is no excuse. If I choose to use an MP3 encoder in this country without paying Frauenhofer and Thomson exorbitant fees, I'm taking that risk. Any reasonable user should already know that libdvdcss is dangerous, and if one doesn't want one's door battered in by the I know _many_ Debian users that would after reading the libdvdread3 debconf note immediately install libdvdcss. Don't assume every user of Debian knows about the history and legal problems of libdvdcss. cops, one shouldn't use it. That said, it doesn't meet the standard set out above: the use of the install-css.sh file itself does not break a law, even though the use of the resulting download might. While this is If production, import and distribution of some software is illegal [1], the legal status of a script that downloads such software is at least questionable. nitpicking, this is the standard set out in policy, and is the criteria for serious bugs. ... Thankfully, I filed it as a critical bug. :-) cu Adrian [1] That's the case with software that circumvents copyright protection in Germany. -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#220464: gimp: LZW patent is still valid in Europe and Japan
On Wed, Nov 12, 2003 at 01:17:18PM -0800, Ben Gertzfield wrote: I am copying debian-legal on this mail. Please include me on any replies, as I am not subscribed to that list. I'm not subscribed to debian-legal, too. Please Cc me on replies. Below are my opinions on this issue. Adrian Bunk wrote: the LZW patent is still valid in Europe and Japan. Due to the possible legal risk for your users in Europe and Japan it's still required to keep LZW code out of main. I'm quite sure we have cryptographic software in main that is patent-encumbered and illegal for other reasons in many non-US countries worldwide. Isn't this exactly the same thing? It's been rehashed many times. Cryptographic software and non-US have nothing to do with patents or non-free software. It was and is always possible to use the software from non-US/main both inside and outside the USA (with at about half a dozen exceptions like Iraq and Afghanistan). Only exporting cryptographic software from the USA was an issue. If patented software was in non-US/main, it wouldn't e.g. be possible to mirror non-US in Germany. As far as I understand, at this point, the conclusion is that some patent-encumbered software is still allowed in main, as long as its distribution does not become problematic (Policy manual 2.2.3). How many countries need to have patents on a given piece of code before it becomes problematic? Section 2.2.3 of your policy says: Packages must be placed in _non-free_ or _non-US/non-free_ if they are not compliant with the DFSG or are encumbered by patents or other legal issues that make their distribution problematic. This section clearly states, that packages that are encumbered by patents must go to non-free. The their distribution problematic only refers to the other legal issues. Besides this, the distribution of patented software is IMHO problematic as soon as there's a patent without a patent licence that allows DFSG use of the patent: Otherwise the patent owner can at any time start lawsuits. I'm quite sure debian-legal will have more to say on this point. Ben cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: cupsys + libssl + libgnutls = confusion.
On Sun, 3 Nov 2002, Andrew Lau wrote: On Sat, Nov 02, 2002 at 09:22:45PM +0100, Adrian Bunk wrote: config-scripts/cups-openssl.m4 in the cupsys source package contains the autoconf macro cupsys uses for this purpose. Hey Adrian, Hi Andrew, I just looked at that cupsys-1.1.15/config-scripts/cups-openssl.m4 and I find no mention of GnuTLS in there at all. Then I took at look at debian/rules and noticed that cupsys isn't even built with SSL or TLS enabled. ... that's my fault: I should have said that you should look at the cupsys package in unstable. 2. Until #16748 - cupsys needs a Build-Conflicts: libssl-dev is resolved, any cupsys-pt client will have no encrypted CUPS server in Debian to talk to. #167489 will soon be fixed (Jeff's preferred solution is to change the GNUTLS tests in cups-openssl.m4; the discussion is in the BTS). But... ... From my understanding of the above two clauses, cupsys can be built with OpenSSL support enabled. So why is it explicitly disabled at the moment? Why do you call for GnuTLS support for cupsys in #167489? What is the official debian-legal position on this because I'm really, really confused now... AFAIK the problem isn't cupsys itself. The problem is that if cupsys is linked with OpenSSL then libcupsys2 is linked with it and therefore all programs using libcupsys2... Yours sincerely, Andrew Netsnipe Lau cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: Is this patch OK for main?
On Tue, 10 Apr 2001, J.H.M. Dassen (Ray) wrote: [I'm probably repeating myself, but this is for the benefit of debian-legal readers and may help to shorten discussion] On Tue, Apr 10, 2001 at 16:10:39 +0200, Adrian Bunk wrote: could someone please tell me if this patch: - contains any code with legal problems (e.g. patents)? Not that I'm aware of. - forces the package to go to non-US? It doesn't. It essentially has two parts ... Thanks for the explanations, I'll include the patch in the near future in util-linux. will be incompatible with the current one as reported in e.g. #36939), and there's the issue that if there were a problem, there'd be a problem with having the diff posted to a mailing list hosted in the US and archived on webservers hosted in the US. Ups, sorry! I'll think of this in the future before sending such a mail. Ray cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Is this patch OK for main?
Hi,
could someone please tell me if this patch:
- contains any code with legal problems (e.g. patents)?
- forces the package to go to non-US?
If none of the above is true I'll apply this patch to the Debian
util-linux package.
Thanks in advance for your answers
Adrian
PS: Please Cc me because I'm not on this list.
--
Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.
diff -urN util-linux-2.11b/MCONFIG util-linux-2.11b.int/MCONFIG
--- util-linux-2.11b/MCONFIGThu Mar 8 20:43:53 2001
+++ util-linux-2.11b.int/MCONFIGMon Apr 2 19:39:50 2001
@@ -16,7 +16,7 @@
# If HAVE_PAM is set to yes, then login, chfn, chsh, and newgrp
# will use PAM for authentication. Additionally, passwd will not be
# installed as it is not PAM aware.
-HAVE_PAM=no
+HAVE_PAM=yes
# If HAVE_SHADOW is set to yes, then login, chfn, chsh, newgrp, passwd,
# and vipw will not be built or installed from the login-utils
diff -urN util-linux-2.11b/mount/Makefile util-linux-2.11b.int/mount/Makefile
--- util-linux-2.11b/mount/Makefile Mon Mar 5 01:38:53 2001
+++ util-linux-2.11b.int/mount/Makefile Mon Apr 2 19:39:50 2001
@@ -24,7 +24,7 @@
MAYBE = pivot_root swapoff
-LO_OBJS = lomount.o $(LIB)/xstrncpy.o
+LO_OBJS = lomount.o $(LIB)/xstrncpy.o rmd160.o
NFS_OBJS = nfsmount.o nfsmount_xdr.o nfsmount_clnt.o
GEN_FILES = nfsmount.h nfsmount_xdr.c nfsmount_clnt.c
@@ -57,7 +57,7 @@
main_losetup.o: lomount.c
$(COMPILE) -DMAIN lomount.c -o $@
-losetup: main_losetup.o $(LIB)/xstrncpy.o
+losetup: main_losetup.o $(LIB)/xstrncpy.o rmd160.o
$(LINK) $^ -o $@
mount.o umount.o nfsmount.o losetup.o fstab.o realpath.o sundries.o: sundries.h
diff -urN util-linux-2.11b/mount/lomount.c util-linux-2.11b.int/mount/lomount.c
--- util-linux-2.11b/mount/lomount.cThu Mar 15 11:09:58 2001
+++ util-linux-2.11b.int/mount/lomount.cMon Apr 2 19:39:51 2001
@@ -6,6 +6,11 @@
* - added Native Language Support
* Sun Mar 21 1999 - Arnaldo Carvalho de Melo [EMAIL PROTECTED]
* - fixed strerr(errno) in gettext calls
+ * 2000-09-24 Marc Mutz [EMAIL PROTECTED]
+ * - added long option names and the --pass-fd option to pass
+ * passphrases via fd's to losetup/mount. Used for encryption in
+ * non-interactive environments. The idea behind xgetpass() is stolen
+ * from GnuPG, v.1.0.3 (http://www.gnupg.org/).
*/
#define PROC_DEVICES /proc/devices
@@ -21,54 +26,107 @@
#include errno.h
#include stdlib.h
#include unistd.h
+#include limits.h
#include sys/ioctl.h
#include sys/stat.h
#include sys/mman.h
#include loop.h
#include lomount.h
+#include rmd160.h
#include xstrncpy.h
#include nls.h
+#ifndef LO_CRYPT_CRYPTOAPI
+#define LO_CRYPT_CRYPTOAPI 18
+#endif
+#ifndef LO_CRYPT_NONE
+#define LO_CRYPT_NONE 0
+#endif
+#ifndef LO_CRYPT_XOR
+#define LO_CRYPT_XOR 1
+#endif
+#ifndef LO_CRYPT_DES
+#define LO_CRYPT_DES 2
+#endif
+#ifndef LO_CRYPT_FISH2
+#define LO_CRYPT_FISH2 3
+#endif
+#ifndef LO_CRYPT_BLOW
+#define LO_CRYPT_BLOW 4
+#endif
+#ifndef LO_CRYPT_CAST128
+#define LO_CRYPT_CAST128 5
+#endif
+#ifndef LO_CRYPT_IDEA
+#define LO_CRYPT_IDEA 6
+#endif
+#ifndef LO_CRYPT_SERPENT
+#define LO_CRYPT_SERPENT 7
+#endif
+#ifndef LO_CRYPT_MARS
+#define LO_CRYPT_MARS 8
+#endif
+#ifndef LO_CRYPT_RC6
+#define LO_CRYPT_RC6 11
+#endif
+#ifndef LO_CRYPT_3DES
+#define LO_CRYPT_3DES 12
+#endif
+#ifndef LO_CRYPT_DFC
+#define LO_CRYPT_DFC 15
+#endif
+#ifndef LO_CRYPT_RIJNDAEL
+#define LO_CRYPT_RIJNDAEL 16
+#endif
+
+
extern int verbose;
extern char *xstrdup (const char *s); /* not: #include sundries.h */
extern void error (const char *fmt, ...); /* idem */
+
+struct cipher_info
+{
+ const char *name;
+ int blocksize;
+ int keysize_mask;
+ int ivsize;
+ int key_schedule_size;
+};
+
+static int set_loop_passwd(struct loop_info *_loopinfo, int pfd, int keysz,
+ const char *encryption, int fd, int ffd);
+static int get_cipher_info(const char *name, struct cipher_info *res);
+static int name_to_id(const char *name);
+#ifdef MAIN
+static char *id_to_name(int id);
+#endif
+
+
#ifdef LOOP_SET_FD
struct crypt_type_struct {
int id;
char *name;
+ int keylength;
} crypt_type_tbl[] = {
- { LO_CRYPT_NONE, no },
- { LO_CRYPT_NONE, none },
- { LO_CRYPT_XOR, xor },
- { LO_CRYPT_DES, DES },
- { -1, NULL }
+{ LO_CRYPT_NONE, none, 0 },
+{ LO_CRYPT_XOR, xor, 0 },
+{ LO_CRYPT_DES, des, 8 },
+{ LO_CRYPT_FISH2, twofish, 20 },
+{ LO_CRYPT_BLOW, blowfish, 20 },
+{ LO_CRYPT_CAST128, cast, 16 },
+{ LO_CRYPT_SERPENT, serpent, 16 },
+{ LO_CRYPT_MARS, mars, 16 },
+{ LO_CRYPT_RC6, rc6, 16 },
+{ LO_CRYPT_3DES, des-ede3, 24 },
+{ LO_CRYPT_DFC, dfc, 16 },
+{ LO_CRYPT_IDEA, idea, 16 },
+{ LO_CRYPT_RIJNDAEL, rijndael, 16 },
+ { -1, NULL,0 }
};
-static int
Re: whether there is a patent on MP3 decoding [was Re: Bug#65794: freeamp must go to non-free]
On Sat, 17 Jun 2000, Josip Rodin wrote: severity 65794 normal severity 65796 normal severity 65797 normal thanks On Sat, Jun 17, 2000 at 02:27:23PM +0200, Adrian Bunk wrote: freeamp is a MP3 decoder. Decoding of MP3s is patented. http://www.mp3licensing.com/royalty/swdec.html says about license fees for MP3 decoders: mp3 Software Decoders/Players distributed free-of-charge via the Internet for personal use of end-users No license fee is expected for desktop software mp3 decoders/players that are distributed free-of-charge via the Internet for personal use of end-users. [you have to pay license fees in all other cases] This seems to conflict with the DFSG. freeamp must go to non-free Actually, patent issues don't concern DFSG, the copyright/licensing issues The first point of the DFSG is: Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. If you read the text above: distributed free-of-charge via the Internet doesn't cover the distribution on a CD. do. But yes, the packages would move to non-free... I am not completely convinced that this is a real threat. There was no threat for a lawsuit ever by the Fraunhofer or Thomson people against a free MP3 decoder that we shipped (although yes, this can be a problem for those CD vendors that make 1 copies). The mp3licensing.com or Until now there was no threat for a lawsuit, but if they want they can try it with EVERYONE who sells a CD - and if they want they can pick a very small one (I think of that there is currently someone in Germany who has a trademark on webspace and his lawyer sends letters that you must say you don't use that word again - and that you have to pay at about 1000,- Dollar for the lawyer who sent this letter. They always pick people / small companies that don't have the money for a long lawsuit.). thomson-multimedia.com sites have no clear reference or text of a patent that covers decoding. Rumour has it that decoding of MP3s is a simple Fourier transform, and there's a prior art for that process which dates back to the start of the century, so the patent wouldn't be valid, if it existed. Until further investigation (i.e. until someone quotes a patent that our free software packages infringe), let's downgrade the severity of these bug reports below release-critical. ... I think these bugs are RC: Do you really want the risk of a lawsuit for everyone who sells a CD with main of Debian? cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: Bug#64129: plugger: cannot build from source
On Thu, 18 May 2000, Adam Heath wrote: ... plugger is in contrib for a reason. ns-plugin-sdk can't be distributed. I have a local deb of it, but I can't send it anywhere, as it has no copyright at all, and netscape has been deaf to my inquiries. ... plugger is under the GPL but linked with a nonfree library? Isn't this a incompatibility similar to GPL linked with QT? cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: mixmaster license
On Tue, 9 May 2000, Peter Palfrader wrote: ... One part that I don't like about the new license[1] is the following paragraph (1.b.iii): [you may modify and distribute the source only iff you] provide Anonymizer Inc. with a copy of the Source Code of such modifications or work by electronic mail, and grant Anonymizer Inc. a perpetual, royalty-free license to use and distribute the modifications or work in its products. Am I correct to assume that this would make the package go into non-free? I think this is DFSG-free and can go to main. TIA yours, peter cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: mixmaster license
On Tue, 9 May 2000, Branden Robinson wrote: I think this is DFSG-free and can go to main. I don't. WHat if Anonymizer Inc. goes out of business? All of a sudden everyone loses the right to modify and distribute the source code. That's right. The oother question is: Is it DFSG-free if this part of the license would be changed to something like send us the modifications by email; if our company is without reach you are allowed to do without this (the wording needs to be improved)? Especially: Is the ... and grant Anonymizer Inc. a perpetual, royalty-free license to use and distribute the modifications or work in its products. DFSG-free? Perhaps we need to add some notes to the DFSG explaining why clauses like the above are unacceptable. I agree. cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: mixmaster license
On Tue, 9 May 2000, Joey Hess wrote: Adrian Bunk wrote: I think this is DFSG-free and can go to main. Would you care to justify that remark? You could start by telling us how it doesn't conflict with sections 1, 3, 5, and 7 of the DFSG. (Have you _read_ the DFSG?) Yes, I did read the DFSG and the complete mixmaster license before writing this. I didn't think of the special case the company is not reachable. That's why it violates #3 (Derived Works). Please explain to me in how far it violates #1 (Free Redistribution), #5 (No Discrimination Against Persons or Groups) and #7 (Distribution of License). see shy jo cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: Is the old BSD licence DFSG compliant?
On 10 Apr 2000, Thomas Bushnell, BSG wrote: sorry if it's a FAQ, but I didn't find a place where it stands explicitely: Is the old BSD licence (with the advertising clause) DFSG compliant? I did read the Debian Social Contract and the DFSG and I didn't find any reason why it shouldn't, or did I miss something? If it's actually copyright UCB, then the advertising clause has been revoked by Berkeley, and you can delete the paragraph and move on. (This applies ONLY if the copyright holder is UC Berkeley, not anyone else.) I don't think so, the copyright is as follows. And then there's still the general question if a copyright with an advertising clause can be DFSG compliant. * Copyright (c) 1985, 1986 The Regents of the University of California. * All rights reserved. * * This code is derived from software contributed to Berkeley by * James A. Woods, derived from original work by Spencer Thomas * and Joseph Orost. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors *may be used to endorse or promote products derived from this software *without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. Thomas cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Is the old BSD licence DFSG compliant?
Hi, sorry if it's a FAQ, but I didn't find a place where it stands explicitely: Is the old BSD licence (with the advertising clause) DFSG compliant? I did read the Debian Social Contract and the DFSG and I didn't find any reason why it shouldn't, or did I miss something? Thanks, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
