Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751586AbXBVNJk (ORCPT ); Thu, 22 Feb 2007 08:09:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751587AbXBVNJk (ORCPT ); Thu, 22 Feb 2007 08:09:40 -0500 Received: from [81.2.110.250] ([81.2.110.250]:49452 "EHLO lxorguk.ukuu.org.uk" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751582AbXBVNJj (ORCPT ); Thu, 22 Feb 2007 08:09:39 -0500 Date: Thu, 22 Feb 2007 14:10:47 +0000 From: Alan To: "D. Hazelton" Cc: "Michael K. Edwards" , "David Lang" , davids@webmaster.com, "v j" , trent.waddington@gmail.com, "Linux-Kernel@Vger. Kernel. Org" , "Neil Brown" Subject: Re: GPL vs non-GPL device drivers Message-ID: <20070222141047.425337a0@lxorguk.ukuu.org.uk> In-Reply-To: <200702212030.58317.dhazelton@enter.net> References: <3d57814d0702191458l1021caeyaefd7775398c5f2a@mail.gmail.com> <200702212030.58317.dhazelton@enter.net> X-Mailer: Claws Mail 2.7.2 (GTK+ 2.10.8; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3469 Lines: 65 > As a side note: The distinct wording of the GPL actually *invalidates* the > GNU/FSF claim that dynamically linking a work with, say, the readline > library, means the work is a derivative of said library. The GPL states (in Not that I can see no, but you could take this to a list with lawyers not programmers on and improve life for both parties > clause 0) that the license only covers copying, modification and > distribution. Unless they are confusing "Linking" with "copying" or "creating > a derivative work" the claim is invalid - because, as it has been shown, a > mechanical process such as compilation or linking *cannot* create a > derivative work. If you take the microsoft windows source code and compile it yourself believe me you will get sued if you ship the resulting binaries and you will lose in court. Copyright law deals with the right to copy hence the name. Generally speaking your right to use a work you have a copy of isn't constrained (and isn't constrainable) by pure copyright, only by contract. The author of a book for example has no power to stop you boiling the book if you don't like it, or using it as bog paper. I would also note that the FSF makes no claim about dynamic v static linking, merely about derivative works - which is the boundary the law is interested in. Indeed the GPLv2 was written in the days where dynamic linking was quite novel which is one reason the LGPL talks about "For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights." and says nothing about dynamic/static linking. > Related to that... Though a parser generated by Bison and a tokenizer > generated by Flex both contain large chunks of GPL'd code, their inclusion in > the source file that is to be compiled is mechanical - the true unique work > is in writing the file that is processed by the tool to produce the output. Flex is more complex because the resulting binary contains both compiled work of yours and a support library of FSF owned code (-lfl). The non computing analogy here is the difference between using a paint program to create a work, and using a paint program to create a work but also including other artwork (eg clipart). The same is true of the GCC compiler as it merges your work with supporting library helper code modules which are themselves creative works. Clearly you could replace those helper modules with your own work and the result would be different. A better example for your case might be indent where the program processes your work mechanically and produces an output that doesn't contain any other creative works, or most of intltools which merges translations mechanically. (the merge code is sometimes a little creative but thats in the sense of being a nuisance not in the legal sense of creative work) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/