lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 10 Feb 2008 08:30:37 -0500
From:	Daniel Hazelton <dhazelton@...er.net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Marcel Holtmann <marcel@...tmann.org>, davids@...master.com,
	David Newall <davidn@...idnewall.com>,
	Greg KH <greg@...ah.com>,
	Christer Weinigel <christer@...nigel.se>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: mark USB drivers as being GPL only

On Sunday 10 February 2008 06:20:45 Alan Cox wrote:
> > Why? Because the pre-processor is what is including any GPL'd code in my
> > application and expanding any macros. That is a purely mechanical process
> > and
>
> And its not pirating Windows because Norton Ghost put Microsoft copyright
> material in your hard disk either - thats a mechanical process too. Right
> - no. Nor can the gcc compiler hold the copyright as you suggest as it is
> not a legal person.

It takes someone telling the program to do it. The act of instructing the 
program is the actual "criminal" act. This is a 'Straw Man'. Next ? 

> The compiler might perform a process which combines your creative work
> with another and thus creates a derivative work. It might do that with
> libgcc. In many cases the FSF is being careful when it makes sure
> specific things don't happen just as Linus did with the kernel. Sometimes
> it is best to make sure no judge got a bit carried away and instead to
> create certainty in advance.

Yes, of course, and I'll never argue otherwise. However, what I was saying is 
that it is the claim of the FSF that, in no uncertain terms, a C program that 
uses the standard C library interface and is linked to glibc instead of, say, 
the old Borland libc, is automatically GPL because it's been linked to GPL 
code.

And in the case of the "Bison Exception", lets think of it this way... A 
company writes a configuration file parser and is selling the software to 
other companies for use on their Solaris and SysV machines. The board decides 
to sell the software for linux and the employee in charge of the linux build 
uses the standard GNU tools for the entire process, including Bison. Even 
without the exception it wouldn't make the program a derivative of Bison or 
even come close to  putting the code under the GPL.

> If you really think what you claim then I'll #include your entire work,
> flog it binary only and assure you it can't be derivative as you said so.
> That's entirely mechanical - in fact I can clain a defence of 'estoppel'
> given your previous statement, so you probably wouldn't be able to sue me
> for it even if it was otherwise a violation.

Straw man. Again.

But... You'd have fallen afoul of the "intent". Action follows intent, and so 
does the law. (At least in the US)

> There is btw lots of possibly useful caselaw in the area of books. People
> have spent time litigating and thus established some clearer answers to
> questions like whether you need copyright owners permission for

And I've actually read almost all the court cases that have a bearing on this. 
(I don't step into a discussion unprepared)

If the process of linking could create a derivative work, the *EVERY* program 
that runs on *ANY* OS would be a derivative of that OS, because the program 
is linked to the OS at run-time. 

DRH
PS: It is time for me to shut up now. I'm sick (bronchitis) and when sick, I 
tend to get very combative and come off like a troll.

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