This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: ecos license question.
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 16 Jan 2003 23:24:37 +0000
- Subject: Re: [ECOS] ecos license question.
- References: <9F77D654ED40B74CA79E5A60B97A087B0423C8@sd-exchange.sdesigns.com>
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