All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Stan Bubrouski <stan@ccs.neu.edu>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [OT] use of patented algorithms in the kernel ok or not?
Date: Sun, 21 Dec 2003 21:57:17 +0000	[thread overview]
Message-ID: <20031221215717.GA6507@mail.shareable.org> (raw)
In-Reply-To: <1072034966.1286.119.camel@duergar>

Stan Bubrouski wrote:
> > I expect this was said in jest, but it would be delightful to see this
> > done for real.  To the best of my knowlege it's uncharted territory,
> > so perhaps what you suggest _would_ be upheld in a court of law as
> > permissible?
> 
> No No No No No...do you really think including code for a patented
> algorithm(s) is a good idea?  You are still distributing the code and
> allowing people to illegally use it in countries where they are not
> allowed to.  In essence you are providing a catalyst for them to violate
> a patent and making yourself and other liable along the way.

That is equally true if I publish a book explaining the algorithm in
great detail - enough detail that you could practically copy working
code from the book.  Yet, publishing books seems to be fine.

That's why I said it's uncharted territory.  We don't know how safe it
is to publish code that *doesn't do anything* but does embody a
patented technique *only if the recipient deliberately modifies the
code*.

Please explain the difference between publishing a book that doesn't
do anything itself, but might "catalyse" a person to using a patented
technique, and publishing source text that doesn't do anything, but
might "catalyse" a person to using a patented technique *if they
deliberately decide to infring the patent themselves*.

If anything, the book is more irresponsible because usually books
don't tell the reader about patents on the methods they describe.  On
the other hand, we are very responsible and propose to tell the reader
_exactly_ what their responsibilities are and the consequences of
their actions if they choose to modify the work.  We give them the
knowledge and the choice.

> US law is sick and fucked up, and if someone sues you for patent
> infringement you're most likely fucked, because you can never have
> enough money to defend yourself...

That's true.  And they can sue you _even if you didn't do anything
wrong_ and you're most likely fucked too.  Innocence is no excuse.

So it has little to do with obeying the law, which is totally
ambiguous in this area anyway, and a lot to do with being an
undesirable target, doesn't it?

> for the sake of us stuck in this so-called free
> country (though we can be arrested and jailed without trial?)

You can be arrested and jailed even if you _don't_ infringe any
patents, too.

You have to be pragmatic, but if you are totally ruled by fear of what
they _might_ do, you'll never do anything interesting.  So we push the
envelope a little bit and see how it works out.  See if people find it
acceptable practice, or if it's not a good time to encode that much
personal freedom and responsibility.

It's not at all clear that !CONFIG_USA || CONFIG_PATENT_nnnnnnnnnn
would be "illegal" in the USA.  As you saw from the help text, there
are many people and organisations _in the USA_ which would be permitted
to enable the options.

It's a lot like the binary modules question, only this time it's the
companies with patent portfolios that like to keep the status quo
ambiguous, because it suits their position.  We can recoil from the
ambiguity, or we can take advantage of it to produce better software.

-- Jamie

  parent reply	other threads:[~2003-12-21 21:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-21  1:12 [OT] use of patented algorithms in the kernel ok or not? Albert Cahalan
2003-12-21 10:53 ` Jamie Lokier
2003-12-21 13:35   ` James Morris
2003-12-21 14:30     ` Jamie Lokier
2003-12-21 16:03       ` Xavier Bestel
2003-12-21 14:56     ` Arjan van de Ven
2003-12-21 19:33       ` Stan Bubrouski
2003-12-21 23:25         ` Helge Hafting
2003-12-21 19:29   ` Stan Bubrouski
2003-12-21 19:55     ` Matthias Schniedermeyer
2003-12-21 20:11       ` Stan Bubrouski
2003-12-21 21:52       ` Francois Romieu
2003-12-21 21:57     ` Jamie Lokier [this message]
2003-12-22  9:50       ` John Bradford
2003-12-22 15:34         ` Adrian Cox
  -- strict thread matches above, loose matches on Subject: below --
2003-12-22  1:43 James Lamanna
2003-12-22 11:32 ` Matti Aarnio
2003-12-18 23:11 Lennert Buytenhek
2003-12-19  6:10 ` Linus Torvalds
2003-12-19  7:38 ` Paul Jackson
2003-12-19  8:47 ` Arjan van de Ven
2003-12-19 11:38   ` Jan-Benedict Glaw
2003-12-20 17:28   ` Stefan Traby
2003-12-21 10:33   ` Jamie Lokier
2003-12-21 16:57     ` Pavel Machek
2004-01-13 15:35       ` Chuck Campbell
2004-01-13 19:35         ` Pavel Machek
2004-01-13 21:04           ` Richard B. Johnson
2003-12-22  0:37     ` jw schultz
2003-12-21 23:39   ` Lennert Buytenhek
2003-12-21  1:25 ` jw schultz
2003-12-21 19:40   ` Lennert Buytenhek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031221215717.GA6507@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stan@ccs.neu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.