www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Can changing class loader behavior in Ant can violate Java SE license
Date Tue, 13 Feb 2007 00:26:34 GMT
resending (!@#@!#!@# Reply-To)
On Feb 12, 2007, at 7:17 PM, Craig L Russell wrote:

>
> On Feb 12, 2007, at 3:21 PM, Geir Magnusson Jr. wrote:
>
>> I don't think that the problem is with the technique (as it's a  
>> common one), but rather with what the technique is being applied to.
>>
>> If you read the Sun Java SE 6 license (for example)
>>
>>   http://java.sun.com/javase/6/jdk-6-license.txt
>>
>> it says :
>>
>> D. Java Technology Restrictions.  You may not create,
>> modify, or change the behavior of, or authorize your
>> licensees to create, modify, or change the behavior
>> of, classes, interfaces, or subpackages that are in
>> any way identified as "java", "javax", "sun" or
>> similar convention as specified by Sun in any naming
>> convention designation.
>
> There are two parts to this question.
>
> 1. If you write a classloader that loads things differently and  
> don't use the "java" or "javax" name space for your classloader,  
> then there's no violation. The reason the classloaders are not  
> final is specifically to allow different behavior.
>

yes

> 2. If you load a different "jaxb" class from the one in your boot  
> classpath, then you're not changing the behavior of the class. So I  
> don't see that as violating anything.

is there no difference between v2.0 and v2.1?  If not, what's the point?

geir

