public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
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

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