[xquery-talk] Re: [XOM-interest] [ANN] Nux-1.0a2 - XQuery support for XOM

[Wolfgang Hoschek]

I've uploaded nux-1.0a3 to address Elliotte's concerns wrt. XOM:

Changelog:

	• 	Separated the patched class nu.xom.xslt.XSLTransform (LGPL  
licensed, copyright Elliotte Rusty Harold)  from the core library.  
There's no trace of it anymore in the entire distribution.
	• 	If you want it, you can get the patched source code externally  
here:  http://dsd.lbl.gov/~hoschek/XSLTransform.java.
	• 	The patch adds an additional constructor argument (needed for  
flexibility). Copy the file into the XOM source codebase, and rebuild  
XOM from source with cd xom; ant jar
	• 	The license statement now makes it clear that package  
net.sf.saxon.xom is under the Mozilla license (co-developed with  
Michael Kay, the saxon author).


Wrt. Mozilla/BSD. If you are sure that Mozilla and BSD code can't be  
released together, please point us to some material supporting this  
claim. If there's merit to the claim, I'll address it, of course. But I  
strongly suspect it isn't merited. On top of that, Michael Kay, the  
saxon author, seems to have no problem with it. Remember, Michael and  
me co-developed code that code together?

Hope this puts this unfortunate thread to rest for good...

Regards,
Wolfgang.

On Oct 12, 2004, at 5:33 PM, Elliotte Harold wrote:

> Wolfgang Hoschek wrote:
>
>> Eliotte,
>> Lots of fuzz about a little patch adding one constructor argument to   
>> XSLTransform!
>> As you are well aware of, the XOM code you refer to retains your   
>> copyright and license (see the source code). Instead of a copy and   
>> paste it is a simple patch adding an additional constructor argument  
>> to  XSLTransform, and we've been discussing this patch per mail for a  
>> quite  some time now. I'd be more than happy for that patch (or  
>> something  equivalent) to find its way into XOM proper, and as soon  
>> as that  happens I can drop the patched XSLTransform class. Then,  
>> there will be  no XOM code in Nux, and hence no issue. You indicated  
>> that that would  probably happen once you've got xom-1.0final out of  
>> the door.
>
> No, I indicated that I would consider it after I get XML 1.0 out the  
> door. I made no promises that I would do it. Possibly it will get in.  
> Possibly it won't. I haven't made up my mind yet. I sort of suspect  
> there's a simpler solution that would meet your needs and bypass my  
> objections as well. I just don't see it yet.
>
>> Further, you raised the license concern in prior mails, but said you   
>> wouldn't be upset by that patch being in Nux for the time being, so  
>> I'm  puzzled.
>
> I'm sorry if you misunderstood me, but I did not give you permission  
> to include this in NUX. I warned you that there was a license issue  
> and asked you to cure it prior to release, either by separating the  
> code bases or by publishing your code under the LGPL. I'm more than a  
> little surprised you released without doing either of those. What  
> modifications you make in your own code base is your own business.  
> However without adhering to the terms of the LGPL you have no right to  
> distribute your modifications to the world.
>
>> As far as net.sf.saxon.xom is concerned, I fail to see your point.   
>> Michael Kay (the saxon author) and me have developed that code, and  
>> it  is of course under the Mozilla license (again see the source  
>> code). As  soon as that code will be released (bundled) with  
>> saxon-8.2 that code  can be dropped from the nux codebase as well.  
>> Again, you and me have  talked about that before, and this is no news  
>> to you.
>
> If you want to release your code under the MPL that's fine. However,  
> you cannot bundle MPL code with somebody else's LGPL code. The  
> licenses are incompatible. I would have brought this up earlier too if  
> I had noticed it, but I've noticed the problem now so I'm bringing it  
> up now.
>
> In the meantime, though, the license page at  
> http://dsd.lbl.gov/nux/license.html provides a BSD-ish license that is  
> not compatible with either the LGPL or the MPL, and gives no  
> indication that it applies to some classes and not others. You can't  
> just mix and match classes published under different licenses in the  
> same product so cavalierly.
>
>> Lastly, I mailed you and asked for comments before I'd announce the   
>> release. You did bring up interesting and valid technical points for   
>> which I'm thankful, so I'm more than puzzled by your response now,   
>> lacking any kind of community spirit, as far as I can see.
>>
>
> I brought up a lot of technical points, and I brought up the licensing  
> issue. You fixed some of the technical problems but the licensing  
> issue remains. You're using code in a way the license does not permit.  
> LGPL is not public domain. It imposes specific obligations on those  
> who choose to use such code.
>t;> If this athmosphere continues like this, I will soon get close to   
>> dropping all XSL classes and provide independent XSL based on native   
>> saxon rather than TRAX, just like I do with XQuery. Would that be   
>> better in your opinion? The only reason I am not doing this already  
>> is  so that XOM users would not get confused by two separate  
>> approaches  towards XSLT functionality.
>>
>
> I think I would prefer that on technical grounds alone, irrespective  
> of licensing issues. Of course, if you remove all XOM code from your  
> own code base, then there's no licensing problem either.
>
> --  
> Elliotte Rusty Harold  elharo at metalab.unc.edu
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/
> http://www.amazon.com/exec/obidos/ISBN%3D0596007647/cafeaulaitA/ 
> ref%3Dnosim