[Openmcl-devel] Universal binaries? Closed source applications?

[Gary Byers]

On Fri, 23 Jul 2010, Paul Onions wrote:

> A quick question, well two actually:
>
> 1. Is it possible to create a universal binary Cocoa application? I'm on a 
> 10.5 PPC Mac and would like to create an app that also runs on Intel Macs.

The issue that I've always gotten stuck on has to do with how a universal
kernel finds an architecture-specific heap image.  If no command-line arguments
override this behavior. the kernel looks for a file whose name matches its own
with the string ".image" appended, and it had always seemed that that meant
that we'd need some sort of support for fat heap image files.

Gary Palter (IIRC) suggested a simple change that'd make that support
unnecessary: rather than looking for <kernel-name>.image, it'd look first
for a file with an architecture-specific extenstion (<kernel-name>.ppc,
<kernel-name>.x8664, etc.)  That'd seemingly solve the problem and make
it possible to distribute fat application bundles.

That's a fairly simple change, but it was never implemented; to be honest,
there doesn't seem to be as much interest in fat applications (or the PPC
in general) as there was a few years ago.

>
> 2. Does the CCL license permit me to distribute a closed source application? 
> I am unsure of the implications of the LLGPL if I want to distribute a 
> proprietary application. Is it enough simply to call ccl:save-application 
> creating separate kernel and image files (assuming no other 3rd party code in 
> the image)?
>

The license is distributed with CCL in the files ccl/doc/LICENSE and ccl/doc/LGPL.

The general idea of the LGPL is that if you link a (traditional, C) application
against an LGPL-ed library (something like the GNU C library on Linux) and distribute
the result, you aren't required to distribute the sources to that application. If
you modify the library itself and distribute that, then you -are- required to
make the source of those changes available.

The LLGPL (under which CCL is licensed; see ccl/doc/LICENSE) tries to clarify
what this means in the context of a lisp application, where the lines between
"the library" and "the application" are blurrier.  The general idea is the same:
you don't need to make the sources to your application available in order to
be compliant,  if you change CCL itself, you do need to make the sources of
those changes available.  Adding a method to a predefined generic function or
subclassing a predefined class isn't considered to be a change to the "library";
changing the implementation of a predefined method or function is, and it's
the nature of lisp that one could probably think of things that're less clear-cut.
(In a lot of clear-cut cases - not all, but a lot - it's probably in your interest
to make the sources to a change to CCL itself public, to help ensure that future
changes to CCL don't break them.)



> Thanks for any help,
> Paul
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>