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

[Jonathan Larmour <jifl@eCosCentric.com>]

Bart Veer wrote:
> 
> 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.

Although you also don't want people (and automated scripts) to get pestered 
about licenses unnecessarily so some override for developers 
(--accept-all-licenses, ECOS_ACCEPT_ALL_LICENSES=1, etc.) may be wise.

>      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.

Be warned there are the two BSD licenses.... one GPL friendly the other 
not. It would be good for the tools to automatically flag up licenses that 
we know are incompatible. I don't think it's bad to build in a few of the 
well-known licenses we're likely to come across.

>    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.

I think if 2 was adopted, it would only be a stopgap. 1 is definitely 
better, although I hope it wouldn't break things with license_proc later.

> 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.

For CVS, I don't think we should stop doing good new things just because of 
that.

> 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.

With sufficient license verification from the tools, if anything, I'd have 
thought it would be easier to keep them in the same repository then.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine