From: ···@sef-pmax.slisp.cs.cmu.edu
Subject: Re: Dylan/Eulisp
Date: 
Message-ID: <CBvsLL.JsC.1@cs.cmu.edu>
    From: ···@cs.rutgers.edu (Lou Steinberg)
    
    The question is, can you (and we!) be sure you aren't being suckered
    in this deal - today Apple engineers are eager to make Dylan open and
    available, but tomorrow the Apple management says "Thanks for all the
    work, now this is all Apple property and you can't have a language
    that looks like Dylan (or that uses implementation technique A or data
    structure B which we have just patented) unless you pay us $$$ or run it
    only on our hardware."
    
Well, suppose for the sake of argument that Apple management should
suddenly go insane and try to screw the nascent Dylan community for some
short-term gain.  Apple controls the Dylan name (via trademark), so they
could prevent anyone else from distributing a system called "Dylan", at
least until agreements are in place licensing the name to others.

As I understand the intellectual property laws, Apple could not prevent
other groups from distributing essentially the same programming language
under a different name.  To attempt to assert control over the language
design itself they would have to stretch the already shaky "look and feel"
copyright doctrine far beyond the (probable) breaking point.  They are very
unlikely to succeed in that attempt, and it would be stupid to try, since
they hope to use the existing legal doctrine to protect the Macintosh user
interface -- their crown jewels, in a sense.

As for patenting specific implementation techniques or data structures, I
see nothing in the Dylan design that could not be implemented with
techniques already in common use.  It is true that the U.S. patent system
is horribly broken in the software area, and that software patents are
being awarded almost at random, so it's possible that Apple could one day
pop up with a patent covering, say, cacheing of recent method dispatches,
or even hash-tables.  Such patents can be overturned by demonstrating prior
art, but it's a tedious and expensive process.  However, a patent of this
kind could just as easily pop up from IBM or Fujitsu or any of a thousand
small "patent bounty hunter" lawyers who are lurking out there in the
bushes hoping to blackmail honest software writers.  So paranoia directed
specifically at Apple in this case is misplaced; write your congressman if
you think this software patent situation should be fixed (along with the
"look and feel" mess).

In any case, I don't expect Apple to try anything like this.  They have no
incentive to drive us all away from using Dylan, and they have a lot of
incentive to build an open and thriving community around this language.

-- Scott

===========================================================================
Scott E. Fahlman			Internet:  ····@cs.cmu.edu
Senior Research Scientist		Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University		Latitude:  40:26:33 N
5000 Forbes Avenue			Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================
From: J W Dalton
Subject: Re: Dylan/Eulisp
Date: 
Message-ID: <CBwzC4.482@festival.ed.ac.uk>
···@sef-pmax.slisp.cs.cmu.edu writes:

>As I understand the intellectual property laws, Apple could not prevent
>other groups from distributing essentially the same programming language
>under a different name.  To attempt to assert control over the language
>design itself they would have to stretch the already shaky "look and feel"
>copyright doctrine far beyond the (probable) breaking point.  

But lawyers are good at thinking up ways to assert intellectual 
property rights.  People did manage to implement languages called
PL/1 without too much trouble, though.  I don't know if they ever
managed to offer them commercially.  (Multics?)  And the Miranda
trademark seems to have discouraged people from implementing the
same language even under another name.  (Haskell is not the same
language.)

Nonetheless, languages are not ordinarily trademarked.  The
use of trademark indicates a desire for a kind of control that
is at least unusual.  

>As for patenting specific implementation techniques or data structures, I
>see nothing in the Dylan design that could not be implemented with
>techniques already in common use.  It is true that the U.S. patent system
>is horribly broken in the software area, and that software patents are
>being awarded almost at random, so it's possible that Apple could one day
>pop up with a patent covering, say, cacheing of recent method dispatches,
>or even hash-tables.  Such patents can be overturned by demonstrating prior
>art, but it's a tedious and expensive process.  However, a patent of this
>kind could just as easily pop up from IBM or Fujitsu or any of a thousand
>small "patent bounty hunter" lawyers who are lurking out there in the
>bushes hoping to blackmail honest software writers.  So paranoia directed
>specifically at Apple in this case is misplaced; write your congressman if
>you think this software patent situation should be fixed (along with the
>"look and feel" mess).

Surely it's reasonable to have some suspicion directed at companies
who have shown in interest in aggressive and innovative pursuit of
intellectual property claims.

Maybe IBM is also working on dynamic languages, method dispatch,
etc; but we know Apple is doing this.  So again the danger seems
somewhat more real in the case of Dylan.

>In any case, I don't expect Apple to try anything like this.  They have no
>incentive to drive us all away from using Dylan, and they have a lot of
>incentive to build an open and thriving community around this language.

And then what?  Don't people have to pay more for Unix licenses
than they used to?  And in your Igor article, you say:

  While we plan to base Igor on the Dylan language, we do not yet have
  a license to use the name "Dylan", which is an Apple trademark.

So is it going to be a matter of licenses?

-- jd