From owner-freebsd-chat@FreeBSD.ORG Fri Oct 29 01:15:38 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAFF516A4CE for ; Fri, 29 Oct 2004 01:15:38 +0000 (GMT) Received: from mail1.webmaster.com (mail1.webmaster.com [216.152.64.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id D041C43D39 for ; Fri, 29 Oct 2004 01:15:38 +0000 (GMT) (envelope-from davids@webmaster.com) Received: from however by webmaster.com (MDaemon.PRO.v7.1.0.R) with ESMTP id md50000248837.msg for ; Thu, 28 Oct 2004 17:51:37 -0700 From: "David Schwartz" To: Date: Thu, 28 Oct 2004 18:15:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41815B2B.7070801@gmx.de> X-Authenticated-Sender: joelkatz@webmaster.com X-Spam-Processed: mail1.webmaster.com, Thu, 28 Oct 2004 17:51:37 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 206.171.168.138 X-Return-Path: davids@webmaster.com X-MDaemon-Deliver-To: chat@freebsd.org X-MDAV-Processed: mail1.webmaster.com, Thu, 28 Oct 2004 17:51:41 -0700 cc: TM4525@aol.com cc: tedm@toybox.placo.com Subject: RE: GPL vs BSD Licence X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: davids@webmaster.com List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 01:15:39 -0000 > But then, I'm not sure (and I mean it) if there can be any piece of > software which, if designed for e.g. Linux, can be written w/o using any > system headers, libraries or whatsoever. You can do this with only moderate difficulty and moderate inefficiency if you want to. All you have to do is: 1) Define your own kernel interface that your proprietary module will use. 2) Implement this interface in a kernel module that is GPL. 3) Distribute your proprietary module such that it uses only your own interface. This way, your module need only use your own headers, which you distribute under the GPL as well as other licenses. The inefficiency comes from having to convert between your own structures and values to and from the Linux kernel structures and values. If you're really clever, you can rig it so that the conversion reduces to no-ops on at least some kernel versions for many conversions, still without using the Linux kernel header files. You are also free to use subterfuge of any kind to get around any restrictions the Linux kernel may attempt to impose upon you because these are not license enforcement mechanisms. The Linux kernel does not, and *may* not, contain any license enforcement mechanisms that affect *use*, and obviously anything that could affect the runnning of your module would be affecting use. (The GPL does not restrict use and prohibits any 'additional restrictions', thus any thing that seemed to be an additional restriction could not be a license enforment mechanism because the restriction is not in the license.) DS