Re: LZW patented file left in .orig.tar source package?
On Fri, 2002-10-25 at 15:33, David Turner wrote:
> On Thu, 2002-10-24 at 00:36, Jeff Licquia wrote:
> > While the decision found that blueprints could consititute part of "a
> > substantial portion of the components", it was clear that paper and glue
> > were also needed. It's not clear to me that blueprints by themselves
> > are enough.
>
> Fair enough, but what else do you need to compile a program (and thus
> produce a known-infringing binary) other than its source code? A
> compiler? Well, Debian's providing that too.
But are we inducing people to build infringing binaries? Given that we
patch the package in an attempt to prevent it, I don't think so.
> > Furthermore, both the statute and the decision makes reference to
> > "actively induc[ing]" the infringing behavior outside the USA. It seems
> > clear that we do not actively induce any such behavior; indeed, one must
> > expend some effort to get infringing packages built, which would include
> > removing roadblocks we actively set up.
>
> (c) doesn't have the "induce" bit -- that's only in (f). But I couldn't
> find a (c) case about blueprints (or, indeed, any other 271 case about
> blueprints or source code).
I suspect that intent is the important distinction. Transporting
blueprints, paper, and glue overseas doesn't seem to be sufficient in
the decision; "active inducement" is also necessary. That's why I think
that the patch is sufficient protection for Debian; it's clear that our
intent is to remove the infringing functionality.
As another example, Apple seems to be happy with the FreeType people
including the patented bits of TrueType, but #ifdef'ed out.
> There are cases which have ruled that source code or even flow charts
> aren't necessary to the disclosure requirements of patents (ask me and
> I'll look them up). I know this is not proof, but it is evidence that
> source code is more specific than is needed for public disclosure.
>
> Looking at it from a larger viewpoint, the idea that merely distributing
> source code and saying, "don't use this" gets around patent law is
> fairly silly. The only sane interpretation is that creating source code
> is "making" the invention, and that source code is the invention. I
> can't see any other interpretation that doesn't lead to absurdity.
I guess I don't see the absurdity. It makes perfect sense to me that
binaries can infringe on a patent, and I can see how providing source in
an easy-to-compile form might be construed as equivalent to providing
binaries. But if we take explicit steps to ensure that the infringing
code is disabled, and if it takes some effort to reenable the code, then
it can't be shown that we intended to induce infringement.
But I'm willing to be educated at this point.
Reply to: