Feasibility of integrating an Aqua interface

[Werner Randelshofer]

Dear Dalibor,

On 02.12.2007, at 23:07, Dalibor Topic wrote:
> 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.

Thanks, I knew about the Classpath exception, but I wasn't aware of  
the Assembly exception and about the alternative possibility using the  
SCA.


>> Except for having to restrict end user usage of the Aqua interface to
>> Mac OS X, …
>
> That may be a problem, as the GPLv2 does not allow further  
> restrictions on
> usage of the code beyond those in the GPLv2.

Yes, you are right.


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

The problem with Quaqua is, that - by design - it can fully implement  
the Aqua Interface on any platform it is running on. There are many  
restrictions in its current implementation, but I am about to lift  
some of them in the process to make it work with SoyLatte on X11. Once  
this is done, it won't be too hard for others to lift the remaining  
restrictions.

I don't see Apple licensing the full Aqua User Interface under GPLv2.  
No matter how nicely we ask. ;)


I think we can stay within all these legal restrictions by using an  
approach which does not require inclusion of copyrighted material from  
Apple into OpenJDK.

For example, an OpenJDK AquaLookAndFeel could make use the Cocoa API  
to render the Aqua interface at runtime.
I think this is what Apple does with their look and feel  
implementations anyway.


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

Yes, I think we can bundle SoyLatte with Quaqua in this way.


With best regards,
Werner