Istvan Albert said:
Grant Edwards wrote:
Well doesn't your work derive some functionality
from the imported code? Does your code work without
the import?
Interesting questions. As long as there exists somewhere a module with
the same name, which you can import for the same purpose, I would say,
'no'.
For example, assume there is a commercial foo.py that is distributed
only under some costly and onerous license. An enterprising paladin of
free software implements and distributes a work-alike foo.py that
follows the same specifications of the commercial one, but is GPL'd.
Now, I write my masterpiece oof.py:
import foo
while foo.bar():
foo.baz()
Is this a derived work from the commercial foo.py? I don't see how --
it doesn't use _one bit_ from it. Is this a derived work from the GPL'd
foo.py? Again I don't see how -- it's perfectly able to work with the
commercial version instead of the GPL one.
Now suppose the commercial enterprise producing the original foo.py,
wilting under the competition of the GPL version, goes bankrupt. The
commercial foo.py is no longer available. Does this suddenly and
retroactively make my oof.py, whose existence predated the event, a
"derivative work" of the GPL foo.py?
I am not a lawyer, and it wouldn't matter much if I was, because it's
the _courts'_ opinion that counts; I don't think the GPL in general has
ever been tested in the courts, much less the specific provision that a
bunch of bits (oof.pyc, or oof.o if I process that a bit, etc) may be a
derived work of
another bunch of bits (foo.py), with which neither them nor any of their
predecessors in the chain (oof.py) share anything, just because, among
the many potential interface-compliant implementations of (foo.pyc,
foo.o, etc), with which oof.pyc might be dynamically connected to
perform intended purpose, one happens to be covered by GPL.
If I choose to link statically (to make oof.exe, etc), then it does
strike me as reasonable doctrine that the whole oof.exe IS a derived
work of foo.py, because it contains bits derived from it (a processed
foo.pyc). Since oof.exe (if the courts concur) is a derived work of (a
specific implementation of) foo.py, that implementation-foo.py's license
_should_ govern the conditions for copying/distributing oof.exe, which
may (and do, in the case of GPL) require source distribution under
certain licenses, etc, etc.
But if I distribute an oof.exe which does NOT include foo.pyc, and
requires the latter (in some interface-compatible implementation) to be
made available otherwise, then we're back into the contentious "dynamic
linking" issue. Until some courts start ruling on that issue, I guess
we'll all just have to be curious and fruitlessly debate our opinions.
People need to understand once and for all that
GPL is about "forcing" you to make your program
open source. Whether that sounds right
or wrong to you, whether you like it or hate it
is irrelevant.
Yes; what's most relevant is the courts' opinions in the matter, which
unfortunately so far we do not know.
Obviously no one like suddenly realize that they are
bound by GPL but everyone must keep this in mind
*before* choosing that path.
Of course: in particular, choosing to fight in court the GPL, or some
specific provision of it, including the specific one of interest (under
which condition is my oof.o a derived work of anything that is not part
of its precursor sources), will no doubt entail a large amount of odium
coming from large parts of the free software community. Even if a given
corporation's IP lawyers were certain that the "derived work from
dynamic linking" doctrive won't hold up in court, that corporation's
management still has a duty to the shareholders to consider whether the
PR costs of fighting that battle might not exceed the value to the
shareholders of doing that bit of dynamic linking. Personally, I'm very
curious to know how the case would go, but not curious enough to risk
spending my own money and attracting the odium on myself to make a test
case!-)
In practice, the issue is moot, since we _will_ all be submerged by
software patents anyway, compared to which these copyrights issues will
(I predict) soon appear as trifles.
Alex
