[Fedora-electronic-lab] TAPR Open Hardware License

Chitlesh GOORAH chitlesh at fedoraproject.org
Sat Dec 12 14:18:23 UTC 2009


On Sat, Dec 12, 2009 at 7:14 AM, Shakthi Kannan < > wrote:
> I have asked Fedora Legal for feedback. In this regard, if we were to
> package VHDL and Verilog cores under an open hardware license, I would
> like to know as to how we should package them into FEL?
>
> For example, if we package opencores.org cores, do we have a naming
> convention like opencores.org-<project-name>, and put them under
> /usr/share/opencores.org/<project-name>, or just
> /usr/share/<project-name>?
>
> Or, do we need to come up packaging guidelines for hardware designs
> that people can use with FEL tools?
>
> Appreciate your inputs in this regard,

Yes indeed this deserves some thinking.

Unlike other software and even fonts, these cores have no significant
meaning to the users (from a software engineer point of view). They
will fall in the same situation as OVM packaging, that is they will be
refused during packaging reviews if they can't at least be used _out
of the box_ with software distributed by fedora.

FYI: OVM was refused because there was no opensource tool to use it.

* From a fedora software packaging point of view

We have to ensure that these cores can either be compiled with
iverilog or ghdl. A script or Makefile should be shipped with the rpm.
All proprietary scripts should be in docdir of a subpackage -extra.
The advantage of packaging these cores is that once we got one core
fully packaged, others will have the same template and it will be very
smooth.

* From an opensource hardware point of view

I agree with your proposed naming convention:opencores.org-<project-name>

I would opt of /usr/share/opencores.org/<project-name> as it pays
respect to the work opencores.org has done in creating set of
guidelines for HDL development, directory structure and community
building.

We should only compile those cores which are tagged as done/complete.
Those cores without documentation are pretty useless for the user. So
I would say we should prioritize those having documentation.

Prepare a spec file and a SRPM for one of the cores hence we can
identify the elements we should pay attention.

Last year, I tried to compile a draft template for opencores IP
distribution based on the designer's needs. But never got time to
complete it
http://chitlesh.fedorapeople.org/temp/
I should spend some time to learn how companies are selling their IPs
as a distribution point of view and improve that template.


Chitlesh




More information about the Fedora-electronic-lab-list mailing list