Skip to content

Home

Jump to bottom Edit New page
DavidJMckenzie edited this page Feb 7, 2018 · 15 revisions

Welcome to the Free HDL License project wiki! I expect most discussion and development to take place here. Please edit and comment freely, but only if you agree to your changes and additions being governed by the project's license, currently described in the README file.

Table of Contents

Why

HDL designs are conceptually like software source code: They're a human-readable format for expressing functionality, which is mechanically converted into a format which more directly implements that function. If the design is being used with reconfigurable hardware (e.g. an FPGA), the synthesized bitfile is loaded and run much like ordinary software in a stored-program computer. While they might embody some technique protected by patent law, the designs themselves are protected by copyright.

There are enough differences, though, that I'm not sure how well the common existing free software licenses (or other software licenses) map to HDL designs. Words like "compile," "link," "library," "object code," and "header file" don't translate exactly. In general, HDL designs can be used to make either reconfigurable logic device bitfiles or permanently-fixed hardware. When the end product is an ASIC, the software thought model (and licenses) may not apply as well.

The goal of this project is to identify clarifications or improvements which would be helpful for licensing Free Software in HDL forms.

Issues

Different Uses of Code

A chunk of HDL code seems to have (at least) the following possible destinies:

  • It's compiled into a simulation model to be run on a general-purpose computer. This is clearly software, and the end user is a programmer/designer working on something which either incorporates or interacts with your design.
  • It's compiled (synthesized) into a "bit file" and run on an FPGA/CLPD device. This seems like software to me, and the end user is the person with the FPGA-based device.
  • It's used to make a physical chip. In this case, there's a series of mechanical and human transformations between the HDL code and the final "soft" specification (e.g. GDS or OASIS files), which is then used to build the chip. I don't know how far down this chain copyright law logically extends. Equally important, I don't know what rights a Free Software HDL designer would want to apply in this case. (See discussion at Stallman1994, Stallman2011, Moglen2004, and the background links below). See What Rights?

Different Processes and Terminology

The HDL and CPU programming processes are decent analogues, but it's not perfect. This may not matter if you want to treat all derivative works identically. It probably does matter, though, for LGPL-like licenses where it matters how the derived work uses your work.

  • Compile ≈ Synthesize (and place and route, ...)
  • Executable, Binary ≈ Design, Bit File, Chip
  • Library ≈ Core (?)
  • Link ≈ ?
  • Source Code ≈ HDL Design
  • Object Code ≈ net list, EDIF, ??
  • Hardware design often includes manual editing of intermediate steps between the highest-level HDL and the final product, blurring the source code / object code distinction a bit.

Use of Proprietary Components

Many (maybe most?) significant FPGA designs involve some proprietary cores from the FPGA vendor. It's not immediately clear when and to what extent such cores are appropriate for a "free" design:

  • In many cases, these cores are the vendor's intended way of interacting with specialized on-chip resources; these are logically analogous to device drivers in the software world. In general, it seems like a design using such cores should be OK: The underlying FPGA chip is intrinsically proprietary; using a proprietary HDL layer to interact with it doesn't seem to further reduce the user's freedom. Common free software licenses allow a free program to depend on a non-free OS and drivers. There are two "gotchas" here, though:
    • The proprietary licenses for those components need to be compatible with free distribution of the combined program. See e.g. Vendor core rights.
    • FPGA vendors do not necessarily license all cores alike: In particular, owning a particular FPGA chip and having a license for the minimal software necessary to generate "bitfiles" for that chip does not generally imply a having a license for all the applicable cores.
  • In other cases, proprietary cores are much more like libraries in software -- they perform some non-hardware-related processing task. This seems trickier.

License Compatibility

  • If we produce a new license, or an addendum / clarification to be used with existing licenses, how do we make it possible (and when is it appropriate) to combine code under this new license with code under existing licenses?

Different Legal Frameworks

Disclaimer! I believe the following to be correct, but it's only my lay interpretation.

Software licenses (free or otherwise) are based almost entirely on copyright law. Almost any conceivable use of an electronic file is considered copying, at least under U.S. law, meaning that a would-be user needs to (a) have a license and (b) comply with its terms in order to be legal. While this is still true for the HDL files describing a design, the acts of manufacturing a device based on the design, or using such a device, are not subject to copyright. Open hardware licenses attempt to work around this by either licensing patent rights (when they exist) or by attaching future obligations on developed hardware to the copyright license of a hardware design. I don't claim to understand the subtleties here, but the high-level point is that a copyright license may not give the licensor the same leverage as it does for software.

Helpful Background

Related

  • Julius Baxter recently announced a draft Open Hardware Description License (OHDL) in the context of the OpenRISC project!

Licenses!

Here are a couple of work-in-progress licenses:

Add a custom footer
Add a custom sidebar
Clone this wiki locally