What license would you want to see?

That is a valid question, and I believe your answers

and comments are on the right lines too.

The goal in simplest terms, given the fact that Niagara

is a breakthrough technology, is to offer it to everyone

(as it is a compelling invitation for people to adopt)

so that it becomes the industry standard for 64-bit CMT.

New designs/chips/SOCs for new uses that can be

brought quicker to market by leveraging something

that works.

This in turn will create the pull from different angles.

IP vendors will offer IP blocks. Foundries will want the

designs ported and ramped on their wafer capacity.

EDA vendors will show off their tools. Academia will

get a head start to innovate into highly parallel approaches etc.

Other OSs will be ported to bring the

benefit of the technology to more applications and uses.

One could argue that open source that is OSI blessed is

perhaps more critical than the specific license model.

But I suppose, different users will care about the

license model specially as it pertains to how it affects

them (due to copyleft provisions etc.)

Perhaps, to have the license discussion, we first need

to understand what the bounds and implications of

these license models are as it pertains to hardware.

For example, what does "source" mean in a hardware

context. Clearly RTL is source. Then what is a binary

or executable? Is it finished/packaged silicon, or is it

the PG tape, or something else? What about the

intermediate forms of the design - say the synthesized

gate level netlist, or the transistor netlist? Are these

sources or executables?

I am sure people have discussed/debated these topics

before, but a refresher will help so we can then talk

about the license models.

coolthreads at 2007-7-6 13:34:23 >

> Given the number of things Sun is planning to provide --

> architecture, RTL view of the T1 microarchitecture, tool

> chain, simulator, etc -- I firmly believe that the GPL

> is the most appropriate license.

If we talk about GPL, we need to specify which version.

Clearly, version 2 has significant issues which inhibit

the kind of corporate investment OpenSPARC desires.

But version 3 seems to have some corrections which

make it more palatable (and more like CDDL). Alas,

GPLv3 will not likely be ready soon, so there may need

to be an interim license prior to dual licensing, just to

get to market.

> Sun is literally open sourcing the entire foundation to an

> innovative product line. This provides the community with

> a state-of-the-art design to tinker with and allows other

> vendors to adopt the design in their work. However, it also

> makes it extremely easy to build competing products that

> are just as innovative as the T1.

How is this a bad thing, in principle? Sun was founded

on the model of assembling COTS components into

solutions, and though it periodically seems to forget its

roots, it can still follow that model well. When further

innovation is required, it will step up to the task, hence

the UltraSPARC T1.

From a practical perspective, there are markets which

Sun does not have a large share, but which could see

advantages of this openness. So it is a good opportunity

for someone to take this starting point and extend into

new markets with Sun's encouragement. OTOH, going

directly after Sun's market will be more difficult and

even though you have RTL, you have a significant

effort to get to manufacturing a working system. It is

possible, but it isn't the fertile ground. Personally, I'd

like to encourage people to take these designs in new

directions, but don't really expect a direct competitor

to existing or planned Sun systems. Even if there were

such a competitor, and they were successful, I would

expect Sun to pick the product up, after a brief battle.

There is considerable historical precedence for this:

HyperSPARC and Fujitsu, most notably.

Directly back to the target, I don't believe any of the

existing FOSS licenses apply well to hardware. In

many ways, the software->hardware transition is a

one way path. While the hardware gets reused for

its lifetime, it is not clear that the originating software

has value over the lifetime. Being overly protective

of the software (RTL) won't be useful for successive

generations. I'm leaning towards something a bit

more liberal than the current proposals because we

tend to get much less reuse of it anyway. Am I all

wet?

-- richard

relling1 at 2007-7-6 13:34:23 >

> I think BSDL BSD License is a good option.....

> "Compatibility with proprietary software licenses"

BSD style licenses are too permissive, especially given the amount of

investment Sun has put into this project. Instead of BSD, the better

choice would be Sun's CDDL license:

http://www.opensolaris.org/os/about/faq/licensing_faq/

Like BSD, this license allows one to combine CDDL code with entirely

proprietary code, and distribute the executable under any

license. Thus, CDDL code can be used in fully closed source commercial

distributions. Unlike the BSD license, however, the CDDL protects the

original work. The basic gist is that all modifications to code

released under the CDDL must be made public, but all other code in the

combined project remains under the original licensing terms.

Of course, in my post above I discussed why I felt the CDDL was

inappropriate for OpenSPARC and why I felt GPLv2 was the best

choice. In theory, a GPLv2 release of OpenSPARC can still be very

useful in commercial products, since most of the added value different

companies will make won't be related directly to the RTL code. All in

all, several companies sharing code publicly and working towards a

very strong brand based upon OpenSPARC will probably do better in the

end than a few companies working towards different proprietary

versions. In other words, the goal should be to work towards a

thriving community of companies rather than individual corporate

bottom-lines.

Nonetheless, I now disagree that a pure GPLv2 license is the best

choice. In particular, I would love to see OpenSPARC dual-licensed

under both GPLv2 and the CDDL.

--Why CDDL?--

1. Most of the corporate world still has worries about the GPLv2.

2. Many companies, even if they wanted to GPL their product, include

proprietary code in their work that is licensed from other vendors.

As far as my initial worries discussed in the above post, I don't

think they will work out in practice. Companies will benefit more by

working towards a thriving community based on a standard notion of

OpenSPARC than from forking their own versions. I doubt the future

will see several incompatible OpenSPARC derived projects competing

against each other.

In general, the CDDL provides copyleft protection on the released code

that Sun has invested in, allows others to include the work without

worrying about other licensing issues, and will still encourage an

open-source community based around OpenSPARC.

--Why GPL?--

CDDL isn't compatible with the GPL. While the CDDL allows covered code

to be combined with code under other licenses (including the GPL), the

GPL itself forbids the combination of GPL code with CDDL code due to

certain terms that the CDDL license requires. Providing OpenSPARC

under a GPL dual-license will allow interested individuals working on

GPL projects to include OpenSPARC code without licensing worries, just

like the CDDL provides people using non-GPL licenses.

As someone involved in a few GPL hardware projects, and on the mailing

lists of several other GPL hardware projects, I can state that this is

a real concern. The Open Graphics Project, for example, is worried

that future developers who join that project might have seen OpenSPARC

code after it is released. AS such, the project maintainers are trying

to develop some means to make sure that code contributed to that

project didn't come from a GPL-incompatible source.

Dual-license and let the user of the code choose which license makes

better sense in their derived work. It gives you the best of both

worlds.

jblomstedt at 2007-7-6 13:34:23 >

I have read the above blog reference and certainly agree that hardware is considerably different from software to make any current software license apply directly -- nevertheless, using an existing accepted license is certainly for the better and there are already hardware projects based on BSD, GPL, and LGPL anyway. So, the blog's idea that a GNU Hardware license would be preferred, but LGPL should be used in the meantime is a reasonable conclusion.

However, I believe the LGPL isn't the best choice. It's not quite the same as the CDDL/GPL dual license I suggested above.

Consider section 6 of the LGPL. That's the section which discusses combined executable works that include LGPL code. Section 6 requires that any combined executable work can be adapted by the end-user to use a new or different version of the LGPL portion of the combined work. In software, this means that the executable must either use shared libraries (thus an end-user can install a new shared library and have the executable use it automatically) or be distributed in source-core or object-code form so that an end-user can recompile the non-LGPL portion of the work with a different version of the LGPL portion.

Hardware is certainly different from software, but given the spirit of section 6 -- a user should have the ability to replace any portion of the project that is based on the LGPL code -- I think the FSF folks could (and would) argue that an end-user who purchases a chip based on LGPL technology should have access to some sort of RTL model of the product to which they could modify any LGPL section. While outright modification and production of hardware is beyond average users, it isn't beyond larger companies. An embedded systems distributor or large OEM may very well demand access to RTL or other portions of a product's design in order to design and produce a new chip that has certain elements of the OpenSPARC section changed (say 8 threads per core instead of 4, or two-way issue).

The CDDL places no requirements on combined works. Including CDDL code in a project doesn't grant the end-user of the product any rights except to the original CDDL code itself and any modifications to such code to make it work in the combined product. There is no ambiguity or implied rights in this case as there is with the LGPL.

A dual-license still seems to provide the best solution to both the commercial and open-source crowds, in my opinion.

jblomstedt at 2007-7-6 13:34:23 >