This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ecos license question.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]