Dtrace port status
Chuck Swiger
cswiger at mac.com
Fri Sep 21 12:08:07 PDT 2007
On Sep 21, 2007, at 11:06 AM, Kevin Oberman wrote:
>>> So find someone who hasn't read that email, write up a spec for
>>> the missing
>>> fields that dtrace requires and ask them to implement and commit
>>> the change
>>> to the dtrace branch on freebsd.org ? :)
>>
>> this has merit.
>>
>> to be honest, within copyright (UK and EU), i think you could
>> reasonably use structure definitions as they are fundamental to the
>> interaction, not the operation of the code. this has support, though
>> it's not been specifically ruled on in court (certainally not that
>> i'm aware of). there is a much bigger problem around patents and no
>> amount of clean room coding is going to avoid those.
>> ... having said that, neither is adding some secondary structure --
>> that is not how patent coverage works, only copyright.
>
> IANAL. Maybe the FreeBSD Foundation can help to get advice from a real
> lawyer, but this came up at least twice in past court cases, AT&T
> v. University of California, et. al. and the more recent SCO v. IBM
> Linux licensing case.
This is likely to be true in the US as well; the canonical legal
decision here about how to understand software copyright infringement
is known as "Computer Associates v. Altai" [1] which defined an
"abstraction-filtration-comparison" test:
The filtration test requires one to analyze the program modules via a
flowchart, and decide whether each distinct module or section "shows
only an idea" (if yes, the material is not copyrightable, but might
be patentable), or is an expression of an idea. If the latter, the
analysis requires consideration of whether the expression is (a)
dictated by efficiency, (b) dictated by external factors
(specifically interfaces, APIs), or (c) whether the expression is
taken from the public domain. Unless the answer to (a)-(c) are all
no, and the code does not represent a "protected combination", and
unless it constitutes "enough copying to be a wrongful taking", it is
considered "lawful copying" and not "copyright infringement".
Notice (b) & (c) in particular; publicly published APIs generally
cannot qualify or be used as grounds for software copyright
infringement. On the other hand, IANAL, TINLA-- and I'd be much
happier with FreeBSD being lilly-white and 100% clean in terms of the
code it includes.
--
-Chuck
[1]: http://www.bitlaw.com/source/cases/copyright/altai.html
More information about the freebsd-current
mailing list