Re: [oc] Inquiry

[John Dalton <john.dalton@bigfoot.com>]

PART ONE

In truth, I don't think resistance to the GPL is due to its
complexity.  Rather I think resistance on the grounds
of complexity is due to unfamiliarity with it, and opposition
to the redistribution conditions.  It is a strange thing
for someone who is used to keeping secrets to be suddenly
told "I'm giving you this, and you cannot keep it secret".

Unfamiliarity often makes simple things appear
complicated.  Just think back to when you first set
eyes on a new piece of code, or get pulled onto a
new project.  At first it seems complicated, but
more often than not the ideas turn out to be really
simple and the initial appearance of complexity was
false.

The GPL is 12 clauses written in plain English.  It
comes with a summary of how to use it, which
makes it look longer than it is.  It would be ironic
if notes intended to add clarity lead to accusations
of complexity.

Along the lines of Richard's BSD summary, a summary of
the GPL might be:

"This is the core. Use it as you please, without removing the 
copyright/disclaimer header. Don't come back whining (and certainly don't sue 
me) when it's not working.  You must distribute it's source,
and any changes, when you give it so someone."

One extra sentence.

If one hasn't already done so, I suggest reading the entire
text of the GPL (http://www.gnu.org/copyleft/gpl.html).
Think of what each of the 12 clauses is saying, re-reading
as necessary.  I suspect it won't turn out to be complicated
after all. (footnote 1)

In most cases, I think saying "the GPL is complex" is a substitute
for saying "I don't feel comfortable with it's conditions".
In that case, let's get the discussion back to whether
the GPL is suited to Opencores, and not be distracted by
allegations of complexity.


My long winded exploration of the implications of the GPL
doesn't mean the *GPL* is complicated.  It means the
*application of copyright to hardware design* is complicated.
You will get similar issues no matter what your license.


PART TWO:

Here is an question that flows on from considering the application
of the GPL to hardware.  Hopefully it will make people think:

"If the GPL is not applicable to hardware designs, it must mean
copyright law is not applicable to hardware designs (the GPL is
just a simple application of copyright law).  If you don't have
patents on your hardware design, what protection do you have?"

The only other forms of "IP" (that I'm aware of) are trademarks and trade
secrets.  Trademarks don't apply to hardware designs and most of the world
doesn't recognise "trade secrets".  By process of elimination, the
answer seems to be "Without patents you have no protection".

Can someone find a hole in my logic?

Consequently, for an IP core maker to argue that the GPL does
not apply to "IP cores", they had better have patents on their
own "IP", otherwise they are also arguing that they don't have any
control over their "IP".


SUMMARY

So far, the only valid argument against the GPL seems to be "I disagree
with the licensing conditions".  In itself, the GPL does not appear
to be flawed and seems to be as valid as any other license (in that they
all rely on copyright).

Ultimately, agreement with licensing conditions is an individual decision
and choice of licensing conditions is down to each author.

Fundamentally, we are trying to help authors make a good license decision
by answering the question:

1) What license/s is/are suited to Opencores?

Given that any Opencores license will have to rely on copyright (unless
we buy patents), we first have to answer the question:

2) What are the implications of trying to apply copyright law
   to hardware design?

We have explored whether copyright law can be used to stop someone
from turning a design into a device and so far have conflicting
views.  This is a question that needs to be answered.

Once we have answered question 2), we then need to answer:
3) Can we come up with a list of license scenarios for
   authors to choose from.  For example:
     - GPL like (force all source distribution)
     - LGPL like (force source distribution for Opencore only)
     - BSD like (allow closed source)
4) Can we come up with a set of licenses that unambiguously achieve
   the above aims?  So far the leaders seem to be:
     - GPL
     _ ???
     - BSD
5) Gather information on how users want to use Opencores,
   so authors can make informed decisions on what license to use.



I'm getting heaps out of this discussion. It's really making me think
carefully about various points.  I hope everyone else is getting as much
out of it as I am.

Regards
John


Footnote 1:
Perhaps it would be interesting to do a 'user interface' test of
different licenses.  Give each license to 100 people to read and
give each person a comprehension test afterwards?


This document is licensed under the Free Documentation License.
Copyright John Dalton 2003

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml