This is the mail archive of the ecos-discuss@sourceware.org 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: Are copyright assignments detrimental to eCos?


Jiri Gaisler wrote:
Alex Schuilenburg wrote:

Anyway, forking is not in our interest, never mind the community's. We want the benefits that contributions to eCos bring, as does everyone else. eCosPro is not a fork, it is a superset of eCos. See http://www.ecoscentric.com/ecos/ecospro.shtml

What you seem to be suggesting is that you want everyone else *but* eCosCentric to benefit from your potential contribution.


What I am saying is that I want everyone to benefit from our contribution,
*and* from potential derivate work in form of bug fixes. Just like the
linux kernel.

In this respect it's no different from the linux kernel. Someone can take the linux kernel, make changes and bug fixes and distribute it. And by virtue of the GPL the people who get any kernel binaries can get the source code that goes with it and all is as it should be. That doesn't mean they have to be posted on the linux-kernel list, nor provided to Linus for inclusion in the source base, and indeed many are not.


What difference do you think there is?

Everyone sees the same kernel code, while applications and
drivers can be proprietary if desired.

And that's what happens with eCosPro - all the source code is supplied, and the only bits that can't be redistributed freely are some portions we have written solely ourselves (not derived from public eCos sources) as extensions and add-ons.


For example we have an entirely new MultiMedia Filesystem. That's an extension we wrote ourselves, and is no different conceptually from people writing their own userspace filesystem on Linux (such as with FUSE). Just like with a FUSE filesystem an extension should be able to be proprietary[1]. The fact that eCos, unlike Linux, links into a single kernel image without such a clear kernel boundary isn't important for the principle of thing - that's the reason for the exception clause with the GPL which we have.

It seems to me that insisting on
FSF copyright transfer blocks this in some way. We are still maintaining
our own ecos fork (superset), but I would rather see everything merged
to anoncvs. But I respect the policy of the anoncvs maintainers and
eCoscentric, so we will keep it as is for them time being.

Obviously you don't have to contribute changes either :-). But I don't think you need have the worry you seem to have. Anything contributed to eCos gets owned by the FSF, and put under the eCos GPL+exception license de facto forever[2]. No-one can change that (except the FSF, and as the creators of free software they never would). And anyone who makes fixes to those source files has to keep it with that license and distribute them under the GPL terms. Just like the Linux kernel.


Does that clear things up?

Jifl (eCosCentric hat)
[1] <http://fuse.sourceforge.net/wiki/index.php/FAQ#Under_what_conditions_may_I_distribute_a_filesystem_which_uses_libfusex3f.>
[2] Or equivalently anyway - because of single ownership in the FSF, we can change the license wording if there is a legal need. We couldn't do that with multiple owners - we'd need everyone's permission.
--
eCosCentric Limited http://www.eCosCentric.com/ The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["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


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