www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Schmidt <cli...@apache.org>
Subject Re: XSLT code using LGPL is OK? (fwd)
Date Sun, 06 Nov 2005 22:55:49 GMT
Sorry I haven't been on the lists much in the last two days... 
(actually I see the first request was 5 days ago -- missed that one  
some how).

If you can only distribute the compiled XSLTs, we can do this under  
the SISSL (one of the many slight derivatives from the MPL).

more below

Cliff

On Nov 6, 2005, at 7:23 AM, Henri Yandell wrote:
> On Sat, 5 Nov 2005, Antonio Gallardo wrote:
>
>> Thanks Henri!
>
>> Can I forward the answer to the lenya devel? If not posible to  
>> dev@lenya then can forward it to lenya PMC?
>
> Glad you asked. I've spent some time re-reading the various LGPL  
> threads, and will spend some more (what are Sunday morning's for  
> eh?) in case my statement was wrong.
>
Thanks for helping out, Henri!

> I have to keep reminding myself that this is XSLT and not Java.
>
> The status is:
>
> LGPL is unusable for Java due to legal confusion in the licence.  
> This maps to other languages, but they're undefined. No import, no  
> SVN, no distribute.

I actually disagree with this point (after talks with FSF over last  
six months) -- I think the issue is the same for LGPL as with the  
other licenses that have terms that go beyond the Apache License.   
The problem is that we don't have consensus on which of the licenses  
that have stricter terms that those in the Apache License should we  
be redistributing.  But, I'll leave the details of that issue to  
another thread.

> LGPL is usable for C/C++, provided that the feature is optional.  
> I'm unsure what the status is on SVN and distributing; but I think  
> it's not allowed.

Same issue for distributing.  At least as problematic (and I think  
more problematic) to distribute binaries that include C/C++ LGPL  
libraries.
>
> The former is being resolved in the hope that we can treat Java and  
> other languages in the same way as C/C++.
>
> So the question is how to interpret XSLT. At best it's usable for  
> optional features, but not storable in SVN/distributable. At worst  
> it's not usable at all in the meantime, but will hopefully change.
>
again, it's not about the linking, it's about the distributing of IP  
that is licensed under terms that are very different than Apache  
License terms.  So, it's no different for XSLT than for anything else.

> ---
>
> As far as I know, anything on this list is forwardable to the PMC  
> lists as this list is open to any committer. You've my permission  
> to forward my answers to the dev list too, though bear in mind it  
> seems to be a subject that doesn't like to sit still and I may be  
> incorrect in my understanding. IANAD (director).
>
>> I have another question, seems like this code is dual Licensed.  
>> The 2nd license is: Sun Industry Standards Source License Version  
>> 1.1 (see below). Is this license also forbidden?
>
> I suspect not. Sun have deprecated it, and as their licences are  
> increasing in usability for us it would suggest that this older  
> licence was unusable for us.  We mostly seem to discuss Sun's BCL  
> and SCSL licences though; I've not seen a lot on SISSL.

Until we have a policy on how we treat various licenses (coming by  
ApacheCon), we should not be distributing code under the SISSL.   
However, if the XSLTs can be distributed in compiled form, we can  
sublicense the compiled XSLTs under the Apache License as long as we  
follow the requirements in section 3 for doing so.  The SISSL  
provides the same sublicense executables (meaning anything other than  
source)  under a license of your choice as long as you don't violate  
other license terms.

If this compiled XSLTs idea is doable for you guys, let me know and  
I'll give you explicit instructions as to how to make sure we meet  
the requirements.

Cliff


---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message