[ECOS] ecos license question.

[Jonathan Larmour]

Fabrice Gautier wrote:
>>But we do want anything based on eCos itself to be made open 
>>so that other benefit.
> 
> Depends what you defined by "based on eCos". Imo for the GPL "based on"
> means also linked.

The exception text is clearer on this than my paraphrase.

>>Also it's not clear when you read the LGPL how well it would apply if 
>>RedBoot was LGPL'd. They may have changed "Library" to 
>>"Lesser" but it's still a libraries licence!
> 
> 
> True, but it still unclear to me how the current eCos license applies to
> Redboot as well. At least the GPL name in the license is confusing me.

I dare say that's because you have a preconception about what GPLing 
implies :-).

>>>2./ You can modify the behaviour of existing eCos code by 
>>>adding hooks in eCos code and calling your own proprietary
>>>functions with those hooks.
>>
>>Actually, according to the FSF under legal advice, not 
>>really. This has 
>>come up before in the context of the LGPL. It is not a sufficiently 
>>separate work. It's a grey area: if you separated it with a 
>>sufficiently generic API, then it _would_ be a separate work!
>>Yes, these types of things are where lawyers make their money :-|.
> 
> 
> So I think we agree, there is a "Grey Area". I hate Grey Area, because you
> do something at the beginning its Black and somehow it's going to end up
> Grey, and once is Grey anything can happen.

It's grey because it is a sliding scale. It's impossible to pin down in 
advance that some amount of integration is too much and another amount 
reasonable, when we don't even know the code involved.

I'm just trying to recall what I remember RMS saying the FSF lawyers had 
said :-). And that was in the context of DLLs strictly anyway. It may not 
be as grey as I make out.

In general the law would consider what would be "reasonable".

> Note that there is already an excpetion in the plain GPL about using "normal
> OS mechanism" (like using syscall for example). So you could have stated in
> the eCos license that those normal OS mechanisme applys also to calling
> documented eCos APIs.

But we don't want to do that. We want people to have the freedom to call 
whatever they want. And there aren't many _official_ APIs in eCos.

> But the current exception is going farther than that
> because i could take says the ide code in redboot and use it in another
> proprietary OS. I would just have to release the IDE source code and provide
> a generic API (which probably already exist).

That's correct. And intentional. If you improved the source code, we would 
(probably, unless 3.(a) of the GPL applies) be able to get the benefit of 
that.

I think our fundamental disagreement here is that allowing people a little 
more freedom to use the code isn't necessarily a bad thing. We just want 
the benefits of the improvements to that code. If we had intended people 
to be able to rebuild things based on eCos from scratch and get the full 
source code (including application code) to do that, then we would have 
GPL'd it without any exception. That wasn't the intention.

Not every open source project has to have full source revealed. Look at BSD.

>>>MPL seems to be the license i know that ressemble the most this eCos
>>>license. I still dont get understand why this is called 
>>>"GPL with exception"
>>>when the exception destroy most of the spirit of GPL...
>>
>>But is incompatible with GPL code, a key aim with the licence change.
> [snip.... dual MPL/GPL ]

Yes, we seriously considered dual RHEPL/GPL too. Complex, confusing, 
enforcement nightmare, and still didn't express our intentions at the time.

Enforcement was a real problem. Many people had been writing new ports, 
new changes etc. and not making their changes available. It wasn't 
tenable. By nailing our colours to the GPL mast it will be much more 
recognisable to users that this is an open source licence. Doing something 
to make the licence _more_ complex would only increase the problem.

> Anyway if I mix pure GPL code with eCos code, the result is GPL right, so
> then I cant mix proprietary code in the result. Same with dual MPL/GPL code.

Yes. And no pure GPL code will be going in the main eCos code base for 
that reason (unfortunately). We may have some sort of off-shoot repository 
down the road.

>>>What would be the difference if eCos was released under MPL ?
>>
>>The RHEPL from before was effectively the MPL with the names 
>>changed. Note that it's very unlikely that eCos's licence would
>>ever be changed now, unless there was some specific legal problem.
> 
> 
> As I said, for me Grey Area is the problem. I know I would consider changing
> to MPL/GPL, but I'm not a Copyright holder, so that just an opinion...

No one has exclusive copyright right now (long story, see 
http://sources.redhat.com/ml/ecos-maintainers "Future code ownership"). 
This will be resolved shortly.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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