From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25538 invoked by alias); 26 Aug 2004 13:47:04 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 25500 invoked from network); 26 Aug 2004 13:46:58 -0000 To: jifl@eCosCentric.com Cc: ecos-maintainers@ecos.sourceware.org In-reply-to: <412D2CE0.2090003@eCosCentric.com> (message from Jonathan Larmour on Thu, 26 Aug 2004 01:20:48 +0100) Subject: Re: Contribution of a DHCP server =?ISO-8859-1?Q?=28=B5DHCP=29_?= =?ISO-8859-1?Q?port_to_eCOS?= From: Bart Veer References: <412D010D.60603@eCosCentric.com> <20040825222323.71CCBEC10C@delenn.bartv.net> <412D2CE0.2090003@eCosCentric.com> Message-Id: <20040826134653.81CAEEC10C@delenn.bartv.net> Date: Thu, 26 Aug 2004 13:47:00 -0000 X-SW-Source: 2004-08/txt/msg00025.txt.bz2 >>>>> "jifl" == Jonathan Larmour writes: >> 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/ >> 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