Re: Contribution of a DHCP server (µDHCP) port to eCOS

[Bart Veer <bartv at ecoscentric dot com>]

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