Feasibility of integrating an Aqua interface
werner.randelshofer at bluewin.ch
Sun Dec 2 05:52:57 PST 2007
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
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
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
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
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
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,
More information about the porters-dev