On 8/22/05, Patrick McNamara <[EMAIL PROTECTED]> wrote: > I've been reading through everyones comments and have found them very > interesting. I figured I would chime in with my thoughts. > > Firstly, we want to do as little as possible to discourage contributions > from coming back to the repository. With a minor patch here or there it > is not a big deal, just a little bit of duplicated effort. However for > major contributions you run into forks that will muddy the water and > generally dilute the talent pool. > > As I see it, we have the following pieces of this effort: > > Documentation and specifications. > PCI Interface > VGA Interface > Misc Interface and Glue logic (i.e. the flash/eprom programming logic) > 3D software model > 3D RTL core > BIOS > Drivers > Software test harnesses.
There are a few other things that I think of as blocks in their own right (video, memory controller, etc.), but you've got the basic idea. > > What follows is based on what I remember of the list discussions, along > with my own thoughts. > > Docs and Specs: > > These are being release under the GPL (actually probably should be the > GPL documentation license) , free and clear. In reality, the I don't > know that the GPL adds a whole lot here. The big thing is that they are > open and available to everyone. I don't know if I ever bothered to put a license on them. I may have put on a copyright notice, though. It doesn't matter, though. They're publically available, and being defined as specifications, implementations of those specs should not be considered derivative works. It's all cool there. > PCI Interface: Timothy has stated that this will be GPL from the > beginning as well. > > VGA Interface: Also currently to be GPL. > > Misc Interface and Glue: I expect this will be GPL'd as there are no > real useful (from a business point) secrets here. Not GPL. These three things are under LGPL. This way, nothing else is infected by the GPL. Things that I or anyone else want to link to them are not required to be released. > At this point, I should point out some things. Under my interpretation, > the combination of the PCI, VGA, Glue, and 3d core into a single bit > image or ASIC may create a derivative work from the point of the GPL and > LGPL. This is one reason I chose the LGPL. This way, we can put these things together with some GPL code and not have them affect each other. > In order to avoid this, we will need to ensure that we can at any > time take the 3d core out of the design and have the rest continue to > work without modification, or ensure that we dual license properly or > avoid the GPL license. > > It is my belief that we should dual license everything that goes into > the FPGA bit file and/or ASIC masks. My reasoning is this. For this > project to be commercially viable (ie we get to make a second chip) we > have to get corporations to buy this design. We want to make it as easy > as possible for the corporate lawyers to ok that purchase without > screwing over the OGP team (both Transversal and the larger open source > group). Consider this scenario. A company decides to make a System On > a Chip. That SOC maker takes an ARM (or PPC) core and adds a network > core and a USB core and the Clarity core and makes a useful SOC. Now > suppose that that SOC is used in the next latest greatest cell phone. > If we don't appropriately license the items in the Clarity core, the > cell phone manufacturer would be legally required to provide the source > for the various parts of the core under the GPL. While this is not a > bad thing from the GPL point of view, from a business point of view it > is liable to be a deal breaker. For that matter, anyone shipping a > product containing the ASIC could be considered to be distributing a > binary representation of the GPLed items. Not only does this include > the core design, it also includes any BIOS on the board and the > drivers. Any changes made in the commercial channel would need to be > reflected in the BIOS and drivers for that commercial release. This is precisely what needs to happen for this to be a viable commercial product. Traversal needs the right to sell under a license other than the GPL. Since no one else has checked anything into SVN for the PCI core, it's not too late for me to dual-license that. I'll dual-license LGPL and Traversal. The PCI core, at least, should be under LGPL, just because I think it's so useful for everyone else, and because I would like people to use it with Unity without them having to release the rest of their design. BTW, I had intended that drivers, BIOS, etc. all be under MIT and BSD licenses. > I personally think that the 3d software model is quite separate from the > ASIC or FPGA bit file. It is a separate implementation of the design > documents. Think of it this way. I do. I just don't want to take any legal risks. > If I design an application and write > a complete set of design documents and then chose to implement that > design in C and separately in Perl, those two implementations are > covered by separate copyrights and separate licenses even though they > are based on the same design documents and may behave identically. You > could technically do it with two C implementations however it would be > much harder to prove there was not "cross pollination" between the two > implementations. While C and Perl can be written to look similar, and > in fact Perl can be automatically converted to C, the conversion > generates something that looks nothing like the original C > implementation, though it may work the same. The same applies for > Verilog/VHDL and C/C++. If the software model is going to be included > with the commercially licenses core, then it should probably also be > dual licensed. If not, I think it could be GPL'd without issue. If it > is dual license, the I don't believe you could use the GPL as the open > source license as you cannot further restrict how people license changes > to it. This means that you cannot require any changes have copyright > transfered to Transversal or otherwise specifically licensed. Yes, you > could require a separate license agreement for access to the SVN > repository, but one I have access to the source I am free to set up my > own complete repository and effectively fork the code. > > Having spent a fair portion of this evening reading the texts of various > open source licenses (both GPL compatible and not) I am yet to find one > that appropriately covers the distribution requirements of a hardware > design. The closest I have found is the modified BSD license, which is > a bit too free and unrestricted in this case, at least for my tastes. Me too, and also for any of my potential customers. Most embedded customers aren't going to care about open source. > I think we need an Open Source Hardware license that states the following: > > 1. All design documents and specifications must be released under the > GNU Free Documentation License. > 2. All Hardware Description Language code shall have a delayed GPL > license. This means that the code will be released under the GPL when > certain conditions are met (as described in my email on 5/13/2005 > discussing how to GPL the RTL code). Until that point, the HDL code > will remain under a restricted license allowing for commercial > distribution. When conditions are met, the license will be converted to > the GPL. This license change will not be retroactive to existing > distributions. > 3. All supporting software (ie drivers, BIOS, etc) must be released > under a license allowing for unrestricted binary distribution. This is cool. We can flesh this out, and apply it to the Verilog code later. > I think there is more, but real life calls at the moment. I'm not a fan > of a new license, but hardware is different from software and has > different requirements. I don't think trying to shoehorn a hardware > project into a software license is a good idea. Yes, it really is quite a different animal. Even stuff for an FPGA requires that you have your own FPGA, which is a significant expense. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
