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

[Greg London]

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

Think of it as the GNU-LGPL license. The code is Freely available.
But people can create functionally identical works that are not
caught by the copyleft aspect of the license.

You've got some functional subroutine, maybe some string function.
You put it under a license that says "you can use this in any work
you want and that work won't be copylefted as long as you observe
the functional boundary between your code and my code."

The other caveat is "If you modify my code, you have to make those
modifications available to the public."

Note, that if Alice makes a library, and Bob uses that library
in his program, then Bob's code is not affected by LGPL.

Also, if Bob modifies Alice's code, because he wanted to
improve it, change it, fix it, or whatever, then the LGPL
would say that copyleft would apply to the new version of
that subroutine only, not Bob's entire program.

What I'm saying here is that the concept of a functional
boundary is already sort of written up in the LGPL.
The difference I'm applying here is rather than limit
it to "library" functions, whatever that means, instead
limit it to a codified functional boundary, such as a
a subroutine, or a module declaration, or whatever.

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

Except, if Alice releases LGPL code, Bob can look at that code
and design his own application. Just because Alice has an application
using her code, doesn't mean Bob can't directly access the library
components via LGPL.

The issue I have with your description is that the guitar amp
may be made of smaller designs, such as a power supply, a
preamp, and so on. If Alice puts her entire guitar design
under an OH license, that should NOT prohibit Bob from using
Alice's lower designs without invoking copyleft.
Alice's design should NOT be treated as monolithic simply
because of the license she chose.

If Bob wants to use Alice's power supply and preamp, but wants
to use his own tube design, then he should be able to do so
without getting wrapped up in copyleft.

Lemme put it another way:

Just because Alice bundles 20 hierarchical levels into one
design, doesn't mean that Bob can't use some of those lower
level modules and make his own design for the top level.

Yes, there are issues with whetehr or not Bob derived from
Alice's top level design, but it should be clear from the
license that Bob can in fact make his own top level design,
use Alice's low level designs as library components, and
not get pulled in by copyleft of the OH license.


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

What this will end up doing is making any design monolithic
to the copyleft license. It will be impossible to use any
submodule buried in Alice's design, treat it as a library
component, and allow Bob to create his own mid level hierarchy.

If Alice makes a bad design decision and creates a bad
toplevel module, then no one will be able to access the
lower level blocks and build their own top level.

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

Go back to the LGPL idea. Alice has a string function that
does a concatenate. Alice builds a word processor. Alice
puts the whole thing under something like the LGPL.

Bob should be able to use Alice's low level string functions
to build his own word processor, one that is functionally
identical to Alice's, and NOT have his word processor be
copylefted.

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

I've worked on System On a Chip designs with gate counts around
20 million gates, several processors, internal memory, and
communication bridges to allow everything to talk to one another.
I'm currently working on a core by myself that will have a
gate count around 2 million.

The hard part isn't the code.

The hard part is figuring out the spec so that everything will
work in the end.

I've worked on projects for six months or more only to have
the top level architects come down and say "Never mind that"
and have to chuck everything.

Assuming Alice's code is a proven design in silicon,
there will be plenty of incentive just to use the code of
Alice's design as a spec, have someone clean room it into
a design architecture, and have someone else code it up
from scratch.

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

That is the idea.

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

Again, this turns Alice's work into a Monolithic design,
rather than a library of various hierarchical level components.

If Alice has a fifo in her processor, Bob should be able to use
Alice's fifo in his DSP without having Alice invoke copyleft
on him.

If Alice has a processor design, Bob should be able to strip
down the top level, use the instruction handler, the program
counter, the interrrupt controller, and code up his own
ALU so that he can do 16 bit instructions instead of Alice's 8 bit,
tie it all together, and have everything but his ALU be
copylefted.

If Bob codes up his own ALU, and the only connection to the
rest of Alice's design is the functional interface, then
the OH license shouldn't invade across the functional boundary
simply because its functionally similar.

If Bob uses Alice's code for his ALU, then sure, its copylefted.

But Bob should be able to code his own if he wants to. Any
changes he does to Alice's code to get his block to fit
would be copylefted, so peopel would be able to see the
ports in and out of his module, by how the top level
module connects his module to everything else.

If he starts with Alice's top level module, and modifies
it to instantiate his own module, then the top level module
would also be copylefted.

But if Bob codes up his own ALU and adds his own instructions
and does it all from scratch, and the only thing he looks
at is the IO declaration going into Alice's ALU, then I see
no reason copyleft should invade across that functional
boundary.


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

I think you are taking an overly complicated view of hardware
design. A fifo is a fifo. An interrupt controller is an interrupt
controller. They all behave certain ways, with some number of
varying permutations.

There is very little in the way of actual, new hardware design.
Most of it is architecture, getting things to work together,
and finding an application that will sell enough units to
cover your NRE.

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

Except that GNU-LGPL, which is my model for the Hardware license,
does NOT use every aspect of copyright "derivative" as a hook
for when copyleft is "activated".

LGPL says copyleft does NOT kick in across functional boundaries.
Modify ALice's subroutine, it's copyleft.
Compile Alice's subroutine, it's not copyleft.

This is what I was trying to explain in Libre Labyrinth
on page 18, when I talk about the different *degrees*
that different licenses will trigger their copyleft aspects.

GNU-GPL kicks in if you make a derivative and distribute it.
Apple License kicks in if you make a derivative.
GNU-GPL kicks in only if you make a derivative of GNU-LGPL
code inside its functional boundary. Outside that boundary,
it may be a legal "derivative", but the license says copyleft
does not apply.

You can see this in the "overlay" I have on page 23.
different licenses shade in different parts of that overlay.

GNU-GPL overlay is on page 37. Compare that to
GNU-LGPL overlay on page 39.
Or the ShareAlike overlay on page 43 which is almost empty.
The Apple overlay on 45 is completely shaded in.
And non-copyleft licenses, like cc-by don't shade anything
in at all.

The hardware license I propose is diagrammed on page 46.
The Hardware License overlay is on page 47.
> 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.

Yes, Joe will have a schedule advantage if he uses Alice's
work, creats a derivative, and lets copyleft apply to his version too.

The point is that Bob is *allowed* by the license to reuse
lower level blocks of Alice's design and code up his own
top level if he wants to. As long as Bob does not invade
any of Alice's functional boundaries, he can use Alice's
code like library modules under teh LGPL.

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

If I use Alice's block in my ASIC, the mask would be a derivative
of her blocks and mine. But the license I am proposing would
say that the copyleft aspect of the license does not cross functional
boundaries. If I don't modify the functionality of Alice's code,
then the mask of my chip (a chip containing her code and mine)
would NOT be infected by copyleft.

The license doesn't have to declare an "atomic design" and some
"external design" to distinguish her core from my mask.

The license simply has to state that the copyleft aspect
of the license will not cross functional boundaries.

Take a read through my Libre Labyrinth, with special attention
towards what the "overlay" is talking about.

http://www.greglondon.com/libre/TheLibreLabyrinth.pdf

I think you want to use something like the LGPL as a starting
point for a license, have the functional boundary be the
limit of when copyleft kicks in, and then modify the license
so that derivatives must be made public, even if they are
not distributed, and then you're probably 90% there.

There's a section in Libre Labyrinth that eventually builds
up the various concepts to the point that it explains
how an Open Hardware licence would work based off of how
the other previously explained copyleft licenses do and
do not work.

Greg