[ohf-licenses] Okay, here's OHPL version "0.2"

[Terry Hancock]

Notes on changes I made.

Terry Hancock wrote:
> 1.6 Limitations
> 
> No copyright license can protect functional Products
> from reverse-engineering. This License can only protect
> changes made which copy or adapt the Design. Just as
> with any other product, the Product can be
> reverse-engineered without reference to the original
> Design, and changes made to that Design. Such a Design
> is a new work, and not legally a derivative of the
> original Design.

Greg asked for a stronger statement on the limits of a copyright-based
license, so I included this in section 1).

> However, should the Product be reverse-engineered
> without agreement to the terms of this License, then
> the party conducting the reverse-engineering does not
> receive the benefit of any license to any of the patent
> claims in the Design held by Contributors, which are
> otherwise granted under section 7 of this license.

This notes the patent argument I made, and section 7 has been modified
slightly to make this statement true (I think).

>   Other Intellectual Property Claims Any claims on the
>   Design or Product which are based in intellectual
>   property laws other than copyright or patents,
>   including, but not limited to trademarks, design
>   patents, and mask rights.

The TAPR license includes things other than copyright and patents under
the license terms that are now in section 7. I had removed it, using the
"essential patent claims" language from GPL-3, but I thought better of
it. We certainly need mask rights, and trademarks can be an issue too --
EXAMPLE: the iPod's physical layout is trademarked so you can't copy it
without a trademark license. We don't want that.

> 2.2 Hierarchical Design Model Terms

With apologies to Greg, I'm not convinced about alternate theories of
limiting the copyleft, so the Design Domain and hierarchical model are
still here. [Greg: you might consider drafting an alternative for us to
consider]

>   Element A Product which is used in Products based on
>   the licensed Design, but whose internal design is not
>   part of the licensed Design, nor necessary to
>   understand the Design.
> 
>   Elemental Design A Design for an Element in the
>   present Design.

Luc expressed some confusion with the use of "Atom"/"Atomic" and it is
an unusual usage. In this version, I've replaced them with
"Element"/Elemental", which seems a little clearer to me, too.

>   Sibling Design A Design which is in the same Design
>   Domain as the present Design, but only used alongside
>   it as another Element in an External Design.

This is a mixed metaphor, I realize. We don't talk about "parent" or
"child" designs, so "sibling" domain is an odd choice of words. Should
we change it? "Parallel" perhaps?

> 3 Design Domains
> 
> 3.1 Choice of Design Domains
> [...same...]

> If the Design Source Data should contain source data
> that is at either an Elemental or External level
> according to the preceeding rules, then each Elemental
> or External Design, as defined by the preceeding rules
> of this section, shall be treated as a
> separately-licensed Design, which may be separated or
> included with the rest of the Design Source Data at
> Your option. (Examples of this practice include
> reference designs for Design Elements used in the
> principle Design as well as application notes
> suggesting External Designs that might be created from
> the Design).

I had intended to include this, but didn't in "0.1" -- the idea is that
if you have "Elemental" or "External" designs included along with the
"Design", the default assumption is that they are ALSO OHPL-licensed,
but they are licensed as SEPARATE Designs.

That includes most of the LGPL-like behavior that Greg was asking for.

However, that's only the default. By choosing a more inclusive domain,
the author can choose a more "monolithic"/"GPL-like" behavior, as follows:

> Any Contributor may, at Contributor's option,
> explicitly define a broader Design Domain so as to
> incorporate the included Elemental or External Designs
> into a single Design. However, Contributor may NOT
> choose a narrower Design Domain, if an explicit
> statement of Design Domain has already been attached to
> the Design.

This is an expansion of some text I had in "0.1" about how a contributor
can make the domain "broader" but not "narrower".

> 4 Design Data
> [...]

> Design Source Data which is created to meet a set of
> Design Requirements or Design Specifications is an
> original work which is NOT to be considered a
> derivative or adaptation of the Design Requirements or
> Design Specifications that it meets (This is because
> the only information retained from requirements or
> specifications is factual in nature, not expressive.
> Thus, the final design copies only non-copyrightable
> information from Specifications or Requirements documents).

This is now a separate paragraph, and reinforces the point about the
limits of copyright-based licenses.

> 5 Permissions & Manufacturing
> 
> Provided that you comply with the provisions of section
> 6 (Copyleft Requirements), you hereby licensed to use
> the Design to:

Trivial word change to use the term "licensed" rather than just saying
"you may". Don't know if it matters.

> 6 Copyleft Requirements
> [...]

> 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.
> 
> If you receive a package containing Design Source Data
> in multiple domains according to the rules in section
> 3.1 (either implicitly or explicitly), then the
> copyleft distribution requirements may be applied
> separately to each Domain. You may (at your option)
> separate Design Source Data into separate packages for
> each Domain. However, please note that you must honor
> any explicit statement of Design Domain contained in
> the Upstream Design Data

Coupled with the additional statements under Design Domains, this
explains what needs to happen when multiple Domains are in one package.

> In addition to the complete Design Source Data, you
> must also retain or include:
> 
> 1. Prominent notices at appropriate places within the
>   package to indicate that the package is offered under
>   the terms of this License.
> 
> 2. A copy of the full text of this License.
> 
> 3. Notes indicating what was changed and why (updates
>   to a changelog are suitable for this purpose).
> 
> 4. Credits for original authors and contributors.

Duh. Major oversight in "0.1": we need to require inclusion of the
license and other basic stuff.

> 6.3 Fulfilling Copyleft
> ... THREE choices ...

Instead of FOUR. I realized that 2 & 3 were the same requirement, except
for whether it electronic or paper media was used, so I just contracted
them for simplicity.


> 1. You may submit the Design Source Data to an Open
>   Hardware Foundation approved Design Registry on the
>   Internet. A list of approved registries may be
>   obtained from the Open Hardware Foundation
>   (http://www.openhardwarefoundation.org/registries).
> 
> If
>   you choose this method, you must include with each
>   Product distributed, the Design Registry (by name,
>   approved registry abbreviation, or approved registry
>   mark) and Registry Identification Number for the
>   Design, either in accompanying documentation or via a
>   label affixed to or direct-printing onto the Product.
> 
> 
>   If you use the Registry option, then each separately
>   packaged unit of Products must contain the URL for
>   the Design Registry chosen, the Registry
>   Indentification Number, and a prominent notice
>   indicating that the Product's Design is licensed
>   under this License, along with the URL for the
>   License
>   (http://www.openhardwarefoundation.org/licenses/ohpl/1.0),
>   in either electronic or hardcopy form, either in
>   accompanying documentation, or affixed to the package itself.

This is now a bit longer. I added a requirement for URLs to be included
with documentation (but not the whole Design). This is also a bit more
specific about how to mark Products with a registry number. I also
thought that registries might use marks rather than a textual
abbreviation -- that might aid identification on tiny parts.

URLs may be too long for direct printing on small parts, so I used the
"packaged unit" language as in options 2 and 3.

Mind you, it occurs to me that for something like a nano-device, the
product may be too small even for a registry number. But then again,
that still leaves options 2 & 3.

> 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, or in hardcopy form (e.g.
>   printed on paper).

Contracted version

> 3. You may include a written promise [...]

Unchanged.

> 7 Patents and Other Intellectual Property Claims

Two changes in the following.

First of all, only "Licensees" are granted a patent license, rather than
all recipients of the project. This adds slightly more teeth to the
copyleft, since people who avoid it will be just as open to patent
claims as anyone else who reverse-engineers a (non-OHPL) product (but
not more so).

Secondly, the "other IP" claims are covered as in TAPR. So that covers
mark rights and trademark rights (and any other IP rights).

> Each Contributor grants to you and every other Licensee
> a perpetual, worldwide, and royalty-free immunity from
> suit under any Essential Patent Claims or Other
> Intellectual Property Claims which he or she controls
> to the extent necessary to propagate the Contributor's
> Version of the Design Data or make, have made, possess,
> use, or distribute Products made using it.
> 
> If you make or have Products made or propagate Design
> Data that you have modified, you grant every
> Contributor and every other Licensee a perpetual,
> worldwide, and royalty-free immunity from suit under
> any Essential Patent Claims or Other Intellectual
> Property Claims which you control to the extent
> necessary to propagate the Design Data or make, have
> made, possess, use, or distribute Products made using it.
> 
> To avoid doubt, conveying Design Data to a third party
> for the sole purpose of having Products made on your
> behalf does not cause that third party to grant the
> immunity described in the preceding paragraph.
> 
> These grants of immunity are a material part of this
> License. If any court judgment or legal agreement
> prevents you from granting the immunity from suit
> required by this Section, your rights under this
> License will terminate and you may no longer use, copy,
> modify, convey, or propagate the Design Data, nor make,
> have made, or distribute Products manufactured from the Design.
> 
> Nothing in this License shall be construed as excluding
> or limiting any implied license or other defenses to
> infringement that may otherwise be available to you
> under applicable patent law.
> 
> 8 Disclaimers
[same as before]

Cheers,
Terry

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