[ohf-licenses] ohf-licenses Digest, Vol 3, Issue 1

[Greg London]

> From: Terry Hancock <hancock at anansispaceworks.com>
> Well it took me long enough to get to this,
> but here's my draft concept for an OHPL.

I think the first FAQ item,
"Is this OHPL compatible with the GPL?"
be a clear "No".

While the OHPL takes pains to make it a
hardware-only license, it is still a
copyright license and it is still based
on copyright law, fundamentally.
Works are works.

Even though the license says it's only
for hardware, one could conceivably apply
it to software. And software licensed under
OHPL would be incompatible with software
licensed under GNU-GPL.

I believe the same would be true of
taking hardware designs currently
licensed under GNU-GPL. I don't think
one could simply relicense them under
the OHPL, nor am I sure that one could
take a GNU-GPL hardware design and use
it as a component in a larger OHPL design.

The GNU-GPL takes an interpretarion of
"derivative" that can be read as
"As wide a definition as allowable by law",
in which case, someone might be able to argue
that putting their GNU-GPL licensed hardware
block inside an OHPL design creates a derivative
work of the GNU-GPL design. In which case,
the OHPL conflicts with the GNU-GPL.

I don't think it's possible to have a
license that adds a restriction such as
a source code requirement that triggers
on hardware manufacturing, and have that
be compatible with GNU-GPL.

The GNU-GPL has the restrictions that it
has, and it won't allow you to lift any
of those restrictions and it won't allow
you to add any new restrictions. Since
the OHPL is different, with different
restrictions, it can't be compatible with
GNU-GPL, unless GNU-GPL explicitely allows
for compatibility by name or something.


Second point: while I get the OHPL is
intended for hardware, I'm not yet convinced
it needs to be restricted to hardware.
It might be possible to have the OHPL be
a hybrid of the GNU-LGPL and the
Apple Public Source License.

The LGPL would have the copyleft be limited
to a functional boundary.
The APSL would require the source be made
public for any derivative, regardless of
whether the work is distributed.

It would then be a matter of defining some
concept of "functional" that would be limited
to a module boundary, a block boundary,
a subroutine boundary, and so on. I'm not
sure how complicated the law would make this,
but it would seem possible to come up with
a list of boundaries and simply state that
anything inside an existing boundary that
you change is a derivative and the OHPL
applies to it.

This might be giving the legal system
more due than it deserves...

Greg