[cc-community] The Question of Manufacturing Copyleft
Terry Hancock
hancock at anansispaceworks.com
Thu Nov 1 12:03:14 EST 2007
Greg London wrote:
>>My point was that the license (contract?) on the plans DID make a
>>stipulation about instantiation/manufacturing of physical objects, not
>>just about "copying". Which is exactly the sort of requirement you need
>>to be able to make for a strong hardware copyleft to work.
> I don't think a copyright license can control how people use the content.
> That requires a contract. And a real, silicon and aluminum ASIC is use,
> not derivative.
I'm not sure I care if it's a "license" or a "contract" -- that's just a
legal detail -- so long as there is a means of implementing it.
> Do you *want* the open hardware project to control instantiations?
> Or do you simply want to make sure that modifications to the source
> are made available?
What a hard copyleft would require is that IF a company makes
modifications to an open design and IF the modifications fall into the
domain of the copylefted element (I have to explain this further, I
know) and IF the resulting hardware is distributed, THEN they must make
the modified design available at least to anyone who receives the
hardware (this can be subject to some reasonable limitations -- just as
the GPL source promise is).
IOW, I don't think they should have to share their derivations under all
circumstances, nor should they have to share all of them, but there are
certain conditions under which I want to trigger such a requirement.
I suspect that, in order to do that, there would have to be a legal
basis for controlling production from the copylefted design.
> I'm pretty sure controlling instatiations would require a contract.
> If you just want to make sure derivatives are made available,
> you'd just have to stipulate that derivatives, even derivatives
> that are not distributed (because an ASIC is not a derivative,
> and selling an ASIC is not distributing a derivative),
> must be made public. or returned to the maintainer, or something.
The only reason to control instantiations is to enforce a copyleft on
derivations that may not have been distributed except as instantiated
hardware.
This is analogous to anyone who distributes modified binaries of a GPL'd
software program being required to provide access to their modified
source code.
The loophole is similar to the web services loophole where a company
manages to escape copyleft by not actually distributing the code in
question, but simply "using" it on a server and providing access to
that. Likewise, a manufacturer could use a soft-copylefted design (e.g.
one under the GPL) to manufacture parts -- and then claim that they were
under no copyleft obligation to share their design modifications because
they weren't distributing the design.
Based on my interviews of people who contribute to open hardware
projects, this is a serious violation of the "social contract" that
developers think they are getting into. I think most would consider it
unethical and exploitative both of themselves and of end users.
> Basically, the license would have to prohibit private derivatives.
> Off the top of my head, I don't know if that violates the
> Open Source Definition or not. I'd have to read through it again.
No it doesn't. But it does seem to violate the "Free Software
Definition" and the "Debian Free Software Guidelines". This is the one
real fracture line between the definitions -- forced sharing of
undistributed design changes. OSD allows it, FSD and DFSG don't.
It is remotely possible that Debian or FSF would regard the change as an
implementation of a copyright that extends to "expressions embodied in
devices" so long as this is how the concept is expressed and limited in
its application.
But, based on the reaction to CC's anti-TPM clause, I'm not sure about that.
That really hinges on the definitional questions I started with.
OTOH, I'm not sure that I care. By and large, there isn't that much
reason to care -- Free Software has never put requirements on the
licensing of the hardware it runs on (I would classify this as a "domain
limitation", hence the use of the word above). And it's unlikely as a
practical matter that you would care about distributing Open Hardware
designs in Free Software-only channels like Debian.
OH will probably have it's own channels.
> Also, is your intent to protect the source code at the core level?
> Or do you want the whole ASIC that uses your core to be made public?
This is another "domain" issue, so I guess it's time to explain that
idea. :-)
My concept is to establish limits based on the concept of "design
domains". In this model, you can think of a "design" as consisting of
"design atoms" combined in some creative way to meet a "design
specification" -- within a particular domain.
Thus, for example, in the "PCB domain", the atoms are chips and discrete
electronic components, and the printed circuit board's specification is
the design specification that the design needs to meet (it's interface
to the next domain up, you might say). Thus, for example, a PCB board
might need to be both "a PCI card" and "a video card" -- properties that
it presents as an atom in the subsystem design domain (when you are
building a computer, you don't care how the boards are designed
internally as long as they meet their published specifications).
The "atoms" in their turn are the "design specifications" in a
lower-level domain, and the design specification is an atom in a larger
domain. Thus, a completed electronic device (say a computer used in a
manufacturing plant), might consist of many different domains interacting:
Materials Science --> Semiconductor Devices (& Discretes)
Semiconductor Device --> IP Cores
IP Cores --> LSI Chips
LSI Chips (& Discrete Devices) --> Printed Circuit Boards
PCBs --> Subsystems
Subsystems --> Complete Computer
Complete Computer --> Factory Floor / Manufacturing Cell
(It's not strictly a linear progression -- discrete devices also lie
beteen Materials Science and PCBs with no intermediates, and mechanical
subsystems may have a parallel relationship with "Subsystems" etc).
Each domain would fall under a separate copyleft, which doesn't bind
other domains (or siblings at the same domain level which do not
directly interact).
This is a generalization of the ideas surrounding "collective works" or
"mere aggregation". We don't want the use of a free chip to only be
possible with free PCBs, nor do we want free PCBs to only be able to use
free Chips.
I've used electronics examples, but in fact, all engineering disciplines
break problems down into hierarchical domains like this, so it's not
that difficult to generalize. However, the domain boundaries are
somewhat arbitrary, so we generally have to rely on industry practices
to establish what the boundaries are, and we have to permit the
combination of design elements which might have slightly different
domain limitations -- especially in industries where the limits have not
been clearly drawn.
> I don't think that affects whether you use a license or a contract,
> but I think it will affect who ands up using your cores, and I am
> curious.
Actually, I know at least one company that will be okay with this. :-)
However, my concept is to let the license be flexible enough to allow
for both possibilities -- kind of like the GPL + LGPL scheme. Then it's
up to the individual project to decide how far they want their design's
copyleft to reach.
This is still a somewhat half-baked idea, but I've been trying to create
a conceptual framework from which a general purpose open hardware
license with a strong copyleft can be created.
I'm hampered mainly by my own poor understanding of IP law, though --
and the fact that this appears to fall into a giant, poorly-explored
gray area.
> The issue, really, is the near million dollars it costs in NRE to
> prepare to manufacture an ASIC. It sort of changes the economics
> when compared to a software company who wants to use copyleft
> software in their works. And I think that a license that required
> the full asic to be made public would be an extremely difficult
> sell. A good explanation might change my mind, though.
Well, it all depends on who you are. If you're the customer, it might
seem like a better idea -- the question then becomes "How do I raise the
NRE costs to contract a manufacturer to make this design for me?"
And while I concede that that's a strong obstacle, there are cases where
it may not be a show-stopper.
For example, say a free chip will save you millions on building and
supporting a PCB that you are selling as part of some product that you
are developing? Then you only care about whether the copyleft will
interfere with your PCB's sales model -- which in my concept, it won't.
If it's a "core" then the same argument can be made from the ASIC
manufacturer's PoV.
A component manufacturer might, likewise, want to use a new polymer
material whose preparation is copylefted -- so that improvements to the
polymerization process must be shared, but not what you make with it.
A computer manufacturer might want to use Open Hardware PCBs in their
design -- that doesn't mean that the entire computers have to be Open
Hardware.
But of course, it also raises the possibility of community-based
projects who build exclusively from Open Hardware -- or at least do so
over many domains.
> So, I'm just wondering where you want to take this.
To the stars, my friend. ;-)
Cheers,
Terry
--
Terry Hancock (hancock at AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com
More information about the cc-community
mailing list