From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3974 invoked by alias); 25 Aug 2004 22:23:31 -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 3945 invoked from network); 25 Aug 2004 22:23:26 -0000 To: jifl@eCosCentric.com Cc: ecos-maintainers@ecos.sourceware.org In-reply-to: <412D010D.60603@eCosCentric.com> (message from Jonathan Larmour on Wed, 25 Aug 2004 22:13:49 +0100) Subject: Re: Contribution of a DHCP server =?ISO-8859-1?Q?=28=B5DHCP=29_?= =?ISO-8859-1?Q?port_to_eCOS?= From: Bart Veer References: <412D010D.60603@eCosCentric.com> Message-Id: <20040825222323.71CCBEC10C@delenn.bartv.net> Date: Wed, 25 Aug 2004 22:23:00 -0000 X-SW-Source: 2004-08/txt/msg00023.txt.bz2 Switched to ecos-maintainers only. >>>>> "jifl" == Jonathan Larmour writes: jifl> sebastien Couret wrote: >> Hello eCOS gurus, >> >> I'm pleased to contribute back to eCOS with this DHCP server port. >> The original code (v0.9.8, 31 Oct, 2002) was found on >> http://udhcp.busybox.net and is covered by GPL Licence. >> So this release will also be covered by GPL. jifl> Thanks! jifl> I'm not sure what the best thing to do with this is. We want jifl> to keep it that code which people get as part of eCos is not jifl> covered by anything more, shall we say, rigorous than the jifl> eCos license, which is GPL plus a special exception. jifl> At the same time, I don't want good stuff to go unnoticed jifl> even by those who don't mind the GPL. jifl> To other maintainers, I have a suggestion in general: to add jifl> a new and separate CVS module called ecos-gpl, which has jifl> full GPL'd (or LGPL'd) stuff in. This is not checked out by jifl> default, nor would the packages in it be part of the jifl> standard set in a full eCos release (not without explicit jifl> user effort so they can recognise the license implications). jifl> Users can use the functionality added not so long ago to jifl> specify multiple ecos repositories if needed, although I jifl> think the wxwindows config tool may still not have been jifl> updated? I believe the configtool accepts an ECOS_REPOSITORY environment variable with multiple entries, but the dialog(s) relating to this setting still assume a single entry. So it works as long as you have set your environment correctly and don't want to switch repositories mid-session. A separate repository is a sensible minimal requirement. We do not want users to accidentally include GPL'd code in their application without realizing it. However I don't think a separate repository is sufficient, we also want explicit support in the host-side tools. There is already limited support for this in ecosadmin when installing a new package, but I don't think that is good enough. I haven't thought through the issues in detail, but two possibilities spring to mind: 1) add a new CDL property license, probably only usable inside a cdl_package. This would take an arbitrary string, so e.g.: cdl_package CYGPKG_SOMETHING { license GPL ... } or cdl_package CYGPKG_OTHER { license "Proprietary, see http://www.xyzzy.com/OTHER/license.html" ... } Whenever you add a package to a configuration with a license property, ecosconfig or the configtool would display that string. Ditto whenever you load the configuration, e.g. as part of an "ecosconfig tree". That way users are told explicitly about any non-standard licenses, and they cannot claim they were unaware of what was happening. There should also be an ecosconfig command line option or a configtool dialog to show the licenses for all current packages. A variation of this is to make the license property compulsory but only display license texts other than "GPL+eCos_exception" or "BSD". That approach seems preferable but requires retrofitting a license property to all our existing packages. Not a difficult job, but tedious. The original CDL design documents mentioned a "license_proc" property, and in fact there is some support for this already in libcdl, but the current CDL implementation is too incomplete for that license_proc idea to be viable at present. A new "license" property would be rather simpler. 2) have ecosconfig and the configtool look for a file LICENSE in each package's directory and do something appropriate. You could only point users at the LICENSE file, typically it will be too large to dump to the screen. I think the CDL approach is preferable, but there may be an element of personal bias here. The libcdl and ecosconfig changes should be straightforward. Not so sure about the configtool. However if we start putting license properties into packages then people will need to install updated host-side tools, a disruptive change. Incidentally, there may also be an argument for putting some existing packages into a separate repository. Specifically packages which will not end up fully contributed to the FSF, e.g. the TCP/IP stacks, MicroWindows, and perhaps jffs2. This would be another disruptive change, but may help to avoid long-term confusion. Bart