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

[Terry Hancock]

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

But that's a consequence of the limits on copyright, not the LGPL.

The law does not evidently follow the same rules of "functional" versus
"expressive" content that you favor, so this isn't necessarily a clear
boundary.

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

The "or whatever" is why I think that this has to be spelled out by
defining domains. In your example, separate modules could be defined as
Atoms if Alice so chose.

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

Hmm. I think that should be up to Alice. By explicitly defining the
Design Domain, she can expand the range of the copyleft, making it more
"GPL-like", or she can leave it with narrower domains, making it more
"LGPL-like".

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

Absolutely. But he may have to license the result under the OHPL if the
modules are not basic enough to be considered Atoms by Alice's choice of
Design Domain.

> Yes, there are issues with whether 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.

Certainly, that is one possibility, but I don't think it's obvious that
it *should* be that way. I think it should be a choice made in the
licensing process: "how finely do I want this to be defined?" versus
"how strongly do I want this to be copylefted?".

Another good example is the business with whether CC-By-SA photographs
should have a copyleft which binds text which the photos are used to
illustrate. Some people want that, and some don't.

The OHPL provides a sliding scale. And just as the LGPL can be converted
to GPL when combined with GPL work (but GPL can't be down-converted to
LGPL), the OHPL's copyleft can be slid upwards to broader domains, but
not downwards towards narrower ones.

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

Actually, it depends on the choice (or definition) of domain. If Alice
wants to say that the Verilog module is the atomicity of the design,
then she can. If not, she can make the whole thing monolithically OHPL,
as you say.

I've heard from both sides on this -- some people want the narrower
copyleft and some want the broader one (in fact some people won't be
happy with ANY limits on domain, but I think there always has to be some
limit -- because if we don't pick it, the courts will).

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

Again, that's only if they don't want to honor the license, and that's
not our market. We're not designing this for the benefit of people who
want to take content out of the free-licensed domain. We're just trying
to have some sensible limits so we don't try to copyleft all
technological civilization on the basis of one little bolt (because if
we do that, that won't actually happen, what will happen is that the
courts will draw a line for us -- maybe not where we want them to, and
maybe not consistently).

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

If so, ISTM that is unavoidable.

I did modify the patent licensing terms, though -- that works out pretty
simply. It just means that if somebody reverse-engineers the work, they
don't automatically get any patent licenses granted in the license.
Thus, you're in the same situation as if you had not used OHPL, and you
can sue them for patent violation if they are in fact violating a patent
of yours.

That probably won't help a lot of people, but it does mean you aren't
giving up the option.

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

Again with the "should"! :-)

I still think that's Alice's decision. For myself, I don't see an
ethical compulsion either way -- it's a quid pro quo. And it's up to
Alice to decide what her quo is worth.

> The hardware license I propose is diagrammed on page 46.

Of course, that may not be the same as what I'm aiming for here.

The idea for OHPL is to be the strongest reasonable copyleft you can put
on hardware. We *want* to actively encourage the growth of a copylefted
domain of design elements that can be used in copylefted designs. We're
not really trying to protect the interest of people who want to escape
the copyleft.

That won't be for everyone, any more than the GPL is for all software
(there are a lot of people who prefer the BSD or MIT/X11 licenses,
without copyleft, or the LGPL with its limited copyleft), but I think it
needs to exist.

Cheers,
Terry

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