Re: [oc] Inquiry

[Niclas Hedhman <niclas@hedhman.org>]

Although I am not a OpenCores user, just hanging around to learn new topic, I 
AM a frequent commercial user of Open-Source Software.

I would never(!) embed GPL'd code into my products, it's in sane. The legal 
aspect of it, practically I have to give my value-add to anyone interested 
(such as competitors).
However, I use a lot of Apache licensed (think BSD) code, BECAUSE they don't 
impose any unreasonable restrictions;
1. Not allowed to use their name to promote the product.
2. Not allowed to remove the copyright statement in source files.

My "improvements" are typically in form of finding bugs, which I typically 
provide back, since I want the community to maintain a common codebase, so I 
can easily upgrade.
Most usage is either in form of
a. utilizing a service provided, for instance creation of SVG files.
b. a plug-in to add additional services to a framework.
Both would be impossible with the GPL, without exposing my trade secrets.

Bottom line; Most corporations of any size today, have already been through 
the legal hoo-haa of GPL and made a policy surrounding it, and probably other 
OSS licenses as well. My dozen or so contacts mostly have the following 
policy in place;
1. For using a GPL/BSD licensed product in operations = OK.
2. For using GPL in product devlopment = NO.
3. For using BSD in product development = OK.



On Tuesday 06 May 2003 06:23 pm, John Dalton wrote:
> 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

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