[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] Inquiry
[This piece has turned out to be lengthy, but hopefully there
is enough interesting stuff in it, especially the second half,
to make it worth reading. Given the length of this piece,
I am explicitly claiming copyright on it and releasing it
under the terms of the free documentation license with no
invariant sections. I don't want this copyright claim to affect discussion
on this list, but if someone distributes this outside the cores list
I expect the license terms to be explicitly mentioned.
Copyright (c) 2003 John Dalton.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is available at the URL
http://www.gnu.org/licenses/fdl.html
]
> (from my point of view, GPL with specific API for closed
> code (like for the linux kernel and it's proprietary
> modules), is the best licence, ...
I'm not sure exactly what you mean here, but I think you
are talking about closing the source of a module,
publishing the API, and linking the closed module
with GPL'd code. Please correct me if I have misunderstood you.
It is a violation of the GPL to statically link GPL'd code
with code covered by a 'non-compatible license' (eg. closed
source). Dynamic linking is not so clear. The Free Software
Foundation takes the position that dynamic linking is not
allowed. Others argue that dynamic linking is okay. It hasn't
been tested in court, as far as I know.
Yes, Linux includes closed source modules. Technically this
is probably a breach of the GPL. In practice, Linus has
decided not to enforce that aspect of the GPL so the closed
source modules stay. An informal arrangement such as this
is probably not a good model for opencores licensing.
Presumably users want some form of certainty, not "well
it's technically against the license, but we will turn
a blind eye to it". (Aside: Take away the 'no linking' clause
of the GPL and you have the LGPL.)
If you are the author of the GPL'd code, you are free
to link it with whatever you want. As before, you
are unlikely to take action against yourself. Like
Linus, you are also free to ignore license violations
by others.
Much of the GPL depends of the definition of 'linking'.
In my opinion, the definition of 'linking' is not clear
for an opencore.
As a first step to trying to solve this problem, I suggest
we think of some case studies and try to figure out in
each case whether linking occurs. **The following are
purely my opinion.** I WANT people to refute my arguments
and propose logical alternatives.
Example 1 (an easy one):
I take two modules and use an HDL compiler to produce
a single executable, which simulates the system when run.
I would argue that the two modules are statically linked,
in exactly the same way as a computer program (since the
binary is one). Hence if one of the modules is covered
by the GPL, I must distribute the HDL for both modules
with the binary.
Example 2 (a harder one)
I take two modules and use an HDL compiler to produce
separate binary libraries of each. I have a simulation
engine running as a server on another workstation. I get
the simulation engine to run a simulation, calling each
module over a network as required.
I would argue that the two modules are probably not linked
(Note that I'm not 100% certain.), provided the interface
to the simulation engine is well documented. I would think
that each module is acting as a self contained program,
communicating over a network. In this case, if I distribute
the simulation binaries, I only need to distribute the HDL
for the GPL'd parts of the system.
Example 3:
I take two modules and use a synthesiser to produce
a bit stream for a single FPGA.
I would argue that the FPGA bitstream is an example of
a statically linked program, so if you distribute
a copy of the bitstream you must also provide the
HDL for both modules.
Some difficult points in this argument.
Is the bitstream covered by copyright (and so covered by the GPL)?
I would think that it probably is. If I went and copied a bit
stream for a closed source product I would probably get taken
to court for copyright infringement. QUESTION: Is anyone
aware of a successful prosecution for copying an FPGA bitstream?
What does it mean to distribute a copy of a bitstream? Distributing
the bitstream on a floppy disk appears to plainly a form of copying.
What about putting the bitstream into a PROM and distributing the
PROM? My guess is that you are still distributing the bitstream.
QUESTION: Have BIOS manufacturers successfully sued anyone for
distributing a PROM containing a copy of their BIOS?
What about programming a FLASH based FPGA with the bitstream
and distributing the FPGA? Am I distributing a device or a
copyrighted bitstream? I can see arguments for both. Maybe it depends
on whether the FPGA stores the bitstream in a form which can be
recovered?. Opinions and arguments from others?
Example 4:
I take two modules and use a synthesiser to produce
a single design file for an ASIC.
I would argue that if a single design file is
produced that it is a form of statically linked
program and source for all modules must be distributed
with the design file.
Once the design file is turned into an ASIC, I would
think that it becomes a device and is no longer covered
by copyright. Hence the GPL does not apply and there
is no legal obligation to distribute HDL with the ASIC
(it hurts me to say this!)
Example 5:
I take two modules and use a synthesiser to produce
individual design files for an ASIC. In the foundry,
these files are combined and used to make an ASIC.
Each design file can be distributed separately, with
HDL being provided only for the GPL'd module. The
single design file produced by the foundry is covered
by the GPL. The foundry is not allowed to distribute this
single design file, as they cannot provide source for it
and so would violate the GPL, but they can use it to
make chips.
Can the foundry distribute ASICs back to the designer
without violating the GPL? Yes, provided the ASIC is
a form of device and is not covered by copyright (and
so outside the scope of the GPL).
This last example seems particularly intriguing. It suggests
that from an ASIC point of view, the GPL can be effectively
made to behave like the LGPL. It ensures that changes to
GPL'd code get released under the GPL. It seems that
closed source can be kept closed provided the boundaries
are very clear between closed and GPL'd code and the GPL'd
code is alway kept in a state whereby it can be treated as
a completely functional unit by itself.
It all hinges on when does a design become a device and cease
to be covered by copyright? What is the definition of a
device? Simulation executables, design files and PROMs
seem to be covered under copyright and for this purpose
are not devices. ASICs seem not to be covered by copyright
and so are devices. FPGAs are a grey area, depending
on how the bitstream is stored and whether it can be
recovered. Perhaps that suggests a test for whether
something is a device: "A bitstream cannot be recovered
from a device"?
Consequently we seem to have arrived at a couple of principles for
applying the GPL to opencores:
1) Objects from which a bitstream, design file, (or other derived
work) can be recovered must be distributed with source, if they
contain any GPLd code.
2) Objects from which a bitstream, design file, (or other derived
work) cannot be recovered need not be distributed with source.
These arguments are leading me to believe that the GPL is a very
good license for opencores!
Thoughts on all this please!
Regards
John
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml