From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3447 invoked by alias); 26 Feb 2003 16:11:55 -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 3440 invoked from network); 26 Feb 2003 16:11:54 -0000 Subject: Re: Another copyright issue From: Gary Thomas To: Bart Veer Cc: eCos Maintainers In-Reply-To: <20030226160243.95BD4EC6F1@delenn.bartv.net> References: <1046272511.31018.6102.camel@hermes.chez-thomas.org> <20030226160243.95BD4EC6F1@delenn.bartv.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: Wed, 26 Feb 2003 16:11:00 -0000 Message-Id: <1046275913.31018.6295.camel@hermes.chez-thomas.org> Mime-Version: 1.0 X-SW-Source: 2003-02/txt/msg00061.txt.bz2 On Wed, 2003-02-26 at 09:02, Bart Veer wrote: > >>>>> "Gary" == Gary Thomas writes: > > Gary> As part of one of the ports I've recently done, I had to > Gary> add a couple of files which require special consideration. > Gary> They are binary data, and only applicable to a particular > Gary> device (nonetheless required to build RedBoot on the device > Gary> since it needs them to initialize the hardware). > > Gary> The producer of the files (the hardware manufacturer) has > Gary> allowed their use, but they want their copyright on them. > Gary> I have amended this to look like this: > > Gary> // > Gary> // Copyright (c) 2003 Intrinsyc Europe Ltd. All rights reserved. > Gary> // > Gary> // Redistribution and use in source or binary format is allowed > Gary> // provided: > Gary> // * This notice must be preserved > Gary> // * The binary data which this file represents may only be > Gary> // used on a NMI uPCI + uE250 based hardware platform. > Gary> // > > Gary> which I believe preserves their use in the spirit of open source. > > Gary> Does anyone have a problem with this? > > I think we do have to be careful about this sort of thing. We don't > want to get into a situation where people contribute HAL packages > which are just prebuilt binaries, encoded in a big C array or > similar. That sort of thing makes it impossible to customize the HAL > for specific application requirements. The GPL uses the phrase > "the preferred form of the work for making modifications to it", and I > think that is a good standard to work to. > > Now, there are certainly cases where you need to feed magic numbers to > hardware or it won't work. I don't have a problem with that, within > reason. In this case uE250_pci_bitstream.h is 389K and > uE250_plx_bitstream.h is 130K. That seems like an awful lot of magic, > more than the rest of the platform HAL. I would certainly like to > understand why the platform needs such a large amount of magic. > This system uses FPGA devices for a number of peripherals (the PCI bus in particular). The only way to use those devices is to program them - at boot time - with this data. The only place to hold this data on the platform is in the FLASH. So, the choice would be to have some very-hard-to-initialize-and-maintain way to get it into part of the FLASH, or make it be part of RedBoot, which is what I chose. n.b. this sort of thing will become more and more popular in the future. FPGA and soft-core systems are beginning to be very common. -- ------------------------------------------------------------ Gary Thomas | MLB Associates | Consulting for the +1 (970) 229-1963 | Embedded world http://www.mlbassoc.com/ | email: | gpg: http://www.chez-thomas.org/gary/gpg_key.asc ------------------------------------------------------------