[Openmcl-devel] Porting Wood and how to handle source code conflicts with Digitool

[Gary Byers]

On Tue, 8 Jun 2004, Lawrence E. Bakst wrote:

> I have started trying to port Wood from MCL to openmcl.

For those who may not know: WOOD ("William's Object Oriented Database") is
an OODB that Bill St Clair wrote for MCL.

>
> 1. If someone has done this would you please let me know?
>

> 2. So far it hasn't been too bad. Changed some ppc::subtag... to
> ppc32::subtag changes. However the next issue is that file-length in
> "l1-streams.lisp" is not compatible. MCL 5.x takes a optional second
> argument which wood uses. It's a trivial change. However that leads
> me to #3.

My guess is that there may be a few more changes required; I've heard
that there are some minor CLOS/MOP issues as well.

>  3. What are the licensing issues around making the changes to
> openmcl from MCL? I tried to search the archives for an answer and
> couldn't find any. The best I could find on the web site was:

>  "The implementations began diverging in 1999; there's still a lot
> of code in common, but there's never been any real effort to keep
> them in synch. Code that deals with stream internals, network I/O,
> physical pathnames, threading, etc. is probably not generally much
> easier to port between MCL and OpenMCL than between any two other CL
> implementations (though there may be cases where it is.)"

> So before I "lift" two lines of code from one to the to other,
> what's the scoop? Was the grant to Gary a one time thing or can some
> effort be made to keep things in sync?

Digitool basically agreed to opensource those parts of MCL other than
FRED and the GUI.  A pretty large subset of that subset happened to
coincide with a port to VxWorks (and LinuxPPC) a few years earlier, and
that's pretty much what's evolved into OpenMCL.

Bits and pieces of MCL code have drifted back into OpenMCL over the
last few years (and there's been some drift in the other direction as
well.)  There's no particularly good reason that WOOD hasn't drifted
(or wasn't included in OpenMCL in the first place); it's certainly
a non-GUI part of MCL, and it probably would have been incorporated
into OpenMCL a long time ago if ... I'd remembered about it.

Digitool's primary concern about that code is that it not wind up as
a proprietary part of a competing commercial product, and that's
one of the primary reasons that it's been licensed under the (L)LGPL.
In a perfect world, Digitool would have taken responsibility to split
the sources into "GUI" and "non-GUI" categories and slapped (L)LGPL
copyright/license notices on the non-GUI sources; I'd already done
the split in order to port to VxWorks/LinuxPPC, and wound up taking
responsibility for the copyright/license notices as well.  (I remember
asking about it and being told "we'll trust your judgement", which is
shorthand for "it's kind of a tedious job and it's not very interesting,
so why don't you do it instead of us ?")

I spoke to Alice Hartley of Digitool while I was writing this; she said
that she had no problem with seeing WOOD drift into OpenMCL and agreed
to make the current (post-MCL 5.0) WOOD sources available for that purpose.
I'll try to do this soon; once this happens, WOOD would effectively be
"a part of OpenMCL" (though it'd probably be a more interesting part if
you can get it working ...)

As I understand it, the fact that the "same" sources are licensed under
different terms isn't that unusual; a similar sitaution might exist
in the case of AIX sources that IBM has contributed to Linux (and let's
not even talk about SCO ...).  As part of Linux, the code is covered
by an opensource license; as part of AIX, that same source code might
not be generally available and source licensees might be prohibited
from doing things that they could freely do with the "same" code under
Linux.



>
> Of course, since I own both, I am probably OK to do this for my own research purposes. I guess there are three cases.
>
> a. If I own both can I lift from one to the other for research purposes?
>

I don't know/remember anything about constraints that might prevent this
in MCL's case.  In the case of LLGPL'ed software, the constraints that
kick in only do so when distribution is involved.

> b. If I own both can I lift from one to the other and then
> distribute an image?

Again, I don't know about the MCL case.

The LLGPL case can get murky pretty quickly (that's true of the regular
LGPL, and special Lisp-centric considerations don't generally make things
clearer.)

As a concrete example: suppose that you have an OpenMCL application
that makes heavy use of DELETE-IF-NOT and you've discovered that the
MCL implementation of that function runs significantly faster than
the OpenMCL version and you decide to replace the OpenMCL version with
the MCL version before shipping.  From the point of view of the LLGPL,
you've modified "the library" (the set of classes/methods/functions
that OpenMCL provides) and are therefore required to make the source
of those modifications available to your users.  (From the MCL side
of things, you may or may not have been allowed to do this substitution
in the first place and you may or may not be allowed to redistribute
MCL source code: those questions depend on the details of the MCL
licensing arrangement.)


> c. What about checking in such changes into the openmcl source tree?

I wouldn't want to host source code unless I was pretty confident that
the code in question could be freely distributed.
>
> I've read the licenses and I have my own idea to these questions, but perhaps it's best just to ask first, without my speculation.
>
> I suppose another question is, if ends up being OK to lift from certain parts of MCL to openMCL, do people want to do this?
>
> Minor Gripe: The OpenMCL licenses should really be readable from the web site without having to download the distribution.
>
> Even worse, I can't find the MCL 5.0 license on what I have installed, which I thought was everything. I'll have try and find my MCL 5.0 CD to see if I somehow missed it.
>
> Best,
>
> leb
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>