From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21135 invoked by alias); 5 Apr 2008 00:14:12 -0000 Received: (qmail 21127 invoked by uid 22791); 5 Apr 2008 00:14:11 -0000 X-Spam-Check-By: sourceware.org Received: from snape.ecoscentric.com (HELO snape.ecoscentric.com) (212.13.207.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 05 Apr 2008 00:13:42 +0000 Received: from localhost (snape.ecoscentric.com [127.0.0.1]) by snape.ecoscentric.com (Postfix) with ESMTP id AE3A8C540F6; Sat, 5 Apr 2008 01:13:39 +0100 (BST) Received: from snape.ecoscentric.com ([127.0.0.1]) by localhost (snape.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNKjdZkzBTmn; Sat, 5 Apr 2008 01:11:53 +0100 (BST) Received: from [127.0.0.1] (unknown [212.13.207.199]) by snape.ecoscentric.com (Postfix) with ESMTP id 231E2C540F5; Sat, 5 Apr 2008 01:11:53 +0100 (BST) Message-ID: <47F6C3C7.5000301@eCosCentric.com> Date: Sat, 05 Apr 2008 00:44:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc3.4.legacy (X11/20060515) MIME-Version: 1.0 To: Jiri Gaisler CC: ecos-discuss@ecos.sourceware.org References: <20080403112347.68e481c9@kingfisher.sec.intern.logix-tt.com> <200804030937.m339bj00013603@mail168c2.megamailservers.com> <200804032050.20913.neundorf@kde.org> <200804032228.m33MSkCg027848@mail168c2.megamailservers.com> <20080404104457.35553e0a@kingfisher.sec.intern.logix-tt.com> <200804040912.m349CrYq028389@mail176c2.megamailservers.com> <20080404114231.7efcf59a@kingfisher.sec.intern.logix-tt.com> <47F5FC4A.2080401@gaisler.com> <20080404145330.GM7929@lunn.ch> <200804041510.m34FAdfE025938@mail175c2.megamailservers.com> <47F64F89.9080809@ecoscentric.com> <200804041650.m34Goakc019397@mail175c2.megamailservers.com> In-Reply-To: <200804041650.m34Goakc019397@mail175c2.megamailservers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Are copyright assignments detrimental to eCos? X-SW-Source: 2008-04/txt/msg00097.txt.bz2 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] [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