From: Bart Veer <bartv@ecoscentric.com>
To: jifl@eCosCentric.com
Cc: ecos-maintainers@ecos.sourceware.org
Subject: Re: Contribution of a DHCP server (µDHCP) port to eCOS
Date: Wed, 25 Aug 2004 22:23:00 -0000 [thread overview]
Message-ID: <20040825222323.71CCBEC10C@delenn.bartv.net> (raw)
In-Reply-To: <412D010D.60603@eCosCentric.com> (message from Jonathan Larmour on Wed, 25 Aug 2004 22:13:49 +0100)
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
next prev parent reply other threads:[~2004-08-25 22:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-25 13:20 sebastien Couret
2004-08-25 21:13 ` Jonathan Larmour
2004-08-25 22:23 ` Bart Veer [this message]
2004-08-26 0:20 ` Jonathan Larmour
2004-08-26 13:47 ` Bart Veer
2004-08-30 7:58 ` Andrew Lunn
2004-08-31 15:38 ` John Dallaway
2004-08-26 14:40 ` Contribution of a DHCP server (µDHCP)port " sebastien Couret
2004-08-26 18:52 ` Jonathan Larmour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040825222323.71CCBEC10C@delenn.bartv.net \
--to=bartv@ecoscentric.com \
--cc=ecos-maintainers@ecos.sourceware.org \
--cc=jifl@eCosCentric.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).