[Mulgara-dev] Pre-Release Legal Review

[Paul Gearon]

Hi all,

On Jul 15, 2007, at 10:37 AM, David Wood wrote:
> Hi all,
>
> I completed the pre-release legal review this morning.  I updated  
> the LEGAL.txt file as follows:
>
>   - Marked with TODO three projects whose source code is not  
> available online.
>   - Updated 3 URLs.
>   - Updated 8 licenses.
>   - Updated version numbers for 2 projects.
>   - Added Xalan, which must have been lost somehow.

I want to thank David for the hard work in doing the legal review/ 
cleanup.  It's something I'd rather avoid (and usually do).  The  
couple of times I've done this myself (usually for smaller projects,  
or for just a small part of Mulgara) I've always pulled out a lot of  
hair.  I also forgot that licenses tend to change over time.   
Sometimes these changes are for good reasons, but it doesn't help  
those of us at the receiving end.

One thing that came out is that we've been dragging Drools forward  
with us.  This was a proof of concept done many years ago, and is no  
longer relevant to our system.  Hence, I was able to remove the  
Drools libs and the sub-package that used them.

In case anyone is concerned about the removal of Drools, I can  
explain.  RETE (the algorithm in Drools) is really about optimizing  
statement at a time processing, whereas our indexing structure allows  
us to perform set-at-a-time operations.  The principles are the same  
as RETE, but Drools is inappropriate.  Hence our development of the  
Mulgara rule engine.

On to the other licenses...

> Apache keeps changing their project URLs as the projects progress  
> through their system :(  On the good side, several projects with  
> non-OSI licenses changed to having OSI-approved licenses.
>
> Source for the following projects is no longer Internet-accessible  
> for the versions that we are using.  We will need to either provide  
> it ourselves or get the authors to do so:
>
> // TODO: Version no longer available from Apache
>     Apache SOAP
>     JARs:     apache-soap-2.2.jar
>     URL:      http://xml.apache.org/soap/index.html
>     LICENSE:  Apache Software License, v2.0
>               http://www.apache.org/licenses/LICENSE-2.0

We need to update our use of SOAP as well.  Getting the licenses up  
to date will be useful here.  Besides, getting onto the latest Apache  
licenses is always a good thing, given how reliant we are on Apache  
licensed code (all the way back to Xerces).

> // TODO - resolve
>     Date Utils
>     JARs:     DateUtils1.jar
>     URL:      http://www.mousepushers.com/java.html
>               (temporarily removed as of this release check - they
>               promise to make their Java utils available again soon)
>     LICENSE:  BSD Variant
>               http://www.mousepushers.com/licence.txt

We will need to live with this for the time being, but I want to  
remove this jar soon.  We also need to fix some of the date issues  
that came up with the daylight savings bug that was discovered a  
little while back.  This may involve Joda time, or something like it,  
but I'd rather that than this particular library.

> // TODO: version not available on SF.
>     JRDF
>     JARs:     jrdf-0.3.4.3.jar
>     URL:      http://jrdf.sourceforge.net/
>     LICENSE:  Dual license: Apache or GNU LGPL
>               LGPL chosen
>               http://opensource.org/licenses/lgpl-license.php
>
> I recall that Andrew Newman created the JRDF version just for us,  
> but he then nearly immediately created a new version for public  
> release.  That means that we are using a version without publicly  
> available source code.  This is an old problem, but one that I just  
> caught.

90% of our JRDF usage is a set of interfaces.  The Abstract...  
classes are usually quite lightweight.  So moving to an "official"  
JRDF of the correct vintage should be relatively easy.

Hmmm, come to think of it, I thought I *did* move us to another JRDF  
during the port to Java 1.5?

All the same, we rely so heavily on this API that I think we need to  
have the code in our codebase.  Not having it is a real nuisance for  
debugging purposes (as you have to go and find it and add it to  
Eclipse or IntelliJ manually).  I'm all for bringing this code into  
our distribution somewhere.  It helps that it's small.  :-)

> This may seem like small potatoes to some of you, but please recall  
> that if our source code is not *completely* available, then we are  
> not really an Open Source Software project.

That is a really big point.  It's also a big point that we are  
legally at fault if someone takes offense to our incorrect usage of a  
library!!!  Just look at the fallout on Slashdot the moment that  
someone realizes that a project isn't distributing sourcecode correctly.

Regards,
Paul Gearon