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

[Bart Veer <bartv@ecoscentric.com>]

>>>>> "jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:

    <snip>

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

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

Sure. I was thinking of an environment variable
ECOS_ACCEPTABLE_LICENSES which would be a list of glob expressions,
e.g. "GPL+eCos_exception BSD*", with the latter covering both vanilla
BSD and BSD+advertising. Only licenses which do not match any of the
glob expressions would be reported. If the environment variable is not
set then libcdl could default to "GPL+eCos_exception BSD". In an
automated environment you would just use "*" and all licenses would be
accepted.

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

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

I don't think I want to embed that kind of knowledge into the code, it
seems more like a documentation issue. For example it is perfectly
legal to combine GPL and BSD+advertising within an organization, as
long as you don't distribute the results. Having the tools give
warnings about this seems wrong. It should remain the users'
responsibility to figure out what to do about it, and get legal advice
if required.

Note that there are a couple of relevant books appearing in the near
future which we should be able to point people at:

    http://www.phptr.com/title/0131487876
    http://www.oreilly.com/catalog/osfreesoft/

    <snip>

    >> I think the CDL approach is preferable, but there may be an
    >> element of personal bias here.

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

Actually, I think a license property will suffice and we can eliminate
license_proc from the design. license_proc would have made more sense
in a graphical configuration tool built using Tcl/Tk, i.e. each
package would have been able to pop up its own dialog requiring that
the user accepts the license terms. I am not sure that would gain us
anything significant.

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

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

It shouldn't stop us, but we should be careful with the timing. It is
better to make several disruptive changes at the same time and only
inconvenience users once. For example, if we are going to be providing
new configuration tools maybe this would also be the right time to
implement cdl_target support.

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

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

My bad, I am mixing up two issues here on the grounds that they both
involve disruptive changes. This would not affect users. However
putting MicroWindows etc. in a separate repository might make our
lives easier handling incoming patches. For everything that goes into
the core we insist on copyright assignments and it must all be squeaky
clean. For something like MicroWindows an assignment for changes is
nice but not essential, as long as there are no licensing issues. If
the affected repository determines the procedure for handling incoming
patches that might make life our simpler. Or maybe it wouldn't. But
the idea seemed worth raising.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts