Hrm. After reading my post, I realized that either I or the spell
checker did something that I think will be unfortunately quite common
with the company name. Transversal instead of Traversal. Ooops, my
apologies.
Patrick M
Patrick McNamara 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.
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)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
