Re: [oc] Legal projects that can be worked on.

["Damjan Lampret" <lampret@opencores.org>]

Hi !

I agree that we should devote more attention to legal issues. However I'm
not expert on this subject so I can't say much - maybe there is an IP lawyer
on this list that could give some hints?

My two cents:
- I think any IP core that is not a clone and it doesn't implement a patent
is _probably_ safe
- even though PCI spec document itself is heavily protected, if you
implement PCI core I think it is ok (do you first need to buy PCI spec?)

I know that USB spec is freely available (usb forum) and implementation of
USB is not problematic. Maybe we should focus on implementations of freealy
available specs?

regards,
Damjan

----- Original Message -----
From: "Sam Gladstone" <samg@t-and-t.com>
To: <cores@opencores.org>
Sent: Saturday, December 22, 2001 8:28 PM
Subject: [oc] Legal projects that can be worked on.


> I thought it interesting that the PCI spec was so heavily protected by
> lawyers from PCI-SIG.
> Is there anything that is not so heavily protected and
> might be of interest for the Opencores group?
>
> I am just looking for a "fair game" list of things that could be looked
into
> that
> won't land me in jail because of the DCMA or some other ridiculous
corporate
> protectionist
> based law here in the U.S.
>
> If we know what areas are legally OK to implement then it could be put
into
> spec.
> Because working on something just to spite lawyers and then have it taken
> off the
> Opencores website is not going to get us anywhere.
>
> Here is what I have seen
> DSP and mixed signal circuits seem pretty safe.
>
> Just about any recent IBM-PC interface seems to be guarded with lawyers.
> (PCI, USB and so on.)
>
> What about specs in the IEEE? How safe are they? Or does inclusion
> into IEEE numbering system make them the property of the IEEE and
> its band of lawyers?
>
> I think this stuff needs to be roughly documented and placed as a FAQ on
> the site. Sure would save a lot of grief for people new to the Opencores
and
> keep Opencores in a little more safe position.
>
> Regards,
>  Sam Gladstone
>
>
>
> --
> 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