Fwd: Feasibility of integrating an Aqua interface

[Dalibor Topic]

Forwarding here, too.


---------- Forwarded message ----------
From: Dalibor Topic <dalibor.topic at googlemail.com>
Date: Dec 2, 2007 10:07 PM
Subject: Re: Feasibility of integrating an Aqua interface
To: Werner Randelshofer <werner.randelshofer at bluewin.ch>


On Dec 2, 2007 2:52 PM, Werner Randelshofer
<werner.randelshofer at bluewin.ch> wrote:
> Dear readers,
> I am seeking advice for the feasibility of integrating an Aqua
> interface into OpenJDK.

Hallo Werner,

> Are there any legal limitations which could prevent an integration of
> an Aqua interface into OpenJDK?

OpenJDK is licensed under the GPLv2 + Assembly exception with some components
licensed under GPLv2 + Classpath exception, so code going into its
code base needs
to be licensed under a GPLv2-compatible license, at least, or needs to
be explicitly
covered by the Assembly exception, or needs to be covered by the SCA.

The third option is the one that is ultimately preferrable over the other ones.

> 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).

That may be a problem, as the GPLv2 does not allow further restrictions on
usage of the code beyond those in the GPLv2.

> Would it be desirable to include the source code of the Quaqua look
> and feel into OpenJDK?

If you can persuade all authors of the code/artwork/included libraries to
sign the SCA, including Apple, then I don't see a problem from a legal
point of view.

I don't know how easy it will be to get Apple to share the copyright
on that artwork, for example, so I'd suggest pursuing the strategy to
use Quaqua as a third-party dependency for now, while working behind
the scenes to get everyone's consent. There is no harm in asking politely.
If Apple says no, then at least we'd be able to work on workarounds for
the encumbrancies with Apple's artwork.

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

I think that'd be a good start. If Apple agrees to license its artwork
more liberally
after being asked politely, we could revisit the discussion, and if
they deny, then
having it as an external build dependency does not hurt anyone, and should work
equally well. For the purpose of making it easy for users eventually
using SoyLatte
via MacPorts, Fink, etc. I'd suggest packaging Quaqua for one of those
distributions,
in case it's not packaged yet.

As far as binaries go, that aren't hosted on the OpenJDK site, I think
it's up to the
porting project how it deals with bundling dependencies, if it needs
to. Regarding code
hosted on the OpenJDK site, the rules need to be more strict,
obviously, and that's
where discussion on this list comes in, to help us find out what they
should be in a
specific case.

cheers,
dalibor topic