[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RTLinux patent



On Mon, Oct 16, 2000 at 06:45:58PM -0500, owinebar@free-expression.org wrote:
> > > Furthermore, in regards to the DSFG being limited to copyright
> > > restrictions, all I see is: Derived Works The license must allow
> > > modifications and derived works, and must allow them to be
> > > distributed under the same terms as the license of the original
> > > software.

On Mon, 16 Oct 2000, Raul Miller wrote:
> > Are you saying this is not the case with rtlinux? Seems to me that
> > modified rtlinux can be distributed under the same terms as rtlinux.

On Mon, Oct 16, 2000 at 10:39:34PM -0500, owinebar@free-expression.org wrote:
>    Yes (I'm saying this isn't the case with rtlinux). I'm at a
> disadvantage in suggesting realistic derived works that aren't part of
> Linux, however I will give it a shot. Joseph Carter has said any such
> development is forbidden anyway because MacOS and Windows aren't GPLed
> - I'm guessing the presumption there is that the derived work would
> have to be part of the OS, so I have to avoid that.

>    What if someone wants to develop a free real time "kernel" that runs
> under one of these OSes while mostly taking it over.  The easiest thing to
> see in this regard would be either as a core part of a game engine
> (someone starting from scratch _might_ find it useful to start and
> learn from the relevant rtlinux sources in terms of playing close to the
> hardware). 

There's plenty of prior art for game engines like this.

> Actually, any other standard application needing real-time guarantees
> (or at least attempts at guarantees) might be derived from this source
> (say data acquisition).

Likewise, there's quite a bit of prior art for data acquisition 
systems.

> Now you might question why they would develop it under Windows (or
> whatever) instead of Linux, but the GPL makes it clear that creating
> such derived works are guaranteed rights, though external developments
> not under the distributor's control may constrain them (and, according
> to clause 7, basically revoke the GPL, at least for redistributors).

You've not shown that this patent is relevant for your hypothetical
cases.

>     And, as part of an OS, what if someone wanted to use it on one of
> the free BSD's?

Seems to me that you'd have the standard problem of GPL in a BSD kernel
-- you'd have to do it yourself, because the BSD folk would want no part
of it.  Also, it's likely you could argue that this would be a case of
modified rtlinux, which is already allowed.

> > More generally, patents are an intractable problem for free software.
> > Many patents have dubious viability (for example: often prior art exists).
> > Note that in the U.S., a patent examiner's chances for advancement are
> > based on how many patents they've approved.  Prior art isn't even an issue
> > in that context (except that denying a patent based on the existence of
> > prior art would tend to reduce the number of patents which are approved).
> > 
> > Also, it is impossible to guarantee that any piece of software is
> > completely free of any patent.
> > 
>    While true, this is also somewhat irrelevant in this case.  In this
> case, you do, in fact, know that the software is _not_ free of any patent.
> It's not a question of whether you're going to distribute software that
> may, or may not, at some future time, have patent problems.  Here the
> question is whether you're going to distribute software that has known
> patent problems.  

That's potential patent problems -- I don't know that there actually
will be any.

>    I mean, it seems to me a good part of the Debian social contract is
> being able to create derived works from the software you distribute as
> free without worrying that there are known patent issues (as you say,
> there's always the risk of unknown or future patent (or whatever legal
> variety) problems, but at least that you aren't exposing me to ones that
> are, in fact, known).

Nope, there's nothing Debian can do to protect you from patent problems.

>    And while I fully support all efforts to legally invalidate these
> patent problems, especially as regards free software, shouldn't Debian
> at least _try_ to isolate its users from these problems while they
> exist? Isn't that the reason for free, non-free, and those pieces of
> software you won't redistribute at all?

The only way to guarantee this is to not distribute any software.

> > So, we basically ignore patent issues unless the patent holder becomes
> > troublesome.  Then we decide what to do on a case by case basis.

>     And yet I know, from long time reading of this forum, this isn't your
> policy on copyright (I can't imagine you or others predominant here
> saying, "we'll ignore copyright issues until a copyright holder becomes
> troublesome"!).  The substantial difference I see here is that, since the
> Berne Convention (I think it was), the presumption is that works are
> copyrighted, whereas (as said above) it's largely unknown whether any
> patents apply.

That's one substantial difference.

Another is that the author of the work is typically not the patent holder.

> The question here is, what do you do when you know a patent applies,
> and whose license would render a work non-free, even if the patent
> holder isn't being troublesome (directly to Debian, anyway, though
> they may be to someone who derives a work from code distributed in
> "free").

I believe that every piece of software distributed by debian falls
into this category.

-- 
Raul



Reply to: