[ECOS] ecos licensing

[ECOS] ecos licensing

[Christopher Cordahi]

Hello,

This might be a silly question, but what is the difference between the
ecos license (GPL with a special exception) and the LGPL?

-- 
Chris

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos licensing

[Jonathan Larmour]

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.

Then there's ambiguity about the legal status of inline code and macros, 
which eCos uses extensively.

Altogether that leads to the current license wording.

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

Re: [ECOS] ecos licensing

[Christopher Cordahi]

On 09/08/06, Jonathan Larmour <jifl@ecoscentric.com> 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.

> 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.

> 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.

-- 
Chris

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] ecos licensing

[Jonathan Larmour]

Christopher Cordahi wrote:
> On 09/08/06, Jonathan Larmour <jifl@ecoscentric.com> 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

[ECOS] eCos Licensing

[Himanshu Patel]

Hi,

I have gone through the eCos licensing on following page:
http://ecos.sourceware.org/license-overview.html

However I am slightly confused...If I develop an application and link
the same with eCos kernel (Ttarget.ld), then also I need to release the
application to community? The GPL will apply to application developed
based on kernel also.
Also can I used header files of eCos in the application? 

Regards,

Himanshu Patel

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss