RE: SWING at OJE

[Nic Ferrier]

>>> Andrew Selkirk <address@hidden> 05-Feb-01 10:50:38 PM
>>>

I always seem to be arguing legal point on this list... apologies to
all those who aren't interested.


I think some of the "clean room" interpretations are wrong. I spent
some time looking into this in the late eighties. I've interspersed my
memories below.

>Rolf is correct in my mis-use of the term 
>clean-room I believe. What I'm creating is an 
>implementation of Swing, but not a clean-room 
>version.  I've done some reading this afternoon 
>and apparently, in order to properly create a 
>clean room piece of software, you need one 
>team who writes a specification on the copyrightable 
>elements of the existing software, and another team 
>which writes the new version based on that 
>specification.  
>Also, the implementation team must never had access 
>to the original  software; ie. if you every used Swing, you 
>can't write a  clean-room version (that is if, from this argument,
>that Swing  is a copyrightable element).

You're right that this is the definition for clean room. However, I
don't think you've got the details about when it's needed quite
right.

If you're interpretation were correct then the owners of the Unix (c)
can sue Torvalds, Stallman et al for their development of a Unix like
kernel, tar, nfs, etc...

And obviously that's not true.

The clean-room requirement (as described above) is necessary to deal
with completly proprietary software. The requirement is needed when
the complete published API is not available and the code has to be
examined to see what it does.

This is what happens: a team of people have to gather to examine the
proprietary code and produce a specification. Then someone who is not
contaminated by that knowledge reieves the specification document and
is locked in a room till he finishes the coding. The lawyers can then
prove that any similarity between the original code and the reverse
engineered code is pure coincidence.

But this is not applicable to Swing (or most of the rest of Java)
because the APIs that we want to re-implement are in the public
domain. 

To clean-room a Java API all you have to do is ensure that you have
not seen the original source code. 

The Kaffe team recomend that you don't download the Sun JDK and if
you do that you remove the source code jar file.

However, there's only one real way to gaurantee that the lawyers
won't get you: the source code for your public version must be
substantially different to the original so that the lawyers can't
proove that it's a dreived work.


The issue here is whether your automatic generation of the interfaces
from the spec documents contravenes any (c). I don't think it does.
You have processed the text - not copyed it.

If you want to be totally bombproof then we (the free software
community) can re-code the API parts (the method and class
declerations) before we release any OJE code. I'm quite happy yo hire
a bunch of java newbies to "clean room" the API docs.

Or we could try and get Sun's permission to auto-generate. Would you
like me to try? I could make soundings if you like.


Nic

PS Since clean-rooming became an accepted methodology some licences
have required that you not "reverse engineer in any way" a computr
program. That obviously stops any effort at all.

If I remember correctly Apple used to have (maybe still does) such a
requirement in their licences.