From: Jonathan Larmour <jifl@eCosCentric.com>
To: sebastien.couret@elios-informatique.fr
Cc: ecos-maintainers@ecos.sourceware.org
Subject: Re: Contribution of a DHCP server (µDHCP) port to eCOS
Date: Wed, 25 Aug 2004 21:13:00 -0000 [thread overview]
Message-ID: <412D010D.60603@eCosCentric.com> (raw)
In-Reply-To: <MELELIOS1IM9QX2CTp2000000ea@melelios.dmz.elios-informatique.fr>
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.
Thanks!
I'm not sure what the best thing to do with this is. We want to keep it
that code which people get as part of eCos is not covered by anything more,
shall we say, rigorous than the eCos license, which is GPL plus a special
exception.
At the same time, I don't want good stuff to go unnoticed even by those who
don't mind the GPL.
To other maintainers, I have a suggestion in general: to add a new and
separate CVS module called ecos-gpl, which has full GPL'd (or LGPL'd) stuff
in. This is not checked out by default, nor would the packages in it be
part of the standard set in a full eCos release (not without explicit user
effort so they can recognise the license implications). Users can use the
functionality added not so long ago to specify multiple ecos repositories
if needed, although I think the wxwindows config tool may still not have
been updated?
So users would do something like:
export ECOS_REPOSITORY=$HOME/ecos/packages:$HOME/ecos-gpl/packages
I'm not sure how we'd deal with documentation - it would probably have to
be kept separate too.
Alternatively we can just continue putting (L)GPL stuff on the FTP site.
Hmmm... it's just occurred to me that full GPL code is incompatible with
BSD plus advertising clause code, which we have a little of in the
networking stacks (UCB doesn't count). Perhaps we should resist all GPL
code for this reason. Elios needs to be aware of this too as strictly they
can't use the FreeBSD stack with the DHCP server in that case
(<http://www.fsf.org/philosophy/bsd.html>)
garibaldi:~/ecos-clean/packages/net$ grep -r "includes software developed"
common bsd_tcpip |grep -v "University of"
common/current/doc/manpages/net/inet_net.3:.\" This product includes
software developed by the NetBSD
common/current/doc/manpages/sys/poll.2:.\" This product includes software
developed by Jason R. Thorpe.
common/current/tests/bridge.c: * This product includes software developed
by Jason L. Wright
bsd_tcpip/current/include/netinet/ip_flow.h: * This product includes
software developed by the NetBSD
bsd_tcpip/current/include/sys/endian.h: * This product includes software
developed by Niklas Hallqvist.
bsd_tcpip/current/src/sys/netinet/ip_flow.c: * This product includes
software developed by the NetBSD
bsd_tcpip/current/src/sys/netinet/ip_id.c: * This product includes
software developed by Niels Provos.
The man pages are irrelevant in relation to the GPL. A test is also a
non-issue. <sys/endian.h> appears to be different in FreeBSD and NetBSD
from what we have, so the origin is unclear. The current file in
free/netBSD has no advertising clause. That leaves ip_flow.h/ip_flow.c and
ip_id.c. The former two have been rewritten in current BSD and are
non-advertising clause. The latter remains.
So any issues could be dealt with with a stack update (or maybe just the
files with some mods?), save for ip_id.c, and I could approach Niels Provos
and ask if he would waive it for eCos.
Thoughts?
> It has been heavily modified to be integrated to eCOS and is mainly
> configurable via configtool.
It's helpful that you've done an EPK, thanks.
Would it be possible for you to do a copyright assignment for your changes?
We have a policy in general that we can include stuff from recognised
external projects, but for individual changes, we prefer the security of a
copyright assignment. In this case, because we know about the GPL, the
reason not being so much the assignment itself, as the copyright disclaimer
from your employer, so that we know that the work you have done is stuff
you are permitted by your employer (who may also be the copyright owner,
depending on your employment contract) to contribute.
> For the moment i have validate it with FreeBSD TCP/IP stack on the Linux
> Synthetic target, a Rattler board and a PQ2FADS board.
>
> I have not much time to improve things such documentation/debug and propose a
> few tests, so i post it has it.
>
> Anyway I hope it will be usefull.
> Any feedback or questions will be greetly apreciated.
>
> I'm on my way to post also a DNS server port (nsd). You will got it soon.
That looks good, and probably smaller than many. The modified BSD license
will be no problem for inclusion in the main repository, although again a
copyright assignment for your own changes would be required as per above,
again largely to verify legally that you are entitled to make the contribution.
http://ecos.sourceware.org/patches-assignment.html
> Have a nice day.
>
>
> --------------------------------
> Hum well, anytime I attach the epk file with this mail, my mail is bounced
> back and tagged as spam ... What should I do ?
I don't know - it came through here fine.
Thanks again,
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
next prev parent reply other threads:[~2004-08-25 21:13 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 [this message]
2004-08-25 22:23 ` Bart Veer
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=412D010D.60603@eCosCentric.com \
--to=jifl@ecoscentric.com \
--cc=ecos-maintainers@ecos.sourceware.org \
--cc=sebastien.couret@elios-informatique.fr \
/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).