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.
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.
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.
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. 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.
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. 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.
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.
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.
Patrick M
Timothy Miller wrote:
On 8/22/05, Martin Jeppesen <[EMAIL PROTECTED]> wrote:
Oh. Now I understand. Well, any of those choices ought to work.
Another variant is a prominent notice on the SVN server front page that
anyone who submits code there automatically grants GPL. You'll run any of
these ideas past the company lawyer anyway, of course.
Too bad I don't have a company lawyer. :)
Wouldn't Linus or Stallman be able to answer these questions?
They most have faced similar concerns when developing Linux and GNU?
Yeah. I'm not sure I want to pester them, and they'd both probably
refer me to someone with a bar license anyhow.
Linus probably wouldn't be very interested. Stallman thinks that
anything that isn't Free Software ALWAYS is evil. I'm not sure how he
think about the hardware distinction, but what I need is traditional
attorney. ESR may be able to give a more objective answer.
Stallman's cool, but I don't see eye-to-eye with him on everything,
and trying to apply his ultimate ideal to this project could destroy
it. I am doing this project so that we can apply his ultimate ideal
to SOFTWARE. Hardware is another matter.
(Actually, Stallman's ideal is the GPL. Any software (BIOS, drivers,
etc) I write will be released under BSD and MIT licenses; if others
want to convert them to GPL later, that's fine, but for the sake of
making this technology ubiquitous, I'm going to go with a more
ESR-like tack. I most definitely want BSD and Windows drivers.)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
