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

[Terry Hancock]

Greg London wrote:
> 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.

Did they have a plan?
Did they use the plans for the Fender amp to make their plan?

If not, then yeah, that should be kosher. If so, then they've made a
derivative work in the process.

Because ISTM that either what they did was so trivial that they could
memorize it, and thus not important enough to worry about. OR they did
something complicated, which means they DID generate documentation.

Now, I suspect that in reality they did that by literally
reverse-engineering Fender's equipment ("clean room development"),
because Fender didn't give them plans, but that would've cost them money
and time.

Had Fender released under the OHPL, with the plans, the obvious thing
would be to use the Design to create an *adaptation* which is for their
Modified Design. Doing so would invoke the copyleft and require them to
also release their design.

So, Mesa Boogie would have a choice: throw away the plans and spend
money and time on reverse-engineering, or read the plans and obey the
copyleft (and why not?). IMHO, the copyleft would've been the cheaper
solution.

> The thing is, and I'm not sure this is how your "Atom" and "External
>  design" boundaries work,

Atoms and External designs are exclusively terms for information
objects, not material objects. What you're really talking about is the
distinction between the Design (which can be protected to some degree)
and the Product (which can't).

If the user uses SOLELY THE PRODUCT to recreate a new design, then
there's nothing we even CAN do about that (not without patent
restrictions, anyway).

Oh, which actually brings up a point... the license also includes a
patent license.

Hmm. Actually, the license gives anyone who possesses the product a free
license to the patents.

It COULD be altered to say "anyone who agrees to the terms of this
license" gets a license to the patents.

I dislike patents, though. So I tried to be as open as possible. Also, I
was basically copying the TAPR license wording.

But, it's a possibility? Should we try to leave in the possibility of a
patent-threat for copyleft-avoiders?

Actually, I'm sort of liking that. It would just have to say something
like, by accepting this patent indemnity (or whatever) you agree to this
license. I'll have to think about that.

> 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,

Okay, hold on.... by "pull out one block in that hiearchy", you mean he
copied Alice's *DESIGN* for that block, or he read the *SPECIFICATION*
for an *UNDESIGNED* (i.e. Atomic) block and then replaced it with a
design that meets the same specification?

Because the latter case is indeed the atomic level --- Alice didn't
design that block, she just used it in her design. If, OTOH, she _did_
design that block, then its design is in her Design Source Data (hence
it is NOT atomic). Hence Bob can't just alter it without following copyleft.

Actually, it's possible that my license text is flawed in that it might
not have this effect, but that was certainly my attempt.

I may need to make it so that the existence of a design level in a
design overrides the explicit statement of design domain.

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

But reverse-engineering is from the Product, you're talking about a
change based on the design. Or not? That's the critical issue here.

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

IF he indeed worked from the Product and not the Design, then, yes.

> 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 its place. And that block wouldn't be covered by 
> the OH license.

I don't see that.

> // Alice expresses the functionality of her Fifo module here

Okay, wait a minute. I *think* what you're saying is that since Alice
must provide the *specification* for blocks of logic in her design, that
a competing *implementation* of the same specification could be
developed and inserted?

I'd have to agree with that.

> 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.

OTOH, when Bob combines his module with Alice's design, he's back to
using her design again. Furthermore, his module design plus Alice's
system design is a "Modified Design", and we're back to the OHPL
copyleft requirement.

ONLY if Bob uses his "reverse-engineered" module in a NEW design
(perhaps a completely reverse-engineered design to do what Alice's
design does), will he be clear of the copyleft.

Also, it has to be realized that in doing so, he is working from Alice's
design. Even if he reverse-engineers every module in Alice's design, but
he connects them in the same pattern as Alice's design, he's still
copying her design.

He's going to have to be AWFULLY careful to avoid infringing copyright.

Remember that the law considers compiled binary software to be
copyrightable (even though that is apparently just "functional" in the
way you mean). So the precedent is running against Bob here.

Perhaps more importantly, you are suggesting that Bob do a LOT of
reverse engineering. He'd probably be better off, not to say legally
safer, to just reverse engineer Alice's design at the top level, and
completely ignore its contents.

In other words, design a competing product.

Which is totally kosher. But it's a lot of work. Getting out of that
work is the benefit of playing by the Open Hardware rules.

Joe, who plays by the rules, merely adapts Alice's design and gets his
(Open Hardware) Product to market MUCH MUCH MUCH faster than Bob does.

> 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.

Well, I did say this:

(OHPL text, section 4, about the 5th paragraph):
> 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).

I probably should make it a separate paragraph.

> 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.

Well, there is still an atomic level, which is the design of the logic
gates and registers -- Alice's code only places and connects those, it
doesn't tell you how to make the gates.

That's what my "atomic design" issue is about. It may be a little too
obvious at this level. Of course this is for the "Complete Logic
Domain", I created "Gate" and "Block" levels because I thought that
there would be a demand for that, based on some of my conversations with
hardware folks involved with Open Cores and the like.

> 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.

You need them, because you are making this entire argument on the basis
of an ASSUMED Design Domain, which is Register-Transfer-Level design of
chips, using Verilog as the Design Source Data. I think you're
overlooking the fact that you are making this assumption.

But what if I created a plan for the actual silicon mask, implementing
Alice's design? That plan would include Alice's design, obviously, but
also my own design for gates and registers, as they would be implemented
in actual doped silicon. The "Atomic Design" limit means I'm not
obligated to OHPL my register and gate designs just because I've shown
how to implement an OHPL'd RTL design in them.

Likewise, if I design a computer motherboard based on Alice's CPU, then
I should not be obligated to OHPL that design -- my design is only mean
to use Alice's designed product, it is not a part of her design. That's
the external limit.

Finally, if my mainboard (which is not obligated to be OHPL, but may
be), contains other chips, say, video-controller chips, they don't have
to be OHPL just because Alice's CPU is OHPL. That's the sibling case.

Admittedly, I think most people regard these divisions as common sense,
at least for the cases we've discussed, and so they may not see the need
to specify them -- but I think that as OH becomes more popular, there
will be more attempts to push the boundaries. And we need to be specific
about where they lie. If we just say "as wide as the courts will let
them be", then we just might find the courts ruling more conservatively
than we want. Instead, we just be specific, and say, "here's where the
copyleft ends" -- which also means "here's where the copyleft begins".

(BTW, I really appreciate this help, Greg! You're definitely making me
think. I think I will try to re-write the patent exemption to only cover
people who've agreed to the license and probably any patents required to
USE the product for end users).

Cheers,
Terry

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