Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!ai-lab!life!burley
From: burley@pogo.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.c++
Subject: Re: comp.lang.c++, rms, and software patents
Message-ID: <BURLEY.90Dec18095004@pogo.ai.mit.edu>
Date: 18 Dec 90 14:50:04 GMT
References: <BURLEY.90Dec14121748@pogo.ai.mit.edu>
	<1990Dec15.235642.10008@zoo.toronto.edu>
Sender: news@ai.mit.edu
Organization: /home/fsf/burley/.organization
Lines: 62
In-reply-to: henry@zoo.toronto.edu's message of 15 Dec 90 23:56:42 GMT

In article <1990Dec15.235642.10008@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

   In article <BURLEY.90Dec14121748@pogo.ai.mit.edu> burley@pogo.ai.mit.edu (Craig Burley) writes:
   >Clearly, if #include requires a license, then C++ (and C) will have to be
   >changed to incorporate a new mechanism that replaces most or all of the
   >functional capabilities of #include without using textual inclusion...

   No, the languages can stay the same.  Only the implementations would have
   to change.  There is no reason not to use #include to signify invocation
   of the new mechanism.  Indeed, ANSI C does not actually guarantee that, say,
   `#include <stdio.h>' is implemented by textual inclusion.

Are you prepared to say that this is definitive legal opinion that:

    1)  "Tokenizing" preprocessors, as compared to text-substituting
        preprocessors (the standard allows for both, I believe), will
        not be viewed by the courts as effectively the same technique
        as covered by the patent?  (After all, the #include mechanism
        still pulls in the file byte-by-byte; or are you talking about
        "precompiling" all #include files so what gets #include'd is
        a "precompiled" file, but never a text file?)

    2)  This (perhaps mythical) include-file patent covers only
        strict inclusion, byte-by-byte, of a text file?

    3)  Even given that the answers to the above two questions are YES,
        that retroactive licensing fees will not be levied against
        anyone who used text-substituting include technology in the past
        N years, which would include most of us?

    4)  Even given that the answer to #3 is YES, that we won't have to
        go to court to make it so, and spend lots of money in the process
        of defending ourselves?

    5)  Even given that the answer to #4 is YES, that corporations won't
        decide to avoid the risk in any case and make every programmer
        in their employ switch to Pascal, Ada, and/or Modula II/III (or
        whatever languages avoid the include-file paradigm) until
        viable alternatives to #include are widely incorporated in
        C (and Fortran 90 becomes widespread for Fortran users)?

My point is not that you don't have a good point.  You have an excellent one.
What you state is almost exactly what should be truth.  "Almost" because
what SHOULD be truth is that patents on obvious things (like include) and
"laws of nature" should never be allowed -- i.e. most software patents.

The problem is, you aren't in charge of the Patent Office or the courts,
and patent lawyers keep telling us that the best way for the industry to
work out the issues regarding software patents is via a lot of long-
lasting, hugely expensive court cases.  Who wants to be the defendants
in these cases?  The line forms on the right...and might well "include"
C/C++ compiler vendors and even people who've created great applications
using C/C++ compilers because of "#include".

Again, though, it is entirely speculative until somebody posts, say, a
patent number for this (still mythical?) include patent.  Then we all
can go to a library (or wherever) and read it ourselves, and find out
who owns it and maybe call them and find out what they're planning to
do to enforce it.
--

James Craig Burley, Software Craftsperson    burley@ai.mit.edu