[ohf-licenses] Open Hardware Public License, First Draft

[Terry Hancock]

Hi all,

These are my own comments on what I've written, intended to raise some
issues for discussion and/or give my rationale for what I did.

Terry Hancock wrote:
> This is a free, open-source, hard-copyleft license for Designs for
> material Products. While material Products

"Hard copyleft" is a term I made up. It's described a little further
along. I'm not *sure* it adds anything to the license. But it describes
the difference in intent between this kind of license and the GPL (which
is subtle enough that it took me a long time to get my head around it,
so I'm guessing others will find it challenging too). First thing you do
for something new and confusing: give it a name.

I decided to skip the sort of "high-horse" talk that the GPL starts
with. I made a couple of attempts with it, but it just sounded corny. I
decided to stick to practical matters.

> This license is designed with functional Products in mind which are
> valued primarily in utilitarian terms, and so is probably not
> appropriate for items of principally aesthetic value, even when a
> physical manifestation exists, such as with sculpture.

Actually I don't know any specific reasons you couldn't use it for
sculpture, but I wasn't thinking of aesthetic considerations when I
wrote this.

> 1.3 Authority of this License
> 
> You are not required to accept this License in order to receive or
> use an unmodified copy of the Design (including manufacturing
> products from it). However, nothing other than this License grants
> you permission to propagate or modify any covered work. These actions
>  infringe copyright if you do not accept this License (except for
> cases of "fair use" or "fair dealing" as defined by statute).
> Therefore, by modifying a covered work, regardless of whether you
> propagate or convey the resulting work, you indicate your acceptance
> of this License to do so.

Pretty much a straight rip from GPL v3, with terms modified for
consistency. Also, I've emphasized the *modification* rather than
*propagation* step as the thing that triggers this license (technically
this is true for GPL 3 as well, but I wanted to make it more clear here,
as it matters more to us).

> 1.4 Duration of this License 

> 1.5 Compliance Conflicts

These sections are also straight from GPL 3.

> 2 Definition of Terms

Now it gets interesting...

> 2.1 Copyright Terminology

I decided, after much pondering, to go ahead and adopt the language
of the GPL 3, as weird as it is. It's very particular about ideas we
need to be particular about, and it tries to avoid the use of
pre-existing "terms of art" that may not be interpreted the way we want
them to be.

> 2.2 Hierarchical Design Model Terms
> 
> This license models the design process as a series of 
> hierarchically-associated Design Domains. Within each Domain, there
> are design Atoms which are combined in some creative way to meet
> design Specifications intended to satisfy design Requirements. From
> the perspective of an engineer working in a given design Domain, the
> Atoms are indeed "atomic" and are not considered as designed objects,
> but as raw materials, with a given specification of interfaces.

"Component" has been suggested as an alternative to "Atom".

Actually my use of the word "atom" is a bit esoteric here. It literally
means, "something which is or is treated as being indivisible" from the
greek a=NOT + tom=CUT. It's used this way in linguistics and sometimes
computer science. It has little to do with the physics meaning.

My objection to "component" is mainly that it has another, more specific
meaning in electronics. I could've said "Part", but that's awfully generic.

So, I've stuck with "Atom".

> Works which are referenced solely as Atoms in the present Design are
> said to be Atomic Designs, and therefore outside of its scope. Works
> which employ the present Design as an Atom are said to be External 
> Designs and are also outside of its scope. Finally, other works
> within the same Design Domain, but whose only relationship to the
> Design are through its specified interface in an External Design are
> described as Sibling Designs and are also outside of the scope of 
> this license.

"Atomic Design 1 + Atomic Design 2" =is-a=> Design

"(Design as Atom) + (Another Design as Atom)" =is-a=> External Design
      ^------ Sibling Designs ---^

Examples:

Two different PC expansion cards in the same PC. The Design is for one
of the cards. Planning to install the Product from the Design into the
PC does not require the PC to be OHPL (External Design). Nor does it
require other cards in the PC to be OHPL (Sibling Designs). Nor must all
of the components specififed to make the Product card be OHPL (Atomic
Designs). However, any evolution or improvement of the Product's Design
must include an OHPL-licensed Design.

An OHPL-licensed car may specify a non-OHPL engine (Atomic Design). It
may be part of an non-OHPL car communications network (External Design).
It has no bearing on the license of other cars on that network (Sibling
Designs).

Note that because of the "broader but not narrower" rule, a downstream
design *may* insist on an OHPL engine in cars based on it.

"Sibling Design" is roughly equivalent to "mere aggregation" terms in
the GPL which prevent the copyleft from being invoked by merely putting
two programs on the same disk.

"Atomic Design" is not often considered in software licenses, but may,
for example include the vocabulary and grammar of the programming
language in which a program is written (a GPL program *can* be written
in a proprietary language, like IDL, for example). At an even more
fundamental level, *characters* may be considered the atoms of the text
files which compose a program.

"External Design" is somewhat similar to "collective works".

> Design Source Data The licensed work, which consists of

Basically, Design Source Data is the "source code".

> Design Generated Data Any data which is generated

We need to include "Design Generated Data" to deal with cases where
there is a "compiled" form of the design that can be used in
manufacturing. We don't want a company to share only this sort of
obfuscated form of "design", while withholding the source.

In particular, sharing Design Generated Data triggers the copyleft
requirements.

> Design Data Design

Basically, the Design Data is the reification of the Design, just as a
"glyph" is a reification of a "character". I'm uncertain whether this
really matters, since we are really always talking about the Design Data
in this license (the Design really only ever exists in your head when
you read the Design Data).

> Product The material object which is created using the Design Data.

A lot of the fuzzy thinking about hardware licenses has to do with
confusing the Product with the Design. In terms of computer science
processing, though, the Product is actually more like the output
generated from a program when it runs, rather than the program itself.

Normally, soft-copyleft licenses don't affect the license of the data
they process! But if we want to keep Products free, then we need to do
something like that.

> 3 Design Domains 3.1 Choice of Design Domains
> 
> Choice of design domain determines the scope of this license,
> including copyleft requirements as described in section 6. When the
> Copyright Owner grants this license, he or she determines the domain
> in one of three ways:
> 
> 1. By explicit selection of one of the domains described in section
> 3.2 (Definition of Named Design Domains).

Of course, this is the best case because it's the least ambiguous and is
still easy.

> 2. By explicit definition of a new Domain, including:
> 
> (a) A generic description of the appropriate forms of Design Source
> Data used within this domain, possibly including alternative forms,
> 
> (b) An explicit definition of what Designs will be treated as Atomic
> Designs within the Design Domain, and
> 
> (c) An explicit definition of what Designs will be treated as
> External Designs lying outside of the Design Domain.

We need this to cover all the cases I haven't listed. "Proliferation" is
mostly a non-issue here, since these are the rules which determine
whether a copyleft is invoked. Once a copyleft is invoked, the
requirements should be compatible, regardless of whether two designs
have exactly the same domain definitions or not (the resulting domain
may be different, though).

Naturally, such statements can be included in future versions of the
license as "Named Design Domains", if they are popular.

> 3. Implicitly, by what Design Source Data are provided. Where such
> materials fit the descriptions provided in the named Design Domains
> provided in section 3.2 of this license, those definitions will be
> preferred. If more than one of the named Design Domains is consistent
> with the Design Source Data which is provided, then the narrowest
> named Design Domain shall be understood to apply (that is to say, the
>  most specific). If the provided documents do not fit any of the
> named Domains provided in this license, then standard Industry
> Practice should be considered in determining the scope of the Design
> Domain (and therefore in determining what Designs are Atomic or 
> External to the Design).

Ugliest case. But it will get used a lot, because this is the "lazy
author" case.

> For any Design which lacks an explicit Design Domain, any Contributor
> is encouraged to add an explicit statement of Design Domain, which
> may broaden, but never narrow the scope of the Design Domain of the 
> Design as interpreted by these rules.

Try to make up for lazy authors by letting anyone downstream make the
implicit explicit.

There is only one example of overlapping domains in the named Domains
listed in this version: the Gate Logic, Block Logic, and Complete Logic
Domains. The Complete Logic Domain subsumes the other two. A work which
contains only Gate Logic would normally be considered a "Gate Logic"
design, unless the author has specified that it is "Complete Logic",
because "Gate Logic" is a *narrower* Domain.

You can think of the "narrowest possible domain" rule as a kind of
inducement to the author not to be lazy about specifying the Design
Domain (by being explicit he can increase the scope of the copyleft).

> 3.2 Definition of Named Design Domains

There are way too few of these, and they are way too biased towards
electrical engineering designs. But mechanical, chemical, aerospace, and
bio-engineering Domains should be included as well.

(To answer luc's question: NO, I didn't intend to limit the license to
"electronics hardware", and YES I do want it to cover all kinds of
hardware designs).

Ideally, though, the definitions would written by practicing engineers
in those domains, not an outsider like me:

> This list of Design Domains is by no means meant to be exhaustive,
> and you always have the option of writing your own explicit
> definition of the Design Domain for your Design. However, if you find
> a Design Domain definition which you think should be included in this
>  license for the convenience of licensors, please contact the Open
> Hardware Foundation (http://www.openhardwarefoundation.com) to
> propose a new Design Domain to be included in future versions of this
> license.

The idea here is to get engineers to tell us what logic domains should
be listed.

> 4 Design Data
> 
> We recognize FIVE classes of Design Data which are treated
> differently according to this License:

"Design Data" here is a little broader than it is used elsewhere in the
license, since it normally *excludes* Requirements and Specifications.
Not sure if this is a problem.

> 1. "Requirements" 

> 2. "Specifications"

> 3. "Design Source Data"

> 4. "Design Generated Data"

> 5. "Usage Documentation"

This is a pretty standard document sequence in engineering. Rapid
prototyping can confuse them a bit, but I think it's still usually
possible to define these.

> Note that this License cannot provide provide protection for the
> ideas expressed in a requirements document (because factual
> information lies outside of the scope of copyright), but only for a
> particular expression of those ideas.

Just informational. Sometimes people don't understand what is and is not
copyrightable.

Also, we don't want to have "requirements trolls" who publish a
statement that requires "a device to do X" and then gets to claim that
all such devices are covered by the OHPL because they "derive" from this.

Of course, such claims would never hold up in court, but let's "nip it
in the bud"!

> Design Source Data is always required to be included in

This is the pay dirt: the Gerber plot, CAD drawing, CAM scripts, PCB
mask, Verilog code, etc, etc, etc.

> Design Generated Data are optional for inclusion in the

It's nice to have pre-compiled files directly usable for manufacturing,
but what we really need is the ability to create them from editable sources.

> Usage Documentation is encouraged, but is not essential

The nice thing about Usage Docs is that there's a strong market pressure
to include them anyway, so we really don't have to worry about enforcing
it through the license.

In any case, as long as there is Design Source Data, the Usage Docs
should be something the community can create as needed.


> 5 Permissions & Manufacturing

(1 - 7)

Apparently, there are SEVEN fundamental freedoms of Open Hardware. ;-)

This is analogous to the FOUR fundamental freedoms of Free Software
provided by the GPL, of course. The complexity is due to the
Products/Design distinction.

> 6 Copyleft Requirements

I think there may be some important omissions in this section.

> 6.1 When Does Copyleft Apply?
> 
> You are responsible for fulfilling copyleft (see 6.3) if any of the
> following conditions applies:
> 
> 1. You Propagate any part of the Design needed for manufacturing to
> another party, including Design Generated Data.
> 
> 2. You Manufacture or contract manufacturing for Products based on
> the Design or on a Modified Design.

These requirements are similar to those of the Apple Public Source
License, in that it required distribution if a work was "externally
deployed". That's roughly analogous to the case of producing Products
from a Modified Design.

> Otherwise, you DO NOT need to fulfill copyleft, including the
> following cases:

Informational: clarification of some obvious non-copyleft use cases.

> 6.2 Definition of Design Source Data: What You Must Include
> 
> The scope of the materials which must be included in the Design
> Source Data depends on the design Domain of the work, as determined
> by the "Choice of Design Domain" in section 3.1: if the copyright
> owner has defined the nature of the Design Domain, you must follow
> that; failing that, if he or she has specified one of the domains in
> section 3.2, you must follow that choice; and failing that, you must
> determine the scope based on the type of materials included in the
> work when you received it.

I think I need to add a requirement to include this license (or a URL
reference to it?) and maybe a changelog or some other stuff. Also, there
may need to be distinctions between distributing the Design and
distributing the Product.

> 6.3 Fulfilling Copyleft

Interesting compromises here.

> Assuming that copyleft is required (under subsection 6.1) and you
> have determined what material must be published due to copyleft
> (under subsections 6.2 and 3.1), you have FOUR choices of how to make
> the Design Source Data available:
> 
> 1. You may submit the Design Source Data to an Open Hardware
> Foundation approved Design Registry on the Internet. If you choose
> this method, you must include with each Product distributed, the
> Design Registry and Registry Identification Number for the Design, 
> either in accompanying documentation or via a label affixed to or
> direct-printing onto the Product.

This is the "publish" option. It's the best one for the community, I
think (Of course, it commits the OHF to providing a list of approved
registries -- but note that OHF doesn't necessarily have to *run* the
registries). We also need a permanent URL for this "approved registry" list.

If this were the only option, though, free software hardliners would be
up in arms, because this violates the "dissident" and "desert island"
tests: it may not be practicable for a recipient to publish data to the
registry.

> 2. You may package the Design Source Data with each separately
> packaged unit of Products distributed, stored in a general purpose
> digital medium which can be viewed by the recipient.

Note "separately packaged unit". This means you can sell "1 Million
Nanobots" in a bag, as long as the bag contains the Design Source Data
for the bots. You don't have to provide 1 Million copies of the DSD. On
the other hand, if you then break that bag down for redistribution, you
need to copy the DSD for each package (not sure if we can put that
constraint on Product distributors, though).

> 3. You may include complete Design Source Data in hardcopy form along
> with each separately packaged unit of Products distributed.

Obviously this should be allowed, but I suspect it'd be rarely used.
It's inconvenient for everybody involved, unless the design is extremely
simple.

> 4. You may include a written promise to deliver Design Source Data,
> good for five years, for no more than the reasonable cost for
> duplication, postage, and handling. You also warrant that you will
> fulfill such requests for Design Source Data, regardless of any 
> changes in your production status, ownership, or financial solvency.
> However, at your option, you may, at any time during the fulfillment
> period, release the data to an approved Design Registry, as described
>  in option 1, releasing you from this obligation.

This is just like the 3 year promise in the GPL, but I like 5 years
better (I have a lot of hardware that old that I'm still using).

Naturally, no one can promise that they won't go out of business, but
this clause holds them to their promise even if they do. To avoid making
that a burden, though, it provides the option of switching to the
Registry method.

> Finally, please note that you need not publish the Design Source Data
> according to option 1 if it has already been done for you.

Well, duh.

> 6.4 No Obfuscations or Technical Protection Measures

This uses modified forms of both the CC language and the GPL language.
It avoids the narrower problems with the CC language by using the words
"intent" and "effect" of "restricting" so it's obviously not just about
file formats. OTOH, if TPM file formats are used, you need the GPL's
permission to hack them.

I can't see that this is as much of an issue for Design data anyway. I
mean, why would it matter? You don't distribute Designs to consumers,
you distribute Products, so the format of Designs is not critical to
consumer appreciation of the Product.

> 7 Patents

This is essentially the terms from TAPR, but updated to use the
copyright language of the GPL. Note that "distribute" is still used in
reference to Products, but that's not a copyright term at all -- we
literally are talking about shipping and receiving material products there.

The GPL has a bunch of extra stuff in its patents section, some of which
is a backlash from the Novell/Microsoft deal. I think TAPR covers that,
though, because it actually includes a covenant not to sue *anybody*
over claims in the Design.

One other change -- I reduced this to "essential patent claims" as in
the GPL 3, but TAPR actually has a broader statement about "all
intellectual property". Should we go back to that (maybe for "mask rights")?

> 8 Disclaimers

Mostly from GPL 3.

> UNLESS OTHERWISE PROVIDED IN WRITING, THE COPYRIGHT HOLDERS AND/OR
> OTHER PARTIES PROVIDE NO ASSURANCE OF SAFETY OF ANY KIND. YOU ASSUME
> ALL RISKS AND LIABILITIES ASSOCIATED WITH MANUFACTURING OR USING 
> PRODUCTS MANUFACTURED FROM THE DESIGN, INCLUDING LIABILITIES FOR
> INJURY OR DEATH.

This is new. Material products can kill or maim you if they don't work
right. This may require some lawyer review to be sure it's valid.
Sometimes there are much more aggressive laws about liability for bodily
harm.

OTOH, there should be the same possibility as with GPL 3 for a third
party to indemnify users against such risks (essentially insurance).

> If the disclaimer of warranty and limitation of liability provided
> above cannot be given local legal effect according to their terms,
> reviewing courts shall apply local law that most closely approximates
> an absolute waiver of all civil liability in connection with the
> Design, unless a warranty or assumption of liability accompanies a
> copy of the Design in return for a fee.

More GPL 3 language.

And that's it.



-- 
Terry Hancock (hancock at AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com