From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30151 invoked by alias); 21 Mar 2003 22:28:55 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 30143 invoked from network); 21 Mar 2003 22:28:53 -0000 To: jifl@eCosCentric.com Cc: ecos-maintainers@sources.redhat.com In-reply-to: <3E7A9442.8000607@eCosCentric.com> (message from Jonathan Larmour on Fri, 21 Mar 2003 04:25:38 +0000) Subject: Re: Copyright resolution From: Bart Veer References: <3E7A9442.8000607@eCosCentric.com> Message-Id: <20030321222850.E6CC5EC6F1@delenn.bartv.net> Date: Fri, 21 Mar 2003 22:28:00 -0000 X-SW-Source: 2003-03/txt/msg00052.txt.bz2 >>>>> "Jifl" == Jonathan Larmour writes: Jifl> The time has come to bring this to a conclusion. The beta is Jifl> now out, and we want this to be resolved for 2.0 final. My preference is for option (b), dropping copyright assignments completely. I am neutral on the need for some sort of disclaimer form. A couple of points: 1) re. legal flaws in the license, we have a certain amount of protection via "(at your option) any later version." Any problem with the license text is likely to be with the GPL as a whole rather than with the exception, so would be a resolved by a GPL V3. This is not a panacea, it does not handle the case where the current license proves to be less restrictive than what we actually want. We may also have the possibility of adding new files to the system with a better license and adjust the rest of the system such that those new files become critical to eCos generally - e.g. a new HAL macro of some sort. 2) software patents are a high risk irrespective of whether or not we do assignments. We may be infringing any number of existing software patents already, patents developed independently of eCos, and that may well be a larger risk than anything IP related. The problem with setting up an eCos foundation is the effort involved, both initially and long term. I believe that the time would be better spent hacking code. We would also need to worry about the running costs - without licenses there is no obvious revenue source other than corporate sponsorship. I don't object strongly to setting up such a foundation, but I don't think the gains are worth the effort involved. The FSF route is worth exploring further, they already have all the bureaucracy in place. I like the idea of eCos becoming the GNU embedded OS. One possible stumbling block is the exception to the GPL, we would have to make sure that the FSF is happy to preserve this exception on code it would own. Another possible problem is policy decisions, for example the recent discussion about whether vhdl output files should be treated as data or as object files. Such issues would have to be passed up the hierarchy and we might not like the results. Bart