>
> Maybe you have a different idea of what "change the behavior" means?
>
> Craig
>>
>>
>> So if you actually followed the letter of this license, you  
>> couldn't replace jaxb because you'd "change the behavior".
>>
>> I haven't read the IBM or BEA JDK license, so I'm not sure if they  
>> are required by Sun to have this limitation as well.
>>
>> geir
>>
>>
>>
>>
>> On Feb 12, 2007, at 6:05 PM, Craig L Russell wrote:
>>
>>> For another take on this issue, BEA Weblogic has released details  
>>> on their "dangerous classloader trick". Please see http:// 
>>> edocs.bea.com/wls/docs100/programming/ 
>>> classloading.html#filteringClassLoader
>>>
>>> Craig
>>>
>>> On Feb 12, 2007, at 2:24 PM, Craig L Russell wrote:
>>>
>>>> IIUC, the technique described in Kohsuke-san's blog is the same  
>>>> technique used by the Tomcat web class loader to avoid using the  
>>>> "normal" classes in the server's classpath and to use the  
>>>> classes in the war file instead. This is a well-understood  
>>>> technique and my only issue with the blog post is calling it a  
>>>> "dangerous classloader trick".
>>>>
>>>> I'd be shocked to hear an argument that this technique violates  
>>>> the Java SE (or any other) license. IMHO the reason Java  
>>>> classloaders are not final is so this kind of class loading  
>>>> behavior is possible. I'd be interested to hear anyone argue  
>>>> that Tomcat is legal but Kohsuke-san is not.
>>>>
>>>> So, IANAL (TG) but I don't see any need to ask further.
>>>>
>>>> Craig
>>>>
>>>> On Feb 12, 2007, at 10:09 AM, Davanum Srinivas wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> Does anyone know of a clause in a Java SE license that we would
>>>>> violate if we change class loading behavior in our code? Case in
>>>>> point, Sun forced an version of JAXWS RI implementation into
>>>>> JDK1.6/Mustang. Which is in fact brain dead and out-dated that  
>>>>> the Sun
>>>>> team is asking users to drop in JAXWS-RI 2.1 [1] if folks run into
>>>>> problems. But the endorsed mechanism override mentioned in [1]
>>>>> possible works because of a special hack [2]. So when i brought  
>>>>> it up
>>>>> and Steve sensed possible problems with Ant and how it could be
>>>>> tackled, we get a reply back (see enclosed email) stating " it  
>>>>> might
>>>>> be prudent to make sure that it does not violate the Java SE  
>>>>> license"
>>>>>
>>>>> So here i am asking, Can changing class loader behavior in Ant can
>>>>> violate Java SE license? Just to cover the base, Another question
>>>>> would be can we implement the same behavior as [2] in Axis2 to get
>>>>> things running under JDK1.6?
>>>>>
>>>>> thanks,
>>>>> dims
>>>>>
>>>>> PS: All the discussion is on public soapbuilders mailing list  
>>>>> on yahoo groups.
>>>>>
>>>>> [1] http://weblogs.java.net/blog/vivekp/archive/2007/01/ 
>>>>> running_jaxws_2.html
>>>>> [2] http://weblogs.java.net/blog/kohsuke/archive/2007/02/ 
>>>>> howitworks_runn.html
>>>>> ---------- Forwarded message ----------
>>>>> From: Doug Kohlert <Doug.Kohlert@sun.com>
>>>>> Date: Feb 12, 2007 11:06 AM
>>>>> Subject: Re: [soapbuilders] [ANN]JAX-WS 2.1 FCS released
>>>>> To: Steve Loughran <steve.loughran@gmail.com>
>>>>> Cc: dims@apache.org
>>>>>
>>>>>
>>>>> Steve,
>>>>> Thanks for your explanation of how Kohsuke's solution might be  
>>>>> a problem
>>>>> for ant.  I am adding him to this thread.
>>>>> I think your proposed solution to ant might be beneficial,  
>>>>> however, it
>>>>> might be prudent to make sure that it does not violate the Java SE
>>>>> license.  I will raise the interop testing suggestion internally.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Steve Loughran wrote:
>>>>>>> From: Doug Kohlert <doug.kohlert@sun.com>
>>>>>>> Date: Feb 9, 2007 11:59 PM
>>>>>>> Subject: Re: [soapbuilders] [ANN]JAX-WS 2.1 FCS released
>>>>>>> To: soapbuilders@yahoogroups.com
>>>>>>>
>>>>>>>
>>>>>>> Thanks Steve,
>>>>>>> I will bring this up internally and get back to you next week.
>>>>>>
>>>>>>
>>>>>> Doug,
>>>>>>
>>>>>> 1. I think the main concern of the Ant team would be that you  
>>>>>> don't
>>>>>> leak classloaders over time, not because they care about memory
>>>>>> leakage, but because it really upsets the IDE teams  
>>>>>> downstream. They
>>>>>> want IDEs to run for weeks without problems, and complain when  
>>>>>> ant
>>>>>> builds cause problems. I think tasks probably get cleanup for  
>>>>>> free if
>>>>>> they are all loaded under an AntClassLoader, but if any class  
>>>>>> loaded
>>>>>> in a subsidiary classloader is somehow retained in any form, the
>>>>>> custom classloader will hang around with corresponding  
>>>>>> consequences.
>>>>>>
>>>>>> 2. I've proposed a declarative away to manipulate which  
>>>>>> classes get
>>>>>> passed down from the Ant classloader:
>>>>>> http://www.1060.org/blogxter/publish/5
>>>>>> there'd be an API way that could be used, including over  
>>>>>> reflection
>>>>>> (useful for tasks that want to run on versions  of ant before  
>>>>>> this
>>>>>> patch goes in)
>>>>>>
>>>>>> 3. On the subject of testing, here's a video on how I interop  
>>>>>> tested
>>>>>> my WSRF impl with others:
>>>>>>  http://smartfrog.org/autolinks/googleLTAC06.htm
>>>>>> that was a few months ago; were I to do it now, I'd consider  
>>>>>> hosting
>>>>>> on amazon EC2. dirt cheap, good bandwidth and better  
>>>>>> availability than
>>>>>> a laptop in a room in my house.
>>>>>>
>>>>>> The axis team have been hinting they'd like to do more classic
>>>>>> SOAPBuilder style interop testing, and there's nothing to stop  
>>>>>> all the
>>>>>> OSS soap stacks from being built together and tested against each
>>>>>> other on a daily basis. It's purely engineering effort, rather  
>>>>>> than
>>>>>> legal issues.
>>>>>>
>>>>>> This would be a good incentive for the glassfish team to  
>>>>>> implement
>>>>>> smartfrog deployment components; so far we've focused on  
>>>>>> tomcat and
>>>>>> jboss.
>>>>>>
>>>>>> -steve
>>>>>
>>>>>
>>>>> -- 
>>>>> Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services  
>>>>> Developers
>>>>>
>>>>> ------------------------------------------------------------------ 
>>>>> ---
>>>>> DISCLAIMER: Discussions on this list are informational and  
>>>>> educational
>>>>> only.  Statements made on this list are not privileged, do not
>>>>> constitute legal advice, and do not necessarily reflect the  
>>>>> opinions
>>>>> and policies of the ASF.  See <http://www.apache.org/licenses/>
 
>>>>> for
>>>>> official ASF policies and documents.
>>>>> ------------------------------------------------------------------ 
>>>>> ---
>>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/ 
>>>> products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/ 
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message