OPENCORES.ORG

it was a bit frustrating, because all these software guys only thing

This discussion keeps popping up.
So far the only clean (as in non-controversial) license for hardware is a
BSD style license.
Why does everybody try to enforce (L)GPL style licenses on people?
We are not developing software, we are developing hardware here.
People should understand that hardware is more costly than software (in
development, testing and production), therefore it should be fine for
companies to use the code provided as they feel fit.
Any license that is somewhat vague limits the usability of a core.

Personally I don't mind what a user does with my cores. They can use them as
they feel fit. And many of my cores have been implemented in ASICs, I know
for sure as I receive testimonies of companies successfully using them.
I also know for sure that part of the success is due to the simple and
straightforward licensing scheme;
-the core is provided as is
-use at your own risk; do not sue me if it doesn't work
-do not remove the disclaimer
-do not remove the copyright
No restrictions on reproduction, usability, or modifications.

Richard

-----Original Message-----
From: cores-bounces@o... [mailto:cores-bounces@o...] On
Behalf Of Attila Kinali
Sent: Wednesday, August 01, 2007 10:30 AM
To: Discussion list about free open source IP cores
Subject: Re: [oc] GPLv3 usable for open HW

Hoi Christoph,

On Tue, 31 Jul 2007 10:56:54 +0200 (CEST)
nussgipfel@b... wrote:

> it was a bit frustrating, because all these software guys only thing
> about software and none of  theme thinks beyond one's own nose :-)

Well, yes. But i can tell you that defining a license that works
equally well for hardware as GPL does for software is quite hard.
OHF is now struggling quite some time to come up with something
usable.

> have i understood the new GPLv3 right? is it realy so general applicable
> as i think?

If you think you've understood GPLv3, read again ;-)

I've read the GPLv3 three times already, but i still have
the impression that i miss something important. The language
is for me as a non-native quite difficult to understand by itself.
On top of that come the legal issues and relations to other licenses.

My biggest concernes so far are that GPLv3 might not be GPLv2 compatible.
I cannot pinpoint why, but the whole text leaves that feeling.
I also have some doubts whether section 6 (non-Tivioization clause)
and section 11 (patents) solve more problems than they create.
I have the impression, that the FSF tries more to force their
religion onto other people than creating a clear, comprehensible
and generally working license that people just can use without
needing to put a lot of thought into it whether they might saw
off the branch they are sitting on.

IMHO i wouldn't use GPLv3 for now. Not until some time
has passed and there has been some explanation on how
this overly unintelligable license is to be interpreted.

Beside, the GPLv3 has still the same problems for hardware
as GPLv2 has. It still talks about linking programs and
combining work. They define some core system as license
boundary to be able to combine GPL system core with non-gpl
software and vice versa. Although that might also work for
hardware, there are many more levels involved. Ie, if you
do a GPL HDL design, is producing an ASIC using it a "linking"
operation in the software sense? Probably. But consider the
case where you have two ASICs on a board that are wired together,
one GPL the other not. Are they "linked" together? Probably not.
Now we put both ASICs into a multi chip package. Or we even
combine them on the same die. Is now the GPL violated? And
where is the limit when integration becomes "linking"?

And this problem repeats itself across the several layers
of electronics design (IP cores, die, package, board, system).

Gruess

			Attila Kinali

-- 
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
                         -- Deed of Morred
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores