From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28536 invoked by alias); 11 Aug 2006 12:51:16 -0000 Received: (qmail 28527 invoked by uid 22791); 11 Aug 2006 12:51:15 -0000 X-Spam-Check-By: sourceware.org Received: from snape.ecoscentric.com (HELO snape.ecoscentric.com) (212.13.207.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Aug 2006 12:51:06 +0000 Received: from localhost (localhost [127.0.0.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 39C822C011; Fri, 11 Aug 2006 13:51:01 +0100 (BST) Received: from snape.ecoscentric.com ([127.0.0.1]) by localhost (snape.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opg+jFL-q4Vp; Fri, 11 Aug 2006 13:50:58 +0100 (BST) Message-ID: <44DC7D32.4070702@eCosCentric.com> Date: Fri, 11 Aug 2006 12:51:00 -0000 From: Jonathan Larmour User-Agent: Thunderbird 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: Christopher Cordahi CC: ecos-discuss@ecos.sourceware.org References: <44DA112C.40907@eCosCentric.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] ecos licensing X-SW-Source: 2006-08/txt/msg00109.txt.bz2 Christopher Cordahi wrote: > On 09/08/06, Jonathan Larmour wrote: >> Christopher Cordahi wrote: >> > Hello, >> > >> > This might be a silly question, but what is the difference between the >> > ecos license (GPL with a special exception) and the LGPL? >> >> It's similar in principle. But binary forms of eCos code are not always >> delivered as a "library". Take RedBoot for example. > > Reading the LGPL license more carefully, I see that although they redefine > that a library is a collection of code, they still cling to the idea > that it be a > library which is not completely standalone. But then I don't understand > how > OpenOffice.org can use it for a license, but that's way off topic. I agree. The incongruity with legal wording is asking for trouble, and that's certainly not something we wanted. >> Then there's ambiguity about the legal status of inline code and macros, >> which eCos uses extensively. > > Do you mean that the LGPL would restrict the use of inline code and macros > available in eCos headers by proprietary code. Their use by eCos shouldn't > be a problem since it is GPL compatible. The delineation of where a derived work starts and stops is far more difficult in the context of inline code and macros. You only have to look at a GCC intermediate .i file to realise that it can be hard not to potentially spread the GPL/LGPL terms into application code, and our absolute goal with the exception is to make clear that (proprietary) application code is separate from eCos itself. So that's what this aspect of the exception tackles. The same issue is faced by libstdc++, and if you look at its license wording (a different form of GPL + exception) it makes the same allowances. But it still wasn't quite appropriate literally, or in our opinion, clear. >> Altogether that leads to the current license wording. > > Thanks for the clarification, I think I understand. > > Although the essence of the LGPL is commonly understood, the wording > of the LGPL seems to introduce additional requirements producing a legal > grey zone. > > The eCos special exception is much clearer, downside is one > more license to manage. Indeed. It would be nicer if the FSF had some standard sets of exceptions. But there'd probably be a philosophical objection to appearing to condone it (despite it happening all the time with libgcc, libstdc++, GUILE, etc.etc.). Jifl -- eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts ------["The best things in life aren't things."]------ Opinions==mine -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss