This is the mail archive of the
ecos-maintainers@sources.redhat.com
mailing list for the eCos project.
Re: Contribution of a DHCP server (µDHCP) port to eCOS
Switched to ecos-maintainers only.
>>>>> "jifl" == Jonathan Larmour <jifl@eCosCentric.com> 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