Feasibility of integrating an Aqua interface

[Werner Randelshofer]

Dear readers,
I am seeking advice for the feasibility of integrating an Aqua  
interface into OpenJDK.

Are there any legal limitations which could prevent an integration of  
an Aqua interface into OpenJDK?
Except for having to restrict end user usage of the Aqua interface to  
Mac OS X, there appear to be no other limitations imposed by Apple  
Inc. which are legally binding. (At least not in my jurisdiction which  
is Switzerland).
After all, there is a Windows Look and Feel in OpenJDK with no more  
limitations than this. But maybe Sun entered a special license  
agreement with Microsoft for this. (?)


Would it be desirable to include the source code of the Quaqua look  
and feel into OpenJDK?
Quaqua is currently a Java specification independent and JVM- 
independent look and feel. It can run on Java 1.4 through 1.6. It can  
run on Apple's MRJ and on Landon Fuller's SoyLatte. Only a subset of  
Quaqua would be needed for a specific OpenJDK port.
Quaqua contains a substantial number of artwork copyrighted by Apple,  
Inc. This is no problem in my jurisdiction, but it might be for other  
jurisdictions.
After all, there is a very marginal number of artwork copyrighted by  
Microsoft in OpenJDK as well (namely some filesystem icons).

How should we proceed with the integration of an Aqua interface into  
SoyLatte?
Should we integrate the source code of Quaqua into SoyLatte, or should  
we integrate Quaqua binaries as a internal or external build  
dependency, or rather only as an internal or external runtime  
dependency?
Dalibor Topic recommended on Sat Dec 1 08:08:57 PST 2007 in the thread  
"processes, goals, infra" to not include third party libraries without  
considering the consequences that this might have:
> For third-party code that means: please don't upload it into a
> project's repository without
> discussing it here first. From a software engineering perspective,
> bundling third party code
> ofter turns out to be a maintenance nightmare (been there, done that
> with Kaffe.org &
> GNU Classpath), so whenever possible, please avoid checking in third
> party JARs, sources,
> etc. into your project's repository, and use more suitable ways for
> your platform to ensure
> that such third party code is available to the port. For example,  
> you could make
> sure that it is packaged for your platform of choice, and document the
> procedure to get
> such build or runtime dependencies installed in the project's  
> documentation.

After reading Dalibor's advice, I think it might be sensible to  
include Quaqua only as an external build dependency into SoyLatte?

With best regards,
Werner