[ohf-licenses] ohf-licenses Digest, Vol 4, Issue 5

[Greg London]

> In any case, I think that your balloon represents only the External
> Design limit, and not the Atomic Design limit.
>
> As an example of why I think there needs to be an "Atomic" limit (though
> I'm still open to using a different word):
>
> Consider the LART.

I think I may have collapsed one issue into something else.

Some time ago, a company called Mesa Boogie used to make
tube-based guitar amplifiers. When they first started out,
they would purchase a tube amp from Fender, then rip it up
and rewire it.

The first thing that needs to be clear with folks who use
the OHL is that this sort of behaviour cannot be prevented
by copyright law, so cannot be restricted by a copyleft license.
It's sort of orthoganal to designing the license, but it should
be in there somewhere. The copyleft effect of the license can
only apply to the written expressions of the design. Reverse
engineering the design gets around that restriction.

Now, if Alice puts her amp schematics under the OHL,
and Bob uses Alice's schematics as a starting
point, modified the schematics to reflect their own
changes, then teh OHL may apply to the new design.

The thing is, and I'm not sure this is how your
"Atom" and "External design" boundaries work, is
that I think this ought to be explicitely allowed
in the license so that Alice gets the appropriate
level of expectations from what the license will
and will not do.

It will clearly be better protection for hardware
projects than the GPL can provide. But the wording
should be clear that there isn't just one "design"
and a bunch of "atoms". It's really a hierarchy
of external designs.

A guitar amp may only have one level of hierarchy,
but something like an ASIC will have many levels.

A processor might have many levels of hierarchy.
And if Alice were to design a processor and release
it under an OHF, and then if Bob were to come along
and pull out one block in that hiearchy, and design
his own block from scratch, without using Alice's
code as a starting point for his derivative,

i.e. if Bob reverse engineered that block in Alice's
design and made his own block

then Bob's new block wont be covered by the OH License
because it won't be covered by copyright.

Which says to me that any functional block boundary
in a design, no matter where it is in the hierarchy,
could be reverse engineered and a new block put in
it's place. And that block wouldn't be covered by
the OH license.

And in the case where Alice designs her processor in
Verilog, these hierarchical functional boundaries are
defined in the verilog language as a "module".

module Fifo (clk, rst, pushcmd, pushdata, popcmd, popdata);
 input clk, rst, pushcmd, popcmd;
 input [7:0] pushdata, popdata;

 // Alice expresses the functionality of her Fifo module here

endmodule

module Processor ( clock, reset, enable, cmd, addr, wdata, rdata);
 input clock, reset, enable;
 input [7:0] cmd;
 input [15:0] addr, wdata, rdata;

// Alice expresses the functionality of the Processor module here
// at some point she instantiates a Fifo module

 Fifo U1 (
  .clk(clock),
  .rst(reset),
  .pushcmd(cmd==WRITE & enable),
  .popcmd(some internal signal),
  ...
 );

endmodule


And I think it is important that the license recognize
this limitation by the language the license uses to
describe it's limitations.

The license has its limits because copyright has its limits.
The main limit is that at a functional boundary, such as
a verilog module, that module could be replaced with Bob's
own incantation if he designs his own module without using
any of Alice's code. If Bob implements Alice's Fifo functionality
but does so without using any of her expression, then Bob's
Fifo is not a derivative of Alice's work, and the license
cannot extend to Bob's Fifo when he start's making changes
to it.

If Bob uses Alice's Fifo source code as a starting poitn and
modifies it, rather than create his own code, then the
OHL can apply because copyright law connects Bob's derivative
to ALice's original code.

But at any hierarchical level, Bob can circumvent copyright
be reverse engineering his own module. Which to me says that
the license ought to recognize this limitation and explicitely
deal with it by declaring how the boundaries are defined
if possible.

For verilog, the boundary is a "module" declaration.

And so on.

There is no "atom" versus "external design" in Alice's code
if she designed all the verilog for her processor. What there
is is probably 20 or so layers of hierarchy of modules.
And if Bob wants to replace one of those modules, and he
does so by reverse engineering the functionality, then he
can avoid copyright law and the copyleft aspect of the OHL.

So, it seems to me, that for some languages, it ought to be
possible to explicitely declare these functional boundaries
for various languages most likely to be used for open
hardware projects.

This is so Alice understands the limitations of the license
and so Bob knows what he can and cannot do. Alice cannot
expect the license to apply to a module that Bob reverse
engineers. Alice CAN expect the license to apply to a module
that Bob uses the source code and creates a derivative.

I don't see the need for the two terms Atom versus
External Design. All I see are functional boundaries,
and for many languages, these boundaries can be explicitly
declared in the license.

Greg London