Re: RTLinux patent
On Mon, 16 Oct 2000, Raul Miller wrote:
> On Mon, Oct 16, 2000 at 06:45:58PM -0500, email@example.com 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.
> 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.
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). Actually, any other standard application needing real-time
guarantees (or at least attempts at guarantees) might be derived from this
source (say data acquisition). 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
And, as part of an OS, what if someone wanted to use it on one of the
> 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
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).
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?
> 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. 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