Re: Bug#523093: undetermined copyright/license violation
On Wed, Apr 15, 2009 at 08:41:08AM +0200, Giacomo Catenazzi wrote: Maybe taking derived code (e.g. including new code), one could write only the license of aggregate work (thus one later license), I think so. I agree it could be better to list them explicitly, but upstream doesn't want that. Then again, see what I said in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523093#38 but I think: 1- the old code is still 2 or later It is. Though, it is impractical to split it off the file that contains mixed licenses. But there's no need to either, people wanting the old code can take it from Tomboy (assuming patent liability is not a problem for them). 2- it is better not to mix licenses in one file, so it is better to add new code or with the same license or in an extra file (no problem removing part of old file) 3- Debian should allow the more liberal license as possible, thus maintaining the option to use the old license terms. We already discussed about whether it's good or not to upgrade licenses or to mix different GPL versions in the same file, in a separate thread in -legal. I gave my personal opinion there. Btw the license change comes from upstream, not Debian. It's obvious Hubert has his own reasons for doing it, but whichever they are they're off-topic here. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
Hi Anthony, On Wed, Apr 08, 2009 at 11:42:33PM +0100, Anthony W. Youngman wrote: Each author *should*, as a matter of *courtesy*, explicitly mention the licence in all of their files, Yes, I agree, in general, but it's still not clear to me that section 12 of LGPL can't be interpreted as you can put a single GPL header just like 2 or later in a GPLv2+ header can be interpreted as you can update the version number and use a single header. What would be the difference? and *should* *not* use a different licence when modifying a different author's original files. That depends on whether the original author chose license terms that would allow this. In this case they did. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
On Thu, Apr 09, 2009 at 10:27:19PM -0500, Adam Majer wrote: License and copyright are one and the same. GPL license relies on copyright law, just like almost any other open source license there is, be it BSD, Artistic or LGPL. Without copyright, the license is meaningless. Without license, you have no right to the source code. Thanks for the explanation; but I think what you mean is they're dependant on each other. This doesn't imply they're the same thing though. I think we all agree the Copyright lines, whenever they were present, need to be preserved. The license bits in general too, but what happens when the license terms explicitly give you permission to relicense? I gave this example in another mail (sorry if I sound redundant); my understanding is that in 2 or later terms in a GPLv2+ header the license version can be updated by recipients of the code, and that keeping the old license blob around is not a must; is this correct? Does section 12 of LGPL 2.1 work the same way? If not, where's the difference? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
On Fri, Apr 10, 2009 at 09:37:22AM +0100, Anthony W. Youngman wrote: I think you're wrong here! The GPL does NOT give you the right to change the terms on which the original author granted use of the code! What it does give you (if the author uses the or later wording) is the right to use a later licence to cover what YOU do. Let us say that I licence something under Version 2 or later. I have NOT given you the right to relicence my code! What you *can* do is say I prefer the terms of version 3, the licence grant gives me the right to claim version 3 as my permission to use this code, therefore I will modify/distribute/etc under version 3. It DOES NOT allow you to take away my grant of version 2. If you then distribute modified code and say modifications are v3 only the resulting file becomes distributable under v3 only. It still hasn't taken away my grant of version 2 to my code. Alright then. Thanks for the correction. So what we need it to keep the old license header around, whenever there was one. I'll make sure this applies before the package is uploaded. Thanks -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
I reply to this separately, because it's quite off-topic and unrelated to the problem at hand. I don't want to add noise to the wnpp log. On Fri, Apr 10, 2009 at 09:37:22AM +0100, Anthony W. Youngman wrote: THAT is why it is downright offensive to change the licence on minor modifications to someone else's file. It is not. The author chose a license that explicitly allows this, in section 12, because they didn't want to prevent the license from being upgraded by third parties. This is precisely what is happening. The legal result may not matter when mixing licences. But the Free Software world places the SPIRIT of the grant much higher than the letter The spirit of LGPL (or GPL for that matter) never intended to allow use of patents as a means to impose a tax on software covered by the license, and Novell is doing exactly that. Looks like fair play to me. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
On Fri, Apr 10, 2009 at 03:51:23PM +0100, Anthony W. Youngman wrote: It is not. The author chose a license that explicitly allows this, in section 12, because they didn't want to prevent the license from being upgraded by third parties. This is precisely what is happening. Just because the author allows it, doesn't mean it isn't offensive. Your small change is taking a lot of rights away from other people. It may be legal and permitted, but isn't it one of the principles of Free Software that downstream can't take away rights granted by upstream? Yet that's exactly what this does! You're confusing rights with leverage. The right to force people into paying you for a service you didn't provide, the right to prevent people from running modified versions of a program, etc. If you do a major rewrite and just re-use part of the old code, then fair enough. But if your changes are minimal then you are preventing your recipients from exercising their rights wrt the *majority* of the code (at least, not without considerable wasted effort stripping out your changes). That's not on. They can still use the original code if they want to. Although if they're US-based corporate users, maybe they'll have to pay Novell for a Peace of Mind pack (aka SLED). That's what I meant about breaking the Spirit makes enemies! Novell are seen as not playing fair, Patent extortion is unethical, in and on itself. They do it by violating the spirit of the GPL, and you perceive this as unfair, but it's not the reason that makes it unethical. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
On Fri, Apr 10, 2009 at 09:15:39PM +0200, Francesco Poli wrote: On Thu, 09 Apr 2009 20:38:33 -0400 Hubert Figuiere wrote: [...] Except that the original files don't have any notice. For those that did, the notice has been kept. In that case, I personally think the safest strategy is including such notice, even though it was not present in the first place. This is getting extreme. If the original author didn't bother asserting their copyright, why would one have to do it in the modified version? Consider the situation in which you send a patch for some program, but don't add your name in the copyright header. Does this mean every redistributor of the program will have to track you down and add the missing lines? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
On Thu, Apr 09, 2009 at 11:47:14AM +0200, Giacomo A. Catenazzi wrote: Robert Millan wrote: For an example, if a program has three authors, one of whom uses BSD, the second uses LGPL 2.1 or later and the third uses GPL 3 then the Venn Intersect is GPL 3, which is the licence that applies to the work as a whole. However, any recipient is at full liberty to strip out parts of the work, and use whatever licence the author granted. Yeah, I understand the combined result is GPLv3; the only doubt I have is whether it's necessary to explicitly mention each license. The combined result is different/new work (with a own license), but derived from other works. Don't confuse single file with combined results. But every file has author(s) and license(s), which are replaceable only by authors. LGPL allow you to use LGPL as a GPL license, but not to change it. Alright. If you add new function to a LGPL file, and your changes are GPL only, *practically* the file is only GPL, but the original code is still LGPL, so better to explicit write also the LGPL. Sounds reasonable. Hubert, can we do that? Let me know if I can help. (or better: use an other file for your changes: one license per file) I think splitting the files can be cumbersome. I wouldn't do it unless strictly necessary. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
Hi Jo, Nice to see your newly found interest in C++ packages (though, not completely unexpected) :-) On Wed, Apr 08, 2009 at 06:26:18PM +0100, Jo Shields wrote: Please note that this project in its current form contains swathes of major copyright violations and cannot be uploaded to Debian - almost all source files contain Tomboy source, with Copyright unilaterally changed. Compare, for an example, http://gitorious.org/projects/gnote/repos/mainline/blobs/master/src/preferencesdialog.cpp to http://svn.gnome.org/viewvc/tomboy/trunk/Tomboy/PreferencesDialog.cs?revision=2349view=markup This kind of rewrite is completely permitted under Tomboy's license - changing the copyright without the author's permission is not. If there's a problem, we'll get it sorted out, but I need more specific info on your findings; the example you pasted shows a file with nor copyright statement neither license information (from tomboy) and one with both of them (in gnote). Please tell me which of these (in your judgement) apply: - The new file seems to be asserting copyright for the code as a whole, and it's not implicitly understood that it only applies to the originality added to it by rewriting in C++. (this is somewhat contentious, since there are examples of other programs doing the same, but it can be fixed by adding a clarification to each file) - The new license (GPL v3) is incompatible with LGPL v2.1 (it's not; see section 13 of the LGPL v2.1) - There are copyright/license statements being replaced, elsewhere in the code. (if this is so, please give some example) - Something else. (be my guest) Tomboy's upstream have been alerted, and are trying to contact the GNote author to resolve the issue Good to know. I'll speak with the gnote author too, but first you'll have to give some more information, or at least point me to it :-) Is there some description/summary of the problem elsewhere I can check? - until then, GNote cannot be considered suitable for Debian. Sure. Btw, I'm adding debian-legal to CC, perhaps they can provide some insight (as you know, when there are doubts about legal stuff it is considered good practice to discuss things in that list). Cheers -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
On Wed, Apr 08, 2009 at 08:30:30PM +0100, Jo Shields wrote: If there's a problem, we'll get it sorted out, but I need more specific info on your findings; the example you pasted shows a file with nor copyright statement neither license information (from tomboy) and one with both of them (in gnote). Please tell me which of these (in your judgement) apply: - The new file seems to be asserting copyright for the code as a whole, and it's not implicitly understood that it only applies to the originality added to it by rewriting in C++. (this is somewhat contentious, since there are examples of other programs doing the same, but it can be fixed by adding a clarification to each file) - The new license (GPL v3) is incompatible with LGPL v2.1 (it's not; see section 13 of the LGPL v2.1) - There are copyright/license statements being replaced, elsewhere in the code. (if this is so, please give some example) - Something else. (be my guest) [...] the copyright header in the file is clearly asserting that the file is 100% copyrighted by Hubert Figuiere when it's not. [...] And so on. * Copyright (C) 2009 Hubert Figuiere is simply false, Alright. So, I understand you mean option 1 (see my paragraph starting with The new file seems to be asserting... above). Unless there's a clear consensus in -legal that this is not a problem, I will assume it is. I'm fine with extra clarification, for the sake of correctness, it just means a bit more work. I'll speak with the gnote author about it. and a clear violation of Tomboy's license. Notice license and copyright statements are two separate issues. AFAIK LGPL doesn't explicitly require that a license notice is preserved mixing code with other licenses like the BSD license does, but I could be mistaken. Any advice on this from -legal? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
[ Adding Hubert Figuiere (gnote upstream) to CC, note that he's probably not subscribed ] Hi Anthony, On Wed, Apr 08, 2009 at 09:20:44PM +0100, Anthony W. Youngman wrote: In message 20090408194833.ga5...@thorin, Robert Millan r...@aybabtu.com writes and a clear violation of Tomboy's license. Notice license and copyright statements are two separate issues. AFAIK LGPL doesn't explicitly require that a license notice is preserved mixing code with other licenses like the BSD license does, but I could be mistaken. Any advice on this from -legal? If it's not your code, and the licence does not give you explicit permission, then you can't change the licence and shouldn't remove the licence note. Note that the GPLs fall in this category! The way you change the licence with this sort of code is by licencing your code with a compatible licence. The licence for the resulting combined work is the Venn Intersect of the two licences. If there's no intersect, then you can't distribute. Does this apply on a per-file basis? It seems we have three different situations: a- old file has no copyright/license statement, and a new copyright/license statement (for Hubert / GPLv3+) was added. b- old file has a copyright/license statement, which is left verbatim since the file wasn't modified (or only minimally). c- old file has a copyright/license statement, the new file adds its own GPLv3+ header and BOTH copyright lines (but not the LGPLv2.1 header). Is any of these at fault? You're saying that C is incorrect because it should include both license headers (and not just both copyright lines)? Is A also at fault because it should say explicitly that the copyright only covers Hubert's changes (even if noone else bothered to assert their copyrights)? For an example, if a program has three authors, one of whom uses BSD, the second uses LGPL 2.1 or later and the third uses GPL 3 then the Venn Intersect is GPL 3, which is the licence that applies to the work as a whole. However, any recipient is at full liberty to strip out parts of the work, and use whatever licence the author granted. Yeah, I understand the combined result is GPLv3; the only doubt I have is whether it's necessary to explicitly mention each license. If it's not, is there anything else we should take care of? Thanks -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
GPL code concatenation
Hi, Suppose you have a chunk of code that implements initialisation of an MSDOS executable. If you concatenate a payload (raw code) after it, you obtain a .exe that runs your code (at a specific, agreed upon, address I think). My question is, would such combination qualify as a derivative program as per GPL requirements? Thanks -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#431109: [PROPOSAL] Disambiguate of Section 12.5
On Sun, Dec 30, 2007 at 09:06:42PM -0800, Russ Allbery wrote: Robert Millan [EMAIL PROTECTED] writes: On Sat, Jun 30, 2007 at 12:17:00AM +0200, Santiago Vila wrote: Instead, I think we should amend policy in this way: Packages under a fixed, definite version of the GPL should refer to the versioned GPL file in /usr/share/common-licenses. On Sat, Jun 30, 2007 at 10:21:25AM +0200, Santiago Vila wrote: In other words, I think it would be ok if our copyright files were worded like this: This program is free software. It is under GPL version 2 or later. On Debian systems, the latest GPL version is in /usr/share/common-licenses/GPL. Ok, new proposed patch, incorporating these fixes. I think that this Policy bug has been addressed by the current version of Policy, which no longer mentions the unversioned files at all. Please let me know if you disagree; otherwise, I'll close this bug. I don't like it. Current text seems to forbid referring to `/usr/share/common-licenses/GPL' for a package that is licensed under GPL version N or later. At the very least, it should allow this. And preferably, mention this possibility so that it can be taken in consideration. This is in fact a convenient practice, because it spares you the job of updating debian/copyright every time upstream updates to a newer version of the GPL. And everything seems to indicate future updates of the GPL will be much more frequent than the v3 one. At least that's what the FSF states. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
moonlight
Any comments on this one? I think we're safe shipping it as long as patent coverage isn't inherently necessary to implement the spec. Then if patent threats appear, the code can be fixed to circumvent them. But then again, it sounds really scary (specially considering once the web has stablished as its new standard, there's no way back). I would recommend not to include it unless there's an active group of upstream developers supporting it the non-patent-covered way. use a distro that is not mainstream or just doesn't have a deal with the daemon.. err Microsoft.. like Novell has.. Will I have to suffer the shadow of Microsoft patents over Silverlight when using or developing Moonlight? Not as long as you get/download Moonlight from Novell which will include patent coverage. See: http://linux.slashdot.org/article.pl?sid=07/09/10/2343256 -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks
On Sun, Jul 01, 2007 at 12:49:58PM +0200, Andreas Barth wrote: * Florian Weimer ([EMAIL PROTECTED]) [070630 10:16]: * Santiago Vila: + file. Packages should not refer to GPL and LGPL symlinks in + that directory since different, incompatible versions of these + licenses have been published by the Free Software Foundation, + hence using the symlinks could lead to ambiguity. I disagree with this. It should be ok to point to the latest version of the GPL if the program says Version X or later. Many programs do that, and we should not need to change them. But do we really want to license everything which is GPL version 2 or later under the GPL version 3? And how do we discriminate between GPL version 2 or later and GPL version 3 or later? If it says version N or later, we should of course point to the *earliest* version to give users the choice which version they want. There's nothing about the earliest giving user more choice than the latest. If instead of GPL 2 and GPL 3, we call them GPL Foo and GPL Bar, we get: - Program is licensed under either GPL Foo, GPL Bar, or future versions that don't exist yet. - Since both Foo and Bar are DFSG-free [1], we are allowed to distribute it under the terms of either. This doesn't take away freedom from our users, who are still able to use it as per the terms of Foo or Bar. AISI, the reason for using the unversioned link is that it means less work for maintainers (and the work *is* significant when it comes to lots of packages) who have to update the copyright file every time license changes. Most GPL programs out there are 2-or-later, so we are always allowed to distributed as per the latest GPL. The opposite does not apply. [1] Even if DFSG-freeness of GPL 3 were to be disputed, this proposal is completely agnostic about that. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] Disambiguate of Section 12.5
On Sat, Jun 30, 2007 at 12:17:00AM +0200, Santiago Vila wrote: Instead, I think we should amend policy in this way: Packages under a fixed, definite version of the GPL should refer to the versioned GPL file in /usr/share/common-licenses. On Sat, Jun 30, 2007 at 10:21:25AM +0200, Santiago Vila wrote: In other words, I think it would be ok if our copyright files were worded like this: This program is free software. It is under GPL version 2 or later. On Debian systems, the latest GPL version is in /usr/share/common-licenses/GPL. Ok, new proposed patch, incorporating these fixes. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. diff -ur debian-policy-3.7.2.2.old/policy.sgml debian-policy-3.7.2.2/policy.sgml --- debian-policy-3.7.2.2.old/policy.sgml 2006-10-03 00:36:50.0 +0200 +++ debian-policy-3.7.2.2/policy.sgml 2007-06-30 10:55:06.0 +0200 @@ -8625,15 +8625,14 @@ p Packages distributed under the UCB BSD license, the Artistic - license, the GNU GPL, and the GNU LGPL, should refer to the - corresponding files under + license, the GNU GPL or LGPL (any version as published by the Free + Software Foundation that Debian considers free), should refer to + the corresponding files under file/usr/share/common-licenses/file,footnote p For example, file/usr/share/common-licenses/Artistic/file, file/usr/share/common-licenses/BSD/file, - file/usr/share/common-licenses/GPL/file, - file/usr/share/common-licenses/LGPL/file, file/usr/share/common-licenses/GFDL/file, file/usr/share/common-licenses/GPL-2/file, and file/usr/share/common-licenses/LGPL-2.1/file, and so @@ -8642,7 +8641,20 @@ file/usr/share/common-licenses/GFDL/file. /p /footnote rather than quoting them in the copyright - file. + file. Packages under a fixed, definite version of the GPL or LGPL + should refer to the versioned GPL or LGPL file in + file/usr/share/common-licenses/file. Packages that are licensed under a fixed + version of the GPL or LGPL, but giving the licensee the option to + adhere to terms of any later version of the license, should refer to + the unversioned GPL or LGPL file in file/usr/share/common-licenses/file, making + it clear which versions may be used.footnote + p + For example, the copyright file might read: + example + This program is free software. It is under GPL version 2 or later. On Debian + systems, the latest version of the GPL is in /usr/share/common-licenses/GPL. + /example + /p/footnote /p p signature.asc Description: Digital signature
Re: Bug#431109: [PROPOSAL] Disambiguate of Section 12.5
But, AFAIUI, the purpose of this informational sentence is to comply with the GNU GPL v2, which states, in Section 1: | give any other recipients of the Program a copy of this License | along with the Program. and then includes (by reference to Section 1) this same restriction in the successive Sections. As a consequence, for a work licensed under the terms of the GNU GPL v2 or later, Debian should give a copy of the GNU GPL *v2*, which it does in /usr/share/common-licenses/GPL-2. Both ways of doing it are in compliance. When a program is dual-licensed under GPL-2 or any later version, you can adhere to GPL-3 for the purpose of compliing with Section 1 (or whatever section it is in GPL-3), without this preventing our users from adhering to GPL-2 if they wish. (IANAL, etc) -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks
retitle 431109 [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks thanks On Fri, Jun 29, 2007 at 10:04:02PM +0200, Santiago Vila wrote: Following /usr/share/doc/base-files/FAQ, I'm reassigning this to debian-policy. Please read my email to debian-legal ad debian-policy from two days ago. In my interpretation, Policy doesn't exclude any version of the GPL from this requirement, but I admit that it is ambigous, specially considering the examples. This proposal does essentialy two things: - Disambiguate GPL/LGPL versioning requirement by extending it to any DFSG compatible version the FSF may publish. - Deprecate use of symlinks, since they're a source of problems (as exposed by GPLv3, see http://lists.debian.org/debian-legal/2007/06/msg00234.html) -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. diff -ur debian-policy-3.7.2.2.old/policy.sgml debian-policy-3.7.2.2/policy.sgml --- debian-policy-3.7.2.2.old/policy.sgml 2006-10-03 00:36:50.0 +0200 +++ debian-policy-3.7.2.2/policy.sgml 2007-06-29 23:58:41.0 +0200 @@ -41,7 +41,7 @@ p A copy of the GNU General Public License is available as - file/usr/share/common-licenses/GPL/file in the Debian GNU/Linux + file/usr/share/common-licenses/GPL-2/file in the Debian GNU/Linux distribution or on the World Wide Web at url id=http://www.gnu.org/copyleft/gpl.html; name=the GNU General Public Licence. You can also @@ -8625,24 +8625,26 @@ p Packages distributed under the UCB BSD license, the Artistic - license, the GNU GPL, and the GNU LGPL, should refer to the - corresponding files under + license, the GNU GPL or LGPL (any version as published by the Free + Software Foundation that Debian considers free as per DFSG), should + refer to the corresponding files under file/usr/share/common-licenses/file,footnote p For example, file/usr/share/common-licenses/Artistic/file, file/usr/share/common-licenses/BSD/file, - file/usr/share/common-licenses/GPL/file, - file/usr/share/common-licenses/LGPL/file, file/usr/share/common-licenses/GFDL/file, - file/usr/share/common-licenses/GPL-2/file, and - file/usr/share/common-licenses/LGPL-2.1/file, and so + file/usr/share/common-licenses/GPL-3/file, and + file/usr/share/common-licenses/LGPL-3/file, and so on. Note that the GFDL is new here, and the license file may not yet be in place in file/usr/share/common-licenses/GFDL/file. /p /footnote rather than quoting them in the copyright - file. + file. Packages should not refer to GPL and LGPL symlinks in + that directory since different, incompatible versions of these + licenses have been published by the Free Software Foundation, + hence using the symlinks could lead to ambiguity. /p p signature.asc Description: Digital signature
Re: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks
On Sat, Jun 30, 2007 at 12:17:00AM +0200, Santiago Vila wrote: + file. Packages should not refer to GPL and LGPL symlinks in + that directory since different, incompatible versions of these + licenses have been published by the Free Software Foundation, + hence using the symlinks could lead to ambiguity. I disagree with this. It should be ok to point to the latest version of the GPL if the program says Version X or later. Many programs do that, and we should not need to change them. Instead, I think we should amend policy in this way: Packages under a fixed, definite version of the GPL should refer to the versioned GPL file in /usr/share/common-licenses. Good idea. Should we also specify that referring to the unversioned GPL is for programs that say Version X or later ? I think this is not obvious. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419597: please remove twolame (patent infringement)
Package: ftp.debian.org Severity: serious twolame contains code (MP3 encoding algorithm) which infringes patents of the Fraunhofer Institute. This falls in the Software that can't be packaged cathegory in WNPP: http://www.debian.org/devel/wnpp/unable-to-package and I don't see any discussion in debian-legal contradicting it. Would you please remove it from stable, testing and unstable ? (Yes, this breaks vlc and darkice, but that can be fixed later. Even for stable, the can't install severity justifies a new upload.) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#203211: Software patents and Debian
On Wed, Aug 16, 2006 at 11:04:44AM +0200, Bas Wijnen wrote: Hello, When looking for some video-editing software, I found avidemux. According to the wnpp bug, there is a problem with license issues regarding the MPEG2/MPEG4 codec. There is a software patent on this codec, and a paid license is needed in order to use it, appearantly. My question is how Debian handles software patents. I thought we didn't care about them except if they were actively enforced, because it's completely impossible to avoid all patented software, considering the junk that gets patented. If that is the case, would any of you know if the MPEG[24] codec patents are actively enforced? In other words, can this be in Debian? Thanks, Bas Wijnen Ps: Please keep me CCd, I'm not on the list. Why not just removing the offending code and leaving avidemux only with support for patent-free codecs like theora? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: possible license violation (was: libssl and zlib1g)
Actualy, I'm not sure if indirect linking of GPL with original BSD license is a violation as well. Summary for debian-legal: - zabbix (GPL) links with libsnmp (revised BSD) - libsnmp links with libssl (original BSD) On Thu, Jul 27, 2006 at 11:32:04AM +0200, Robert Millan [ackstorm] wrote: On Thu, Jul 27, 2006 at 10:50:05AM +0200, Michael Ablassmeier wrote: hi robert, On Thu, Jul 27, 2006 at 10:07:38AM +0200, Robert Millan [ackstorm] wrote: It seems that zabbix is explicitly checking for and linking with libz and libcrypto. Look at the logs: checking for compress in -lz... yes [...] checking for main in -lcrypto... yes [...] gcc -Wall -g -O2 -o zabbix_server [...] -lz [...] -lcrypto well, i have just had a look at other packages build-depending on libsnmp-dev, and all ive had a look at add -lcrypto to the linking flags on build time, as this seems to bee needed when linking against snmp stuff: from ifstat's configure.in: # Setting to be able to force linking with -lcrypto.. from netmgr's configure.in: # Net/UCD-SNMP includes v3 support and insists on crypto unless # compiled --without-openssl Since libsnmp is *already* linking with libz and libcrypto, if zabbix itself doesn't use them directly, there's no need for a direct link. However (and this a more important fact that I overlooked), in the case of openssl it would be illegal to link a GPL program with it, since the OpenSSL developers added an advertising clausse that makes it incompatible. A Build-Conflicts should be present in order to avoid this from happening. Alternatively, you could link it with GnuTLS compat layer to see how it works out. *sight*, i have feared this might be the case. However, i dont quite understand the case here. Zabbix does not use any of the openssl headers or functions in its code and is nevertheless linking against libcrypto which is needed because libsnmp9-dev is linked against openssl. Then it's not really needed. Just disable the -lcrypto flag (or add a Build-Conflicts). If you want an explanation for this non-sense, I think the most plausible one is that they enabled direct linking with libz/libcrypto as a workaround for static binary brokenness. I.e. you can't build a static zabbix without -lz -lcrypto Fabio, what do you think about this? Should i start ask Alexei for permission about linking against openssl so we are on the safe side? Unless Alexei recieved copyright assignment papers from all significant (~15 lines) contributions, he can't really (legaly) do that. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
contrib or main?
Hi! gngb is in main, gnuboy is in contrib. They both are GPLed, so the obvious question is, what's the difference? If requiring non-free ROMs to run justifies putting it in contrib, then I think gngb should be moved. Otherwise it's gnuboy that should be moved. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rar support violates DFSG #4
On Fri, Nov 25, 2005 at 07:44:08PM -0800, Steve Langasek wrote: OTOH, if you think my interpretation of DFSG is inadequate, I could try to expose it better, and we could also move this to -legal (perhaps I should have started there in first place). Yes, I still disagree with this reasoning. People of conscience may disagree on whether *preventing* the creation of files that can't be read with free software is serving the goals of the DFSG. In the absence of agreement on this point, I don't think it's right to treat this as a release-critical bug unless the *maintainer* agrees with you. That suggests if the maintainer disagrees in, say, DFSG #1 (Debian will remain 100% free), then we don't have to treat as release-critical an inclussion of non-free in main. I think I'll try to expose better my point, and also move it to -legal. DFSG #4 states: We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. I think it's very clear that the free software community is harmed by promoting trap formats like RAR, so I won't extend on that. For what the needs of our users are concerned, we have basicaly two groups of users with opposed needs: 1- A group of users who want to use rar to produce archives. 2- A group of users who want to extract rar archives produced by the first one. Reasons why I think the latter group is much bigger than the first: - In case user in group #1 is using RAR for private backups/etc, the technical disadvantages of using RAR instead of a combination of tar (better integration with Un*x file metadata) and p7zip (better compression) indicate this is a minority of users. - In case user in group #1 is using RAR for distributing data across the internet, then for each user doing this, it's logical to expect more than one user in group #2 will recieve the file and want to extract it. - In popcon, unrar is roughly 5/4 times more popular than rar. Although this info should be taken with a grain of salt, because many users install rar with the sole purpose of extracting, or simply because it's in Suggests in the packages that are object of this discussion. Therefore I don't think we're serving the interests of our users or the free software community first in our priorities. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#335898: bogus all rights reserved message
On Wed, Oct 26, 2005 at 11:16:14AM -0500, Jeffrey L. Taylor wrote: Quoting Robert Millan [EMAIL PROTECTED]: Package: kfreebsd-5 Severity: normal The following lines are printed by kFreeBSD when boot starts: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. I think there two problems with that: - All rights reserved would imply that the software is not licensed at all, which isn't true. The answers I got from #debian-devel indicate it's perfectly legal to remove this message for clarification. IIRC, the phrase All rights reserved. is required for copyrighted material in some Latin American countries. Without it, it isn't copyrighted. I.e., All rights reserved. is the equivalent of Copyright 2005 I. Author. Of course, IANAL. According to what I've been told in #debian-devel (which makes sense to me), all rights reserved means you have no right to use this software. However, the licensing terms in the source code should take preference. I'm CCing debian-legal, perhaps they can mirror some light into this. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#335898: bogus all rights reserved message
On Wed, Oct 26, 2005 at 10:21:40AM -0700, Josh Triplett wrote: - All rights reserved would imply that the software is not licensed at all, which isn't true. The answers I got from #debian-devel indicate it's perfectly legal to remove this message for clarification. ^ Not unless you are the copyright holder. I meant to say from the boot message here. Does this also apply to the boot log? Your other response below seems to indicate otherwise: [...] alternatively, you could remove the copyright notice *from the boot messages* (since it is not the copyright notice which is governing the work). -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Bug-gnulib] missing licenses in gnulib
On Thu, Oct 07, 2004 at 02:57:45PM +0200, Bruno Haible wrote: I don't want it to give it away in public domain; instead I've added the GPL copyright notice to [lbrkprop.h] now. Thanks! With this and the other commits Paul did, most of my concerns are solved (all of those that affected the lib directory, in particular). Did you reach a consensus in how to deal with the lack of license in m4 and modules directories? -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: [Bug-gnulib] missing licenses in gnulib
On Wed, Oct 13, 2004 at 08:52:17PM +0200, Bruno Haible wrote: Robert Millan asks: Did you reach a consensus in how to deal with the lack of license in m4 and modules directories? Under modules/ I put a copyright notice. great! For m4/* these is still no consensus: Paul Eggert wants GPL for them, whereas I favour a GPL with autoconf-like exception clause license... I think it makes more sense to actualy add a minimal license first and then discuss whether a less restrictive one would be better. Currently it has no license so it's just illegal to do anything with these files. OTOH, if you set them to GPL you can always change it to be less restrictive (as long as you or the FSF owns the copyright, that is). -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: [Bug-gnulib] missing licenses in gnulib
On Wed, Oct 13, 2004 at 09:16:08PM +0200, Robert Millan wrote: On Wed, Oct 13, 2004 at 08:52:17PM +0200, Bruno Haible wrote: Robert Millan asks: Did you reach a consensus in how to deal with the lack of license in m4 and modules directories? Under modules/ I put a copyright notice. great! Uhm. Now that I look at it, doesn't the notice in modules/README contradict the modules files themselves which contain a license tag indicating GPL/LGPL? (I verified each of them does that). -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: [Bug-gnulib] missing licenses in gnulib
On Fri, Oct 01, 2004 at 10:00:25PM +0200, Bruno Haible wrote: Robert Millan wrote: lib/atanl.c lib/logl.c If you look into the glibc CVS log of sysdeps/ieee754/ldbl-128/s_atanl.c and sysdeps/ieee754/ldbl-128/e_logl.c, you see that the copyright holder (Stephen Moshier) has given permission to license them under LGPL. lib/diacrit.c This comes from Fran?ois Pinard's libit-0.2, which is GPL. lib/alloca.c A long-time GNU citizen, distributed as part of many GNU packages. lib/lbrkprop.h For these borrowed files from other GNU or free software projects, I think we still need an explicit note in the files distributed as part of gnulib. Could you please add the license header that corresponds to the license terms of the package from which it was borrowed to these files? IANAL, but I think you can legaly do that. This is an automatically generated file. It's ridiculous to put a copyright license on an automatically generated file if the generating program is available under GPL, since anyone could take that generating program, modify its printf() statements to emit a different license, and run the generating program. I don't know how does copyright law apply to auto-generated programs. Maybe debian-legal can offer advice on this. tests/test-stpncpy.c I've put this under GPL now. Ack. Thanks! The worst problem, however, is in the m4 and modules directories, where most of the files are unlicensed. For the m4 files, I propose to add the standard notice to them: [...] Well let's see how the GPL vs LGPL discussion ends up. I don't really have a take on this. About the modules/ files. I wrote most of them. What kind of copyright would you find useful, given that it's only meta-information? I think when they're copyright-significant GPL would be fine. However, my suggestion is that you set the global COPYING file to say GPL unless stated otherwise. This way we can avoid trouble with copyright-significant misc files like READMEs and such. Oh right, standards.texi is under GFDL. So this means that Debian will not ship the GNU standards in the next release? There's no official statement on this, but the situation is that they may be included with sarge (at the maintainer's discretion) but not for later releases, when the new DFSG that unambigously applies to documentation takes place (see http://www.debian.org/vote/2004/vote_004). -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: [Bug-gnulib] missing licenses in gnulib
On Sat, Oct 02, 2004 at 09:05:51AM +0200, Jim Meyering wrote: dirfd.h is just dirent boilerplate code plus two trivial #if blocks. Not worth worrying about, imho. The guts are in dirfd.m4. getpagesize.h was factored out of GPL'd code. I've added a copyright notice to each of those. Looks fine. Thanks Jim! -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: Moving libcwd to Debian non-free
On Sat, Oct 02, 2004 at 09:48:40PM +0200, martin f krafft wrote: Carlo, I am sorry to inform you that I have decided to move libcwd to Debian's non-free archive, where it will enjoy less support. The debian-legal team has deemed the QPL to be not DFSG-free, and even though I completely understand and subscribe to your rationale, I am not capable of sustaining it in main any longer. Hi Martin, How many packages depend on this library? These should be moved to contrib, and if they're not many you could consider removing libcwd along with them, too. -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: Moving libcwd to Debian non-free
On Mon, Oct 04, 2004 at 07:13:20PM +0200, martin f krafft wrote: also sprach Robert Millan [EMAIL PROTECTED] [2004.10.04.1908 +0200]: How many packages depend on this library? These should be moved to contrib, and if they're not many you could consider removing libcwd along with them, too. Consider removing it? Why? Anyway, I doubt there is a single package that depends on libcwd. We provide non-free packages when our users require them (Social Contract). If there's no demand for libcwd there's no reason to provide it. This is you as the maintainer who should judge that. I think it's specialy appropiate to take this in consideration for a library that has no reverse dependencies. Of course, maybe we should just wait for a response from upstream and see if they want to re-license :). -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: Moving libcwd to Debian non-free
On Mon, Oct 04, 2004 at 07:31:56PM +0200, martin f krafft wrote: also sprach Robert Millan [EMAIL PROTECTED] [2004.10.04.1926 +0200]: We provide non-free packages when our users require them (Social Contract). If there's no demand for libcwd there's no reason to provide it. This is you as the maintainer who should judge that. I need the package myself. [...] Right. So how do I reach out to the 17 users popcon lists? Well, that counts a few users indeed. :) Anyway, as a sidenote I encourage you to find an alternative if the licensing problem cannot be solved. -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: missing licenses in gnulib
On Wed, Sep 22, 2004 at 03:22:01PM +0100, MJ Ray wrote: On 2004-09-22 14:58:24 +0100 Robert Millan [EMAIL PROTECTED] wrote: [ putting debian-legal on CC ] For what end? Because gnulib is ITPed (#272867), we need to sort out possible legal problems before adding it to Debian, and debian-legal may offer advice. To me, this looks like you are trolling a list @gnu.org - please be more precise with your wording on this topic. My current understanding is that the FSF does not consider is this documentation also free software? to be a sensible question, while many debian developers do. I agree with the conclusion that it's better to omit them from discussion for now. Both of us are aware of the issue so it's useless to argue about it. I didn't intend to spawn a discussion on this, but in my report I was listing all the license problems I found in gnulib and I won't hide this from the list as if it didn't exist. I think I was clear enough. -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
missing licenses in gnulib
[ putting debian-legal on CC ] Hi! I'm trying to prepare a Debian package of gnulib, but there seems to be some legal problems we should sort out first. According to the COPYING file, we can't assume GPL for any of the files in the source tree. This is a problem for files that are not explicitly licensed. I've made an exhaustive list in the lib and tests directories: lib/alloca.c lib/atanl.c lib/diacrit.c lib/dirfd.h lib/getpagesize.h lib/lbrkprop.h lib/logl.c tests/test-stpncpy.c The legal status of these is questionable and in some cases they're being distributed illegaly (since copyright holder is not FSF). I have omitted from the check those files that were 15 lines in size since these could be considered not significant for copyright purposes. The worst problem, however, is in the m4 and modules directories, where most of the files are unlicensed. Typicaly, these macros would be implicitly licensed by a COPYING file, but there's no COPYING file covering them. This situation makes it illegal to use most of gnulib's macros in any program (even GPLed ones). There's also the problem with non-free documentation in doc directory (3 files), but I'm aware that for the FSF freedom isn't important for documentation so I'm ommiting the list here. -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `-
Re: [Spi-trademark] Re: Bug#265352: grub: Debian splash images for Grub
On Wed, Aug 18, 2004 at 12:15:39AM -0700, Bruce Perens wrote: Do you want us to remove you guys off this thread until we settle the score? I am fine with being on the list, but please refrain from blaming SPI for this not being done. There were a number of comments to that effect attached to the bug report. I guess this goes for me, too. Please excuse me, I wasn't aware of the real situation. It's pretty understandable that SPI defends Debian's interests, even if such interests are wrong. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: Bug#265352: grub: Debian splash images for Grub
On Tue, Aug 17, 2004 at 08:27:18PM +0100, Roger Leigh wrote: Is the Open Use logo DFSG-free? - From http://www.debian.org/logos/ : Debian Open Use Logo License Copyright (c) 1999 Software in the Public Interest This logo or a modified version may be used by anyone to refer to the Debian project, but does not indicate endorsement by the project. Uh :(. It doesn't explicitly allow redistribution, nor distribution of modified works. It doesn't allow to charge a fee for redistribution.. etc. Doesn't sound free to me. I can't see a problem there (it's much stricter for the official use logo), but there are no restrictions upon use or derived works, so I think it's OK. (It's certainly used by many other Debian packages!) IANAL, but AFAIK when a license doesn't explicitly allow something, it means it's not allowed. I'm adding CC to debian-legal. Can you people send your advice? Thanks. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: Bug#265352: grub: Debian splash images for Grub
On Tue, Aug 17, 2004 at 03:23:22PM -0700, David Schleef wrote: The Debian Open Use Logo License is generally considered to be non-DFSG free. However, it appears to be a widely held belief that Debian should have _some_ logo that is DFSG-free, and that the license of the open logo should be changed to make this so. I think because of the latter, there has never been a logo purge of main. Perhaps an attempted logo purge would convince SPI to act on this matter. What does convince SPI mean here? I thought SPI is governed by the Debian developers. It's somewhat amusing that debian-legal routinely convinces people to change to DFSG-free licenses, but can't seem to affect its own organization. The real question is why a project that is dedicated to free software did release a non-free logo in the first place... -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: Bug#265352: grub: Debian splash images for Grub
On Wed, Aug 18, 2004 at 12:54:06AM +0100, Roger Leigh wrote: I agree. I just thought that Debian stuff would be DFSG free by default, as required by the Social Contract... Yeah, how sad.. Well, then please merge the unaffected images into Luis' package. I hope when we start nuking the non-free logo here and there, this will teach the SPI a lesson. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: Please pass judgement on X-Oz licence: free or nay?
On Tue, Aug 03, 2004 at 02:01:03AM +1000, Daniel Stone wrote: /* * Copyright 2003 by David H. Dawes. * Copyright 2003 by X-Oz Technologies. * All rights reserved. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the Software), * to deal in the Software without restriction, including without limitation * the rights to use, copy, modify, merge, publish, distribute, sublicense, * and/or sell copies of the Software, and to permit persons to whom the * Software is furnished to do so, subject to the following conditions: (I recall hearing something like this from Branden on IRC, but anyway) Doesn't explicitly grant permission to distribute modified software, so it fails to comply with DFSG #3. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: Bug#261600: License violation
On Tue, Jul 27, 2004 at 08:20:39PM +0100, Simon Kelley wrote: [...] Try this Gedanken-experiment: would you still consider the license to be violated of the files were named *.rom in the package and then renamed as *.bin by the postinst script? If so why do you think that a slightly different way of achieving exactly the same result violates the license? How about if the package contained the original C header files, and the postinst script generated .bin files from those? That would sort out 'distribution', but the license says 'usage' must be done as *.rom. However, then we wouldn't be violating upstream license since it is up to the user to illegaly use the package. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: Bug#261600: License violation
On Tue, Jul 27, 2004 at 10:31:41PM +0100, Simon Kelley wrote: The license certainly doesn't say that usage must be done a *.rom, it says that use is permitted provided that _redistribution_ is done as header files or binary image files (and the copyright notices are included) Regardless of the need or otherwise of naming the files in the distribution as .rom, your statement is just false. Ah sorry, my oversight. Then I guess renaming in postinst would be compliant with the license. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
GPL violation in shadow? (was: Re: Bug#244297: Still in license violation. (was: Re: Bug#244297 acknowledged by developer (Bug#244297: fixed in shadow 1:4.0.3-29)))
Hello, This seems like a GPL violation. The debian version of shadow package includes GPLed code from GNU su. This is allowed since shadow's license is 3-clausse BSD (GPL-compatible) but it looks to me that we aren't complying with Section 2 of the GPL which requires that the whole modified work is relicensed. Please could you have a look at the license references in package shadow (version 4.0.3-29)? I believe [shadow]/src/su.c and [shadow]/debian/copyright indicate that the GPL terms only apply to the parts that were originaly GPL and not the whole work. Thanks. On Sat, Jul 03, 2004 at 04:13:22PM -0400, [EMAIL PROTECTED] wrote: close 244297 thanks No, I said /* Some parts substantially derived from an ancestor of: */ and then reproduced the gnu copyright message, which clearly applies to the whole work. kcr Robert Millan [EMAIL PROTECTED] writes: reopen 244297 thanks You added a note to the license header in src/su.c explaining that the _parts_ borrowed from GNU su are licensed under the GPL. This is misleading, because in order to comply with the license terms of GNU su, you have to relicense the whole file under the GPL. Section 2 clearly states: These requirements apply to the modified work as a whole. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T., Ainulindale (Silmarillion)
xvidcore
Hi, I'm going to sponsor xvidcore, an MPEG4 encoding/decoding library (RFP #232658), packaged by Edouard Gomez (one of the upstream developers). I've been pointed out that MPEG4 is convered by a patent. However, also been told that this shouldn't be a problem unless the patent holder is actively enforcing the patent against us. Note that we are already using MPEG4 code in debian (e.g. xine package). Unless someone objects, I'll upload after a few days. (please put me on CC, not subscribed) -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T., Ainulindale (Silmarillion)
License violation in new Plex86
Hi! I believe the new Plex86 project, a fork of the original Plex86 which is currently hosted in Savannah, is in violation of the LGPL license. The main author of Plex86 forked his own project (heh) to create the new Plex86 effort, and relicensed it under the MIT/X license. He asserted that, as the copyright holder, he has permission to do so. But Plex86 included many contributions of different developers under the LGPL. In order to relicense, he'd need either to have permission from each of the copyright holders of the old Plex86 project, or remove/replace the code for which he doesn't own the copyright. I inquired him about this after his license change announcement, and obtained no response: http://sourceforge.net/mailarchive/forum.php?thread_id=2078828forum_id=26580 IMO, the new Plex86's legal status is in a very questionable state, and should not be packaged for Debian unless the situation is clarified. If you do agree with this, I'll add it to the WNPP list of unpackageable software. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T., Ainulindale (Silmarillion)
Re: pvpgn ITP
On Mon, Dec 29, 2003 at 01:34:56PM +0900, Mike Hommey wrote: On Monday December 29 2003 05:09, Robert Millan wrote: I think there should be no problem, specialy since pvpgn hasn't recieved any notice from Blizzard, and they're hosted in Germany where the DMCA doesn't apply. (...) DMCA doesn't apply there, but the local flavour of EUCD (European Union Copyright Directive) does, which is, if I recall correctly, even worse than the DMCA... What is the legal status, then? Does the EUCD forbid redistribution even if the pvpgn hackers haven't recieved any notification from Blizzard? If so, will the situation change? -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T., Ainulindale (Silmarillion)
pvpgn ITP
Hi! I recently ITPed pvpgn (#224163) and would like to ensure there's no legal problem adding it to Debian. The background: - pvpgn is a fork of the (dead) bnetd project. - bnetd was sued by Blizzard on basis of the DMCA, the current legal status is undetermined - in Debian, we already have packages of bnetd, maintained by Dennis L. Clark (CCed). I think there should be no problem, specialy since pvpgn hasn't recieved any notice from Blizzard, and they're hosted in Germany where the DMCA doesn't apply. I'd appreciate advice though. Is it ok for main or should it be uploaded to non-us? -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T., Ainulindale (Silmarillion)
Re: Changes in formal naming for NetBSD porting effort(s)
On Mon, Dec 15, 2003 at 10:40:11PM +, Roger Leigh wrote: Would Debian Aulë be appropriate? Of the fabric of Earth had Aulë thought, to whom Ilúvatar had given skill and knowledge scare less than to Melkor; but the delight and pride of Aulë is in the deed of making, and in the thing made, and neither in posession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. Ainulindalë, J. R. R. Tolkien, /The Silmarillion/. Hey, you just ripped my signature! *G* -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Invariant name in hello's debian/rules file
Hi! Trying to distress a bit the recent *cough* discussion in -private, I think it's a good moment for rising my point in -legal (where it should be). I recently found this in the debian/rules file for GNU Hello (which, it is well known, has been copied to death into hundreds of other debian packages). # Sample debian/rules file - for GNU Hello. # Copyright 1994,1995 by Ian Jackson. # I hereby give you perpetual unlimited permission to copy, # modify and relicense this file, provided that you do not remove # my name from the file itself. (I assert my moral right of # paternity under the Copyright, Designs and Patents Act 1988.) # This file may have to be extensively modified The license states that you can't remove the name from the file itself. I'm sure this is not what Ian intended, but one could add this line all over the file: # Ian Jackson and then it can't be removed. It all gets very confusing if we apply the same reasoning as for GFDL's Invariant sections. What do you people think? -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#156287: Advice on Drip (ITP #156287)
This seems like a big can of worms. I think i'll just fix the bogus direct dependency on libdvdcss for Drip and bring Drip into Debian for now.. thanks all for your help. On Tue, Jul 29, 2003 at 08:01:21PM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 01:49:48AM +, Robert Millan wrote: On Tue, Jul 29, 2003 at 06:14:53PM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 01:02:36AM +, Robert Millan wrote: Whatever. The fact is that when we put Drip, libdvdread and libdvdcss together we obtain what what the DMCA calls a circumvention device for copyright protection technology. This may happen in non-us, but must not happen in main. I don't see any bright line that would be used here to legally distinguish between (Drip+libdvdread+libdvdcss) and libdvdcss by itself. It seems to me that if we're allowed to ship libdvdcss, we're also allowed to ship applications that use it. This is what the DMCA reads: (2) No person shall manufacturate, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component or part thereof, that-- (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; The libdvdcss has the primary purpose of allowing DVD players to reproduce CSS-encoded movies, and not that of circumventing CSS. Any DVD player has the primary purpose of reproducing CSS-encoded movies, so the same applies. Drip is a DVD ripper. Without CSS support, it rips DVDs but doesn't break the CSS protection so it is not put in question. When CSS-enabled, its primary purpose is argueably the circumvention of CSS, which is a technological measure that effectively controls access to a work protected under this title. This is an arbitrary distinction that has no clear basis in the law. You are also circumventing CSS by playing the DVD in question (viewing is also a form of access). Remember that CSS is a standard developed by a consortium of DVD *player manufacturers*, to maintain their hardware profits. Anyway I find this discussion much useless, since the DMCA can't be applied to non-us. SPI is a US corporation, and its assets could be seized as the result of a court settlement against us. AIUI, this is the main reason why CSS-aware software is not already commonplace in non-US. -- Steve Langasek postmodern programmer -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#154281: libdvdcss ITP
[ this thread comes from libdvdcss ITP #154281 ] On Wed, Jul 30, 2003 at 01:21:53PM +0100, Colin Watson wrote: On Wed, Jul 30, 2003 at 02:01:46PM +, Robert Millan wrote: On Wed, Jul 30, 2003 at 11:31:08AM +0200, Sam Hocevar wrote: On Wed, Jul 30, 2003, Robert Millan wrote: As for the legal advice, what do you mean? Do you suggest that we hire a lawyer to advocate in favour of libdvdcss? I suggest we hire a lawyer to tell us whether we may include libdvdcss in Debian _or not_. This is roughly what we did for the crypto-in-main issue. ok. where should this be brought forward? debian-devel? Surely not! Legal issues are for debian-legal. Ok. What are the necessary steps to request that we hire a lawyer to resolve this? Can I do it on my own or is SPI the entity who should take action here? -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#156287: Advice on Drip (ITP #156287)
I'll upload Drip to main when its independant of libdvdcss (through libdvdread), and other technical issues are solved. As for libdvdcss, see the other thread. On Wed, Jul 30, 2003 at 07:02:16AM -0400, Joe Moore wrote: Robert Millan said: This is what the DMCA reads: (2) No person shall [...] import, [...] any technology, product, service, device, component or part thereof, [ like Drip+libdvdread+libdvdcss ] Anyway I find this discussion much useless, since the DMCA can't be applied to non-us. non-us has traditionally been home to software than can not be _exported_ from the US, not software that can not be _imported_ into the US. (references: http://lists.debian.org/debian-legal-0209/msg2.html and more recent discussion on debian-legal which I can't find on the web at the moment.) --Joe -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#156287: Advice on Drip (ITP #156287)
On Wed, Jul 30, 2003 at 01:05:02PM -0400, Jeremy Hankins wrote: I'm not absolutely clear what distinction Steve's referring to, but I assumed it was the distinction between decoding+copying and decoding+playing. My understanding is that it's the decoding (i.e., the circumvention) that's questionable, whether it's copied or played. The whole preventing copying bit is just MPIAA spin; what css actually does is prevent playing (i.e., interpretation of the data). Am I misunderstanding? Adding decss to drip may intuitively *seem* worse than adding decss to a player, but is there legal or factual basis for that? A circumvention device is a circumvention device; that's the whole point with this law. Please let's not bring this discussing again over and over. This issue has been beated to death several times with no result. As Sam Hocevar pointed, we're stuck on it anyway and a good direction to take is hiring a lawyer to analize the situation. Btw, don't confuse decss with libdvdcss. DeCSS is a program for DVD-decoding (somewhat) like Drip. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Advice on Drip (ITP #156287)
On Tue, Jul 29, 2003 at 10:19:53AM +0200, Sam Hocevar wrote: On Mon, Jul 28, 2003, Robert Millan wrote: It is important to note that libdvdcss is _NOT_ part of Drip. There are unofficial libdvdcss packages around, and I added them to Build-Conflicts to ensure Drip is not accidentaly linked against it. Uh? I suggest you have a more precise look at the Drip source code and see how exactly it uses libdvdcss. My understanding is that it does not at all: it only uses libdvdread. The Drip author seems to be largely confusing what is installed at build time and what is present at runtime; the warning about libdvdcss not being present is triggered when libdvdcss is not present on the _build_ system. No, autoconf checks for libdvdcss and if found Drip is linked against it: $ ldd /usr/bin/drip | grep libdvdcss libdvdcss.so.2 = /usr/lib/libdvdcss.so.2 (0x4019a000) My understanding is that Drip being linked against libdvdcss is illegal in the USA, so a solution could be to put it in non-us. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Advice on Drip (ITP #156287)
On Wed, Jul 30, 2003 at 12:21:22AM +0200, Sam Hocevar wrote: $ ldd /usr/bin/drip | grep libdvdcss libdvdcss.so.2 = /usr/lib/libdvdcss.so.2 (0x4019a000) Linking drip with libdvdcss is utterly useless since drip does not use any libdvdcss function. Ok, I understand. I'll find it out when I get the other problems sorted out (depending on the results, the linker issue might not be relevant) My understanding is that Drip being linked against libdvdcss is illegal in the USA, so a solution could be to put it in non-us. Grmbl, please read carefully my first message in this thread. Drip has nothing to do with libdvdcss, only libdvdread uses libdvdcss. Whatever. The fact is that when we put Drip, libdvdread and libdvdcss together we obtain what what the DMCA calls a circumvention device for copyright protection technology. This may happen in non-us, but must not happen in main. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Bug#156287: Advice on Drip (ITP #156287)
On Tue, Jul 29, 2003 at 06:14:53PM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 01:02:36AM +, Robert Millan wrote: Whatever. The fact is that when we put Drip, libdvdread and libdvdcss together we obtain what what the DMCA calls a circumvention device for copyright protection technology. This may happen in non-us, but must not happen in main. I don't see any bright line that would be used here to legally distinguish between (Drip+libdvdread+libdvdcss) and libdvdcss by itself. It seems to me that if we're allowed to ship libdvdcss, we're also allowed to ship applications that use it. This is what the DMCA reads: (2) No person shall manufacturate, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component or part thereof, that-- (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; The libdvdcss has the primary purpose of allowing DVD players to reproduce CSS-encoded movies, and not that of circumventing CSS. Any DVD player has the primary purpose of reproducing CSS-encoded movies, so the same applies. Drip is a DVD ripper. Without CSS support, it rips DVDs but doesn't break the CSS protection so it is not put in question. When CSS-enabled, its primary purpose is argueably the circumvention of CSS, which is a technological measure that effectively controls access to a work protected under this title. Anyway I find this discussion much useless, since the DMCA can't be applied to non-us. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Advice on Drip (ITP #156287)
[ Please CC me, I'm not subscribed ] Hello! I'm finishing the initial release of the Drip debian package (ITP #156287) which is almost ready for upload. The only resting nitpick is a possible legal problem. The README.Debian I'm pasting below explains for itself, I think everything should be ok the way I have put it, but would appreciate confirmation before uploading to the archive. It is important to note that libdvdcss is _NOT_ part of Drip. There are unofficial libdvdcss packages around, and I added them to Build-Conflicts to ensure Drip is not accidentaly linked against it. ---README.Debian start Drip for Debian --- The purpose of this program is the creation of backup copies for your legaly owned DVD movies. Some of these DVD movies implement an annoying CSS protection to prevent you from creating backups, and Drip has support for using the libdvdcss library, which breaks this protection. Such support is, however, disabled in this package because enabling it would violate the DMCA and possibly other laws. This means in some states including but not necessarily limited to, the USA, it might be illegal to build Drip with libdvdcss support enabled, and/or distribute or even use such a build of Drip. Neither the authors of this program, nor the maintainer of the Debian package, nor the Debian project is responsible in any way for the person who illegaly enables libdvdcss support in Drip. If you think it is legal to do that in your state, you can do that (under your entire responsability) by following these instructions: [...blah blah...] ---README.Debian end -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: Advice on Drip (ITP #156287)
Hi Sam, On Mon, Jul 28, 2003 at 07:52:57PM -0400, Sam Hartman wrote: I continue to believe that like other packages already in Debian, supporting libdvdcss if it is found is perfectly reasonable. If you manage to dlopen it and find the right symbols, use it. If someone complains, we can reevaluate the situation at that point. To my understanding, the legal problem is not in libdvdcss nor in drip, but in the combination of them. libdvdcss itself doesn't violate the DMCA because it can be used for purposes other than ripping DVDs (for players), and Drip itself doesn't violate the DMCA because the default configuration has CSS support disabled. However, when put together we have a program that is clearly intended for DVD ripping _and_ able to break CSS. This fits the DMCA definition of a circumvention device of copyright protection technology. I want to have libdvdcss in Debian (it's ITPed, and there's a satisfactory discussion in -legal about it), but avoid this problem particularly. The situation that installing both drip and libdvdcss automagically enables CSS support in Drip (with dlopen) is not acceptable, since it could make the user break law without even knowing it. My approach is that users who explicitly desire to have a CSS-enabled Drip can obtain it (since it's perfectly legal if you don't live in the USA) but no person gets it without knowing what person is doing and thus accepting responsability for pers actions. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Re: copyright violation in libflash
Hi Aubin, On Sun, Aug 04, 2002 at 10:13:39AM -0500, Aubin Paul wrote: Thanks for bring this to my attention; I agree that we should remove the package, as I checked the two files and both mention that they are derived from sample code. I can't believe I didn't see that; I thought the only copyright violation was the old header from Mozilla which was replaced. good luck. Hope that Oliver brings a solution soon.. P.S. Is Oliver using my patches? I think so, I sent them a while ago and he accepted them -- Robert Millan 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5 Andrew S. Tanenbaum, 30 Jan 1992
copyright violation in libflash
Hi Aubin! Olivier Debon (upstream maintainer of libflash) just told me that some files in libflash cannot be licensed under the GPL: ./lib/adpcm.cc ./lib/script.cc because they are (or appear to be) a derived work from macromedia's copyrighted code. he said he's working on a replacement and will release a fixed version in a few weeks. please could you invistigate on this? it could be that libflash needs to be removed from debian until the issue is solved. I'm CCing debian-legal cheers, -- Robert Millan 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5 Andrew S. Tanenbaum, 30 Jan 1992
wpoison, is it okay?
Hi!
Could you take a look at wpoison? (RFP #122929)
I guess it's DFSG compliant but just to make sure...
I've also asked the author for permission to use PNG versions
of his official GIF, do you think the modified license is okay too?
These are the changes for the new license:
27,30c27,34
# software or any derivative or modified version thereof. Also, the
# official Wpoison logo itself must be include in an HTML hyperlink
# so that any usser clicking on any part of the logo image will be
# directed/linked to the Wpoison home page at:
---
# software or any derivative or modified version thereof. Permission
is
# granted to redistribute the official Wpoison logo graphic in
graphic
# formats other than GIF, and to use them to comply with this
statement
# as long as the logo graphic does not suffer any modification.
#
# Also, the official Wpoison logo itself must be include in an HTML
# hyperlink so that any usser clicking on any part of the logo image
will
# be directed/linked to the Wpoison home page at:
Please keep CC to [EMAIL PROTECTED]
Regards,
--
Robert Millan Debian GNU/Hurd user
zeratul2 wanadoo eshttp://getyouriso.dyndns.org/
GPG ID C8D6942C
237F 8688 C2E5 BC64 E152 97B4 FB28 D41B C8D6 942C
Free Dmitry Sklyarov! http://www.freesklyarov.org
Join us in civil disobedience and distribute DeCSS!!
/*efdtt.c Author: Charles M. Hannum [EMAIL PROTECTED]*/
/*Length: 434 bytes (excluding unnecessary newlines)*/
/*Usage is: cat title-key scrambled.vob | efdtt clear.vob */
/*title-key can be read from the DVD by css-auth. (see livid.org)*/
#define m(i)(x[i]^s[i+84])
unsigned char x[5],y,s[2048];main(n){for(read(0,x,5);read(0,s,n=2048);write(1,s
,n))if(s[y=s[13]%8+20]/16%4==1){int i=m(1)17^256+m(0)8,k=m(2)0,j=m(4)17^m(3)9^k
*2-k%8^8,a=0,c=26;for(s[y]-=16;--c;j*=2)a=a*2^i1,i=i/2^j124;for(j=127;++jn
;c=cy)c+=y=i^i/8^i4^i12,i=i8^y17,a^=a14,y=a^a*8^a6,a=a8^y9,k=s
[j],k=7Wo~'G_\216[k7]+2^cr3sfw6v;*k+/n.[k4]*2^k*257/8,s[j]=k^(kk*234)
*6^c+~y;}}
