public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
@ 2001-05-29  1:38 Adam J. Richter
  0 siblings, 0 replies; 37+ messages in thread
From: Adam J. Richter @ 2001-05-29  1:38 UTC (permalink / raw)
  To: alan; +Cc: aaronl, acahalan, adam, dledford, jas88, linux-kernel, lk, lm

> = Alan Cox
>>  = lk@tantalophile.demon.co.uk?
>>> = ??

>>> AFAICS, the firmware is just a file served up to the device as needed
>>> - no more a derivative work from the kernel than my homepage is a
>>> derivative work of Apache.
>> 
>> Indeed.  But if you compiled your home page, linked it into Emacs to
>> display on startup, and distributed the binary, the _combination_
>> "Emacs+homepage" binary would be a derived work, and you'd be required
>> to offer source for both parts.

>In which case GNU Emacs violates the GPL by containing a copy of COPYING which
>is more restricted than the GPL. After all it displays copying on a hotkey
>combination

	"M-x describe-copying" just displays the file
/usr/share/emacs/<version>/etc/COPYING.   The emacs binaries do not
contain the text of GPL.

	By the way, if one wanted to #include the text of the GPL,
then, in the specific case of the GPL, one could argue that the
restrictions on modifying the GPL are part of the GPL and, therefore
not further restrictions.  (Even though those restrictions occur before
the "preamble", they're just as binding and removing them would be a
change to the GPL, so they are an existing restriction of the GPL rather
than a further restriction.)

	That said, I have long advocated that authors use
GPL-compatible copying conditions for everything, including plain text,
to facilitate free software effects on platforms that comingle code
and documentation, such as many web pages and some other interactive
media.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
A
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
@ 2001-05-26 11:09 Adam J. Richter
  0 siblings, 0 replies; 37+ messages in thread
From: Adam J. Richter @ 2001-05-26 11:09 UTC (permalink / raw)
  To: jas88; +Cc: aaronl, acahalan, dledford, linux-kernel, lm

James Sutherland wrote:
>On Fri, 25 May 2001, Adam J. Richter wrote:
>> Larry McVoy wrote:
>> >On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:

>> >It's also about the concept of boundaries - if you think that that
>> >concept is not a legal one then why aren't all programs which are run
>> >on top of a GPLed kernel then GPLed?
>>
>> 	Apparently Linus felt that that was a sufficiently
>> plausible gray area that he addressed it explicitly in
>> /usr/src/linux/COPYING:
>>
>> |   NOTE! This copyright does *not* cover user programs that use kernel
>> | services by normal system calls - this is merely considered normal use
>> | of the kernel, and does *not* fall under the heading of "derived work".
>> | Also note that the GPL below is copyrighted by the Free Software
>> | Foundation, but the instance of code that it refers to (the Linux
>> | kernel) is copyrighted by me and others who actually wrote it.

>Note the "derived work"; there is no way on this earth (or any other) that
>you could regard the device's firmware as being a "derived work" of the
>driver! AFAICS, the firmware is just a file served up to the device as
>needed - no more a derivative work from the kernel than my homepage is a
>derivative work of Apache.

	Nobody is arguing that it is illegal to copy the keyspan
firmware by itself.  What I think is clearly illegal is copying the
whole keyspan .o file, not because it infringes the firmware copyrights,
but because it infringes the GPL'ed material's copyrights.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
@ 2001-05-26  3:10 Adam J. Richter
  2001-05-26 11:00 ` James Sutherland
  0 siblings, 1 reply; 37+ messages in thread
From: Adam J. Richter @ 2001-05-26  3:10 UTC (permalink / raw)
  To: lm; +Cc: aaronl, acahalan, dledford, linux-kernel

Larry McVoy wrote:
>On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:
>> 	Contracts for slavery are specifically not enforceable due to
>> the 13th Amendment, and there is also a stronger question of formation

>Completely misses the point.  THe point isn't about slavery, come on, Adam,
>it's about putting unenforceable things into contracts.

	The point is you have to agree to the contract that is the
GPL to get the right to make a copy of a GPL'ed work.  You raised
the ridiculous example of slavery apparently as an analogy to the
requirements of permissions on copying conditions that go beyond
restrictions one is subject to anyway by copyright.  The point
is that you can make require someone to agree to conditions that
go beyond the restrictions already imposed by copyright in exchange
for permission to, for example, make a copy, so your argument about
the boundaries of copyright is inapplicable.  The GPL is enforceable.

>It's also about the concept of boundaries - if you think that that 
>concept is not a legal one then why aren't all programs which are run
>on top of a GPLed kernel then GPLed?

	Apparently Linus felt that that was a sufficiently
plausible gray area that he addressed it explicitly in
/usr/src/linux/COPYING:

|   NOTE! This copyright does *not* cover user programs that use kernel
| services by normal system calls - this is merely considered normal use
| of the kernel, and does *not* fall under the heading of "derived work".
| Also note that the GPL below is copyrighted by the Free Software
| Foundation, but the instance of code that it refers to (the Linux
| kernel) is copyrighted by me and others who actually wrote it.


	I believe you could enforce copying conditions on a kernel
where, in order to have the right to make a copy of the kernel, you
agree only to run certain types of programs.  I believe Windows CE
has historically been "licensed" this way.

	I did not say that you cannot define boundaries and I also
think you can even make inferences that a judge is likely to agree
with.  What I am saying is that in order to have the right to make
a copy of the of the GPL'ed code in the keyspan_usa drivers, you
must agree to everything the GPL requires, and those requirements
do not have to be limited to the boundaries of the author's existing
copyright.  The GPL is a contract.  If you don't agree to it, don't
do anything with GPL'ed material that the copyright monopoly restricts.

	I am not a lawyer, so please do not rely on this as legal advice.


Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
@ 2001-05-26  2:34 Adam J. Richter
  2001-05-26  2:38 ` Larry McVoy
  2001-05-26  4:52 ` Jeff V. Merkey
  0 siblings, 2 replies; 37+ messages in thread
From: Adam J. Richter @ 2001-05-26  2:34 UTC (permalink / raw)
  To: lm; +Cc: aaronl, acahalan, dledford, linux-kernel

Larry McVoy writes:
>On Fri, May 25, 2001 at 10:02:08AM -0700, Adam J. Richter wrote:
>> 	If you want to argue that a court will use a different definition
>> of aggregation, then please explain why and quote that definition.  Also,
>> it's important not to forget the word "mere."  If the combination is anything
>> *more* than aggregration, then it's not _merely_ aggregation.  So,
>> if you wanted to argue from the definition on webster.com:

>Adam, the point is not what the GPL says or what the definition is.
>The point is "what is legal".  You can, for example, write a license
>which says

>	By running the software covered by this license, you agree to 
>	become my personal slave and you will be obligated to bring
>	me coffee each morning for the rest of my life, greating
>	me with a "Good morning, master, here is your coffee oh
>	most magnificent one".

>If anyone is stupid enough to obey such a license, they need help.
>The problem is that licenses can write whatever they want, but what they
>say only has meaning if it is enforceable.  The "license" above would
>be found to be unenforceable by the courts in about 30 seconds or so.

	Contracts for slavery are specifically not enforceable due to
the 13th Amendment, and there is also a stronger question of formation
of a binding contract in your example, because the proposed mode of
acceptance (related to the pointers I provided before) is doing
something that you might have the right to do regardless of copyright
(running the program as opposed to distributing copies).  I believe
that people write contracts all the time that prohibit distribution of
certain works with others, for marketing reasons.

>OK, so what does this have to do with aggregration?  The prevailing 
>legal opinions seem to be that viral licenses cannot extend their
>terms across boundaries.

	We're not talking about mythically changing the copyright
status of another work.  If your opinion is "prevailing" please
include a reference to a section of the US code, a court decision
or some reference that one could actually track down.

	By the way, I have asked a lawyer at an IP litigation firm
that we use about this and he indicated the copyright infringement case
was quite strong.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
@ 2001-05-25 17:02 Adam J. Richter
  2001-05-25 17:23 ` Jacob Luna Lundberg
                   ` (2 more replies)
  0 siblings, 3 replies; 37+ messages in thread
From: Adam J. Richter @ 2001-05-25 17:02 UTC (permalink / raw)
  To: dledford; +Cc: aaronl, acahalan, linux-kernel

Doug Ledford wrote:
>"Adam J. Richter" wrote:

>>         On the question of whether this is nothing more than
>> aggregation,

>Yes, on that very question, I would argue it is a mere aggregation.

>> the firmware works intimately with the device driver to
>> produce a unitary result.

>Irrelevant.

        The 1991 Abridged 6th Edition of _Black's Law Dictionary_
defines "aggregation" thusly (unfortunately, talking in terms of
patent law, but it is the most authoratitive definition I have found
so far):

        Aggregation: The combination of two or more elements in patent claims,
        each of which is unrelated and each of which performs separately and
        without cooperation , where combination does not define a composite
        integrate mechanism.  Term means that the elements of a claimed
        combination are incapabile of co-operation to produce a unitary
        result, and in its true sense does not need prior art patents to
        support it.


	If you want to argue that a court will use a different definition
of aggregation, then please explain why and quote that definition.  Also,
it's important not to forget the word "mere."  If the combination is anything
*more* than aggregration, then it's not _merely_ aggregation.  So,
if you wanted to argue from the definition on webster.com:

	1 : a group, body, or mass composed of many distinct parts
	    or individuals
        2 a : the collecting of units or parts into a mass or whole
	  b : the condition of being so collected

	You have to argue that absolutely nothing more than this
is being done.  For example, the code the parts are not working
together.

>All drivers work with some sort of firmware on their respective
>targets to produce a unitary result, even if that firmware is implemented with
>silicon (as a ROM BIOS that loads the proper firmware code, or as
>microcode/state hardware built into the chip(set) itself).  As a closely
>similar device, think about the 1542 SCSI controller.  [...]

	Yes.  It would also be illegal to distribute a GPL'ed driver
.o that #include'd that proprietary firmware.

>>  You actually have to do some
>> kernel development to remove the
>> [proprietary firmware from the keyspan_usa drivers].


>That's because you are assuming that uploading garbage to the device is not an
>option.

	No.  If I you change the driver to upload garbage, your
userland loader that just looks for the unitialized device ID will
not be able to get to the uninitialized device before the device
driver claims the interface and trashes it.  So, your supposed act of
disaggregation by zeroing out the effected bytes did not fully
restore the old functionality.

	By the way, I'm pretty sure that the situation is even
worse.  The modified driver would not just load garbage to the
ezusb device.  It would tell the ezusb device to jump to it, so
you would not be able to talk to it after that point, other than
by telling the kernel to reset the hub port that the ezusb device
is connected to, in which case, the keyspan_usa driver will again
grab the device and trash it.

	I would also argue that searching for a lengthy bit string
in file format and carefully zeroing it out is enough complexity
so that the connection between the two pieces of information (the
firmware integrated in the .o and the rest of the .o) are more
than just aggregation.

	I'm not denying that you could imagine a case that is a gray
area where the FSF's understood intention in writing the GPL as
interpreted by a judge from the GPL _and other evidence_ under the
four corner's rule may have been to allow it, but I don't think
we're anywhere near it.  But I agree that one could find some
point where it's a judgement call.  If you get sued and the judge
agrees with the plaintiff, you can lose your house, you life's savings,
etc.  in statutory damages at, I believe, $50k per act of copying.
If the judge agrees with you, well, then you have the satisfaction
of winning that argument.  I hope you appreciate the asymmetry of
the risk and have similarly calibrate your standards for caution,
at least when you advocate exposing others to these kinds of risks.

>> you could just skip distribution of an extra file and have the rest of
>> the functionality work. 

>That is exactly the case.  The only change that must be made to remove that .h
>file from the driver source is to tell the driver where the *new* location of
>the correct firmware is.

	What do you mean "remove the .h file" from the .o and
"tell the driver" (open your mouth and talk to the screen?).
We are talking about a .o file.  Copying the .o file is the
act of infringement.

	Also, if you're going to respond further, please also
answer the following question.  Are you claiming that the FSF intended
to allow a GPL'ed .o file that contains proprietary firmware for another
microprocessor or are you claiming that FSF made a drafting error in
the writing the GPL?

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
@ 2001-05-25 10:36 Adam J. Richter
  0 siblings, 0 replies; 37+ messages in thread
From: Adam J. Richter @ 2001-05-25 10:36 UTC (permalink / raw)
  To: hugh; +Cc: aaronl, acahalan, greg, linux-kernel, linux-usb-devel

	Here's a surprise.  I think the problems with the keyspan
copyrights may have sprung from an administrative error.  I notice that
the copyright notices in
linux-2.4.*/drivers/usb/serial/keyspan_usa{26,28,49}msg.h, which look
GPL compatible to me, look as if they were intended for
keyspan_usa{18x,19,28,28x,49w}_fw.h, since they refer to firmware
in their titles:

        Copyright (c) 1998-2000 InnoSys Incorporated.  All Rights Reserved
        This file is available under a BSD-style copyright

        Keyspan USB Async Firmware to run on Anchor EZ-USB
                          ^^^^^^^^


	Yet, the keyspan*msg.h files have no firmware.  The firmware
is in keyspan_usa*_fw.h.

	Hugh, perhaps you could pass this up the chain of command
at Keyspan and see if they will simply grant permission to
replace the *_fw.h copyright notice with the one from *msg.h, which
is probably a lot simpler than having them spend lawyer and management
time on writing new terms.

	I have cc'ed this to linux-kernel because there is a
current discussion going on there on this subject that I had just
responded to.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
@ 2001-05-25  9:34 Adam J. Richter
  2001-05-25 16:06 ` Doug Ledford
  0 siblings, 1 reply; 37+ messages in thread
From: Adam J. Richter @ 2001-05-25  9:34 UTC (permalink / raw)
  To: acahalan; +Cc: aaronl, linux-kernel

>> = Aaron Lehmann <aaronl@vitelus.com>.
>  = Albert D. Cahalan <acahalan@cs.uml.edu>

>> 	I believe this infringinges the copyrights of the authors
>> of the code used in these drivers who released their code under GPL.
>> Alan Cox, has gone on a campaign claiming that this is "mere aggregation"

>As far as the Linux kernel is concerned, firmware images are
>not software at all. They are large magic numbers that must
>be written to the hardware. (they don't execute on your CPU)

>If a driver writes 0x63f30e44 (4 bytes) to the card, no problem?
>Fine, how about 0x52e590a84fc8231e (8 bytes) then? You can see
>where this is leading I hope: 200 kB is perfectly fine.

>It's obviously not size that matters. What matters is that Linux
>doesn't transfer control into the firmware; that is, Linux does
>not do a jump into firmware like this:

>goto *((void*)firmware);

	I have never heard of this legal standard.  A reference
to some section of Title 17 in the United States Code (copyright), a
relevant court precedent, etc. would be appreciated.

	I am not a lawyer, so please do not use this as legal advice.

	A software "license" typically grants you permission to do
things that you would not otherwise be allowed to do with a
copyrighted work in the absense of any permission (such as make a copy
in most cases), provided that you meet certain conditions.  Those
conditions could be nearly anything.  They're not necessarily limited
to what is restricted by copyright.  I used to think it was so limited
due to copyright preemption of state law by title 17 of US Code section
301, http://www4.law.cornell.edu/uscode/17/301.html, but apparently
this does not appear to be so according, for example, to
http://www.richmond.edu/~jolt/v1i1/hardy.html#fn13, which references
"Hines v. Davidowitz, 312 U.S. 52, 67 (1941), reaffirmed in Sears,
Roebuck & Co. v. Stiffel Co., 376 U.S. 225, reh'g denied, 376 U.S.
973 (1964)", which I HAVE NOT READ, but I have read other things about
this question and this just happens to be what I could dig up in a few
seconds on google.

	If I recall correctly, doing something that is only legal if
you had accepted an agreement is acceptance according to some
provision of the uniform commercial code.  (No, it's not new.  I think
at http://www.law.cornell.edu/ucc/2/2-206.html, section 1a, and the
definition of goods to include "goods in action" in
http://www.law.cornell.edu/ucc/2/2-105.html#Goods_2-105).

	From this, I hope we can agree that is possible to write
copying conditions that prohibit make any copies of certain free
software contained in the keyspan_usa drivers if the keyspan_usa firmware is
also distributed in the same driver ".o" file, and that the question
is simply whether the GPL does so.

	So, Albert, are you claiming that the FSF intended to allow a
GPL'ed .o file that contains proprietary firmware for another
microprocessor or are you claiming that FSF made a drafting error in
the writing the GPL?

	If you believe you have found an error in the GPL, do you
think a court would let you out of it given the four corners rule
(basically using evidence of the understood meaning of an agreement to
interpret what was actually written down)?

	On the question of whether this is nothing more than
aggregation, the firmware works intimately with the device driver to
produce a unitary result.  The part of the driver that runs in the
device and the CPU side speak a mutually agreed upon protocol, and the
unitary result is that you do not have to preload the firmware as
earlier versions of the driver required.  You actually have to do some
kernel development to remove the code.  It's not simply the case that
you could just skip distribution of an extra file and have the rest of
the functionality work.  In fact, even if you zeroed out the
microcode, you would still not get the result of having the driver
work (e.g., if you had loaded the code originally).  Instead, the
driver would fill the device with all zeroes.  Greg Kroah-Hartman has
already said he thinks removal is complicated enough that he does not
want to voluntarily do it in 2.4.  For these reasons, this situation
is not just shipping two works next to each other (mere aggregation).

	I hope it should be clear now that the GPL can and does
prohibit #include'ing this and that it is not mere aggregation.

	I also hope that people understand that while I think the
stability argument for not including my fix in 2.4 (which everyone
seems to like technically) is BS, I would be satisfied if the
keyspan_usa drivers were now released under GPL-compatible copying
conditions.  However, it has now been weeks this has not been done.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 37+ messages in thread
[parent not found: <200105250559.f4P5x80365151@saturn.cs.uml.edu>]
[parent not found: <Pine.BSF.4.21.0105242155540.4849-100000@beppo.feral.com>]
* Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
@ 2001-05-25  4:34 Aaron Lehmann
  2001-05-25  5:07 ` Greg KH
                   ` (2 more replies)
  0 siblings, 3 replies; 37+ messages in thread
From: Aaron Lehmann @ 2001-05-25  4:34 UTC (permalink / raw)
  To: linux-kernel

This message sparked a long thread on the debian-legal mailing list,
which is long since dead. I am personally very curious about whether
this has been resolved upstream. I consider it a very important issue,
which is why I asked for RMS' opinion. He said that what is being done
is clearly not "mere aggregation", and that such firmware should be
moved out of the kernel (and even the tarball) to stop violating the
GPL and make Linux be free software.

As a user of hardware which requires firmware like this, I have mixed
feelings, but feel strongly that requirements of the GPL clearly
override any measure of convenience. Are there any plans to remove the
binary-only firmware from the kernel, and/or eventually from the Linux
source distribution? I am not refering to this USB driver
specifically, but rather the general occurance of firmware embedded in
Linux device trivers.

----- Forwarded message from "Adam J. Richter" <adam@yggdrasil.com> -----

From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Sun, 22 Apr 2001 12:53:48 -0700
To: debian-legal@lists.debian.org
Subject: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h


	Linus's Linux kernel releases from 2.3.50 through the latest
test release (2.4.4-pre6) contain GPL-incompatible "firmware" images
for "EZUSB" devices in linux/drivers/usb/serial/keyspan*fw.h, which
are #included into drivers which contain GPL'ed code, even when compiled
as modules.

	I believe this infringinges the copyrights of the authors
of the code used in these drivers who released their code under GPL.
Alan Cox, has gone on a campaign claiming that this is "mere aggregation"
and insists that I bring in the lawyers to prove him otherwise.  I
really do not want to take this step, but he is forcing my hand.  Note
that Yggdrasil is a copyright owner in this case.

	To simplify removal of the offending code, I have provided
a separate user level facility that can use the USB "hot plugging"
system to automatically load that "firmware" or any other.  The USB serial
maintainer already plans to switch to it in 2.5, and has tested it and
verified that it works.  The software and a kernel patch to remove
the offending code is FTPable from
ftp://ftp.yggdrasil.com/pub/dist/device_control/ezusb/.  The kernel patch
also moves the "whiteheat" code loading into the same user space utility,
just for technical reasons, even though that code can apparently be legally
included in the kernel.  Note that even without this software, the EZUSB
firmware can apparently be loaded by other facilities or from other
operating systems.

	Here is what people involved in Debian should do:

		1. Make sure that no Debian release or snapshot that
		   includes a kernel from 2.3.50 through the current
		   one (don't know if there are any yet) includes
		   linux/drivers/usb/serial/keyspan*fw.h.  By the way,
		   even if there were no legal liability, these files
		   could not be in the "free" part of Debian, if I
		   read the Debian Free Software "Guidelines" correctly.

		2. Possibly include the user level software FTPable from
		   Yggdrasil, although be warned that that code will probably
		   be replaced in the near future to use an input file
		   format more compatible with other development tools used
		   for EZUSB 8051 microcontroller software development.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."


-- 
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



----- End forwarded message -----

-- 
#define m(i)(x[i]^s[i+84])<< /* I do not condone improper use of this code */
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^i&1,i=i/2^j&1<<24;for(j=127;++j<n
;c=c>y)c+=y=i^i/8^i>>4^i>>12,i=i>>8^y<<17,a^=a>>14,y=a^a*8^a<<6,a=a>>8^y<<9,k=s
[j],k="7Wo~'G_\216"[k&7]+2^"cr3sfw6v;*k+>/n."[k>>4]*2^k*257/8,s[j]=k^(k&k*2&34)
*6^c+~y;}}//Please join us in civil disobedience and distribute DeCSS(or efdtt!)

^ permalink raw reply	[flat|nested] 37+ messages in thread
end of thread, other threads:[~2001-05-29  1:41 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <mailman.990765360.7016.linux-kernel2news@redhat.com>
2001-05-25  6:02 ` Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h Pete Zaitcev
2001-05-29  1:38 Adam J. Richter
  -- strict thread matches above, loose matches on Subject: below --
2001-05-26 11:09 Adam J. Richter
2001-05-26  3:10 Adam J. Richter
2001-05-26 11:00 ` James Sutherland
2001-05-29  0:03   ` Jamie Lokier
2001-05-29  0:24     ` Alan Cox
2001-05-29  0:55       ` Jamie Lokier
2001-05-26  2:34 Adam J. Richter
2001-05-26  2:38 ` Larry McVoy
2001-05-26  4:52 ` Jeff V. Merkey
2001-05-25 17:02 Adam J. Richter
2001-05-25 17:23 ` Jacob Luna Lundberg
2001-05-25 18:30 ` Larry McVoy
2001-05-25 22:30   ` Aaron Lehmann
2001-05-26  1:43     ` Larry McVoy
2001-05-25 19:14 ` Doug Ledford
2001-05-25 10:36 Adam J. Richter
2001-05-25  9:34 Adam J. Richter
2001-05-25 16:06 ` Doug Ledford
     [not found] <200105250559.f4P5x80365151@saturn.cs.uml.edu>
2001-05-25  6:03 ` Aaron Lehmann
2001-05-25  6:34   ` Alexander Viro
2001-05-25  6:42     ` Aaron Lehmann
2001-05-25  6:58       ` Alexander Viro
2001-05-25  7:02       ` Andreas Jaeger
2001-05-25  7:05         ` Alexander Viro
2001-05-25 10:56     ` Erik Mouw
2001-05-25 11:56       ` Alexander Viro
2001-05-25 12:44     ` Pavel Machek
     [not found] <Pine.BSF.4.21.0105242155540.4849-100000@beppo.feral.com>
2001-05-25  5:57 ` Aaron Lehmann
2001-05-25  6:26   ` Matthew Jacob
2001-05-25  6:31     ` Aaron Lehmann
2001-05-25  4:34 Aaron Lehmann
2001-05-25  5:07 ` Greg KH
2001-05-25 10:00 ` John Cavan
2001-05-25 11:10   ` Alan Cox
2001-05-25 16:17 ` Alan Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox