[ohf-licenses] Hello and welcome!

[Terry Hancock]

Hello all and welcome to the "Open Hardware Foundation Licenses Mailing
List".

There are six people on the list now, which I suspect represents the
interest level in the OHF board, or near enough. I don't actually have
access to the administration interface right now, so this list is pretty
much totally unmoderated at the moment, but I'm sure we'll deal with
that in time. We do appear to have an archive, so I'll try to make this
a good first message...


This list is for discussion of the definition, design, and application
of free licenses for open hardware design data. Goals include:

1) Defining minimum terms to be considered "Open Hardware" (including
   different conceptions and labels for "openness" of hardware)

2) Recommending "best practice" licenses for various situations

3) Creating a FAQ which clarifies the effect of using various existing
   licenses for Open Hardware, including compatibility issues and
   use-cases

4) Composing a new license or licenses to recommend for new projects


There are lots of special problems associated with using a copyright
license to promote freely-developed and documented hardware communities.
 Some people have even suggested that a patent license would be more
sane (though personally, I don't like this idea).

One of them is that much hardware -- even more than I originally
suspected, I am beginning to think -- is often not covered by copyright.
In fact, even the fact that programs in binary form are covered seems to
be an exception motivated by commercial interests.

This necessitates some clever thinking if we are to emulate anything
like the society that surrounds Free Software, and in my opinion, it
also means that, most likely, our preferences for licensing terms will
lead us to different terms than are used with Free Software: the law is
different, so we will need different tactics, even if the strategy is
more or less the same.

I think the differences will be at least as great as those found with
regard to "Free Content" or the "Creative Commons".

One thing that is useful in that regard, is that Richard Stallman, an
important opinion-leader in the Free Software camp has acknowledged
this, and doesn't feel that hardware development has the same "ethical"
obligations as does software. I'm not sure I fully agree with that, but
at least it gives us some hope of a less politicized environment.

Nevertheless, there are more radical opinions out there, and whatever we
do has to fit some abstract notion of "freedom" if we are to have any
credibility at all.

>From the other quarter, we have to deal with the fact that much of
existing Open Hardware is simply design data released under a Free
Software (or in some cases Free Content) license. IMHO, this is
*dangerous*, because the expectations of developers are apparently in
high contrast with the reality of the law.

For example, consider this quote from Timothy Miller (Open Graphics
Project):

"""
While I can't tell you about how the law applies to the GPL-licensed
OGD1 design, I can tell you what I think is the ethical way to treat it.
I want people to learn from it, which means that if there's some part of
it that you need to copy in order to make your design work, I'm not
going to be bothered. In particular, if that part is some standard,
fundamental thing, like how to wire up a switching power regulator, then
I can't even see how the GPL can be applied --- if you didn't copy us,
your circuit would be identical to ours anyhow, so you might as well
just save the time and copy it. To me, the GPL applies to "substantial
portions" of our design. In this case, any design that you would make
which is substantially derived from OGD1 should either be licensed under
GPL, or you should pay us to license the design. Violating that may or
may not be illegal, but it certainly would be an insult to those who
worked hard to design and build it.
"""

And this one, from Dieter (same project):

"""
Making a physical OGD1 card is like compiling gcc. Editing a movie using
a OGD1 or OGC card is like compiling a program using the gcc binary.
"""

(Both from my recent interview).

Now, contrast those opinions with this one, from Greg London, who, while
not a lawyer, does seem to have a fairly strong understanding of
copyright law:

"""
Verilog code, and schematics, and so on, are all
works of expression that can be covered under
copyright. Copyright won't protect the functionality
of a circuit, but it can protect your particular
expression that describes that circuit.

[...]

Once you perform the conversion from verilog code
to an ASIC, you are converting from expression to
functionality. And copyright doesn't protect this
functionality any more than it protects the functionality
of your 16 bit counter.
"""
http://lists.ibiblio.org/pipermail/cc-community/2007-October/002421.html


The *danger* is this:

If there is a sharp contrast between ethical expectations and legal
realities and some entity should exploit this difference, as Tivo did
when it locked down the Linux kernel used on its devices, it will create
a strong impression among the most important opinion group -- the
developers themselves -- that "Open Hardware doesn't work". Because, if
they go in with one expectation and something entirely opposed to that
happens, then it *hasn't* worked, at least from their point of view (and
developers matter most, because without them, there will be no open
hardware to promote).

So, either, we need to improve developers' understanding of the reality
of using existing licenses (and find a way to motivate them within that
sphere), OR we need to change the rules with a new license that comes
closer to their expectations.

Both are valid; both are appropriate to discuss here; and both should,
IMHO, be done. However, I find the latter challenge to be the most
interesting, and I think it will be the most fruitful in the long run,
just as the GPL was more fruitful for Free Software than were
non-copyleft licenses such as the BSD and MIT/X11.


For the purposes of discussion I would like to recommend a couple of
definitions:

"soft copyleft" -- a copyleft which applies strictly to digital
representations ("software" in the broad sense of the word), such as
plans, writing, documentation, etc.

and

"hard copyleft" -- a copyleft which applies also to the physical
instantiations of designs. In other words, one that applies when you
make a thing from the plans, rather than when you distribute the plans.

Note that these are not the same as "weak" and "strong" copylefts, which
refers to how tightly the copyleft binds to either kind of work. For
example, both the GPL and the GFDL have been described as "strong
copylefts", while CC-By-SA is in some ways a "weak copyleft" because it
allows more exemptions from copyleft rules and does not impose a source
requirement. But both only apply to "soft" works, so they are "soft
copylefts".

To my knowledge, the only already-existing "hard copyleft" is the TAPR
license, and I'm not sure about whether it is legally enforceable. There
may be others I don't know about.

Also, I think we should try to maintain a distinction between "what is
legally possible" and "what is ethically desirable". Many people
substitute ethics for law and law for ethics unthinkingly, and a lot of
confusion results.

For example, I might say at some point that "it is legal to have a
copyleft requirement which says you must jump up and down constantly
whenever you use the program", but that doesn't at all mean that I think
such a license would be a good idea or even ethically conscionable.

On the other hand, if I say (as Timothy does in the quote above) that it
is ethically desirable for users of Open Hardware to maintain the
openness and freedom of communication that makes Open Hardware possible,
it doesn't necessarily mean that I know how to enforce that legally, nor
even if it is possible to do so.

At some point, of course, we'll want to bring the two together, but it's
entirely reasonable to try to tackle them separately before doing that.
You have to understand your tools and materials before you can build
anything with them.

This becomes particularly sticky in an international context, because
the legal frameworks in different countries are different enough that
the *effects* of a license may be quite different in (e.g.) Spain from
what they would be in the U.S., even if the *intent* and the *wording*
are the same. In fact, it sometimes happens that the same intent can't
be achieved by *any* choice of wording.

And with that food for thought, I will sign off, as this message is
already too long! :-)

Cheers,
Terry


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