Standard interfaces

[Mark Wells]

On Tue, 9 Nov 1999, John Cowan wrote:

> It is becoming common for standards organizations to release packages containing
> Java interfaces which define either some standard directly, or at least the Java binding
> to the standard.  In order to prevent random changes to the interface that
> would break it, it is also common to release such a package under a license which
> forbids modification, while allowing redistribution.
> 
> Is Java code that binds such standard interfaces inherently unfree?

Hmm.  Interesting question.

I'd say that if the package that they release just contains interface
definitions (in Java, things that start with 'interface') and not
implementations, it's not unfree software, but it's certainly not free
software.  It barely even qualifies as software--it's more of an API
specification than anything else.  The problem is that in Java the
compiler actually processes API specifications if they're properly stated.

What's important, IMHO, is that others are free to write implementations
of these interfaces and distribute them under terms that allow
modification.

> Is it incompatible with the GPL?

Another good question.

Here's an analogous case: Is the POSIX specification incompatible with the
GPL?  After all, you can redistribute and modify implementations of POSIX,
but you can't modify POSIX itself.  (Well, most of us can't.)  You have to
use POSIX to create a POSIX implementation.  Again, the only reason this
doesn't work in Java is that some fascist quiche-eating Pascal programmer
decided that Java would have these things called 'interfaces', so that the
compiler could enforce compliance (at the syntactic level) with the API.

POSIX is compatible with the GPL because it only defines a standard, not
an implementation.  Similarly, these API-defining packages should be
compatible with the GPL even though they can't be redistributed with
modifications.

However, I would say that it's better for anyone who is considering
releasing an API-defining package to license it so that modifications
*can* be redistributed, but they must be under a different name.  That
kind of license maintains the 'purity' of the name of my API (for
compatibility reasons) but allows others to fork it if the API itself
turns out to be inadequate.