Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Morgan Delagrange wrote: OK, Java-specific question. It seems likely that altering or inlining LGPL code pollutes the Apache license. Are you of the opinion that IMPORTING but not altering or distributing LGPL classes pollutes the Apache licecnse? And if so, can that be stated on the Wiki page? If LGPL code cannot be imported, it's pretty much useless in any capacity for Java projects. Bingo. The only *reasonable* way of dealing with LGLP stuff would be thru some for of reflection (reflection, for those who don't know, is the ability for java to connect to 'named' resources of classes. it's the most *dynamic* form of loading for a language which is already entirely dynamically loaded). So, suppose that LGPLObject is there somewhere in your classloading space (the classloader is the virtual machine subsystem that looks for your classes, classes being the objects and main units for java programs, all classes are always dynamically loaded) and this LGPLObject contains the method (java terminology for a function) called doSomething() If you use *regular* programming practices you have to do import LGPLObject; then LGPLObject o = new LGPLObject(); o.doSomething(); that will 1) ask the classloader to find that object 2) allocate memory for it 3) create the object 4) invoke the object method doSomething This means, mostly, for legal sakes that the LGPLObject *MUST* be in the classloading space during compilation time. Now, if we use reflection, we can do Class c = Class.forName(LGPLObject); Object o = c.newInstance(); Method doSomething = c.getMethod(doSomething); doSomething.invoke(); which compiles even without having the LGPL library in your classpath. *BUT* programming java in this way is *FOOLISH*. Reflection was created to load classes programmatically at runtime, it was not created as a way to route around legal problems. -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Stefano Mazzocchi wrote: Morgan Delagrange wrote: OK, Java-specific question. It seems likely that altering or inlining LGPL code pollutes the Apache license. Are you of the opinion that IMPORTING but not altering or distributing LGPL classes pollutes the Apache licecnse? And if so, can that be stated on the Wiki page? If LGPL code cannot be imported, it's pretty much useless in any capacity for Java projects. Bingo. The only *reasonable* way of dealing with LGLP stuff would be thru some for of reflection (reflection, for those who don't know, is the ability for java to connect to 'named' resources of classes. it's the most *dynamic* form of loading for a language which is already entirely dynamically loaded). So, suppose that LGPLObject is there somewhere in your classloading space (the classloader is the virtual machine subsystem that looks for your classes, classes being the objects and main units for java programs, all classes are always dynamically loaded) and this LGPLObject contains the method (java terminology for a function) called doSomething() If you use *regular* programming practices you have to do import LGPLObject; then LGPLObject o = new LGPLObject(); o.doSomething(); that will 1) ask the classloader to find that object 2) allocate memory for it 3) create the object 4) invoke the object method doSomething This means, mostly, for legal sakes that the LGPLObject *MUST* be in the classloading space during compilation time. In legal terms, your program will not build without a class named LGPLObject which has a public doSomething() method. So, you *depend* on it. In a sense, with import you're stating dependency in your sources. Now, if we use reflection, we can do Class c = Class.forName(LGPLObject); Object o = c.newInstance(); Method doSomething = c.getMethod(doSomething); doSomething.invoke(); which compiles even without having the LGPL library in your classpath. In legal term, again, your program will *behave differently* if a class named LGPLObject exists in your runtime environment and it happens to have a doSomething() public method. With dynamic loading you're not stating dependency, merely *acknowledging existence*. As the concept of derivative work is about something that extends or change a preexisting work, the second approach will probably skip it (specially if your program tests for the result of the snippet code and survives when the given class is not in the path). I don't think that even reflection will stand in court if your program cannot perform its duty without the given library being there. I.E. fine when alternate services can perform a task, or for non-essential components of a project. *BUT* programming java in this way is *FOOLISH*. Reflection was created to load classes programmatically at runtime, it was not created as a way to route around legal problems. +1 disclaimer type=IANAL ditto. Also, I am just a plain committer, so take it as just my opinion. /disclaimer Regards, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Santiago Gala wrote: Stefano Mazzocchi wrote: Morgan Delagrange wrote: OK, Java-specific question. It seems likely that altering or inlining LGPL code pollutes the Apache license. Are you of the opinion that IMPORTING but not altering or distributing LGPL classes pollutes the Apache licecnse? And if so, can that be stated on the Wiki page? If LGPL code cannot be imported, it's pretty much useless in any capacity for Java projects. Bingo. The only *reasonable* way of dealing with LGLP stuff would be thru some for of reflection (reflection, for those who don't know, is the ability for java to connect to 'named' resources of classes. it's the most *dynamic* form of loading for a language which is already entirely dynamically loaded). So, suppose that LGPLObject is there somewhere in your classloading space (the classloader is the virtual machine subsystem that looks for your classes, classes being the objects and main units for java programs, all classes are always dynamically loaded) and this LGPLObject contains the method (java terminology for a function) called doSomething() If you use *regular* programming practices you have to do import LGPLObject; then LGPLObject o = new LGPLObject(); o.doSomething(); that will 1) ask the classloader to find that object 2) allocate memory for it 3) create the object 4) invoke the object method doSomething This means, mostly, for legal sakes that the LGPLObject *MUST* be in the classloading space during compilation time. In legal terms, your program will not build without a class named LGPLObject which has a public doSomething() method. Incorrect: it will *build*, but it will not *execute*. So, you *depend* on it. In a sense, with import you're stating dependency in your sources. True. This is the reason why this legal route-around will not work against GPL, but only against LGPL. Now, if we use reflection, we can do Class c = Class.forName(LGPLObject); Object o = c.newInstance(); Method doSomething = c.getMethod(doSomething); doSomething.invoke(); which compiles even without having the LGPL library in your classpath. In legal term, again, your program will *behave differently* if a class named LGPLObject exists in your runtime environment and it happens to have a doSomething() public method. With dynamic loading you're not stating dependency, merely *acknowledging existence*. This accademic trick is done to prove there is a way to totally isolate the virality of LGPL in Java (at least, that's my personal opinion). I think it would be pretty hard to state that my program can be considered part of the LGPL-ed library if I call build it even if it's not even present on my disk. As the concept of derivative work is about something that extends or change a preexisting work, the second approach will probably skip it (specially if your program tests for the result of the snippet code and survives when the given class is not in the path). Exactly. I don't think that even reflection will stand in court if your program cannot perform its duty without the given library being there. I.E. fine when alternate services can perform a task, or for non-essential components of a project. Again, you are not taking into account that I working again the LGPL, not the GPL. There is no way to route around GPL. It was very carefully designed for that purpose. *BUT* programming java in this way is *FOOLISH*. Reflection was created to load classes programmatically at runtime, it was not created as a way to route around legal problems. +1 disclaimer type=IANAL ditto. Also, I am just a plain committer, so take it as just my opinion. /disclaimer let me state again that I consider this discussion pretty accademic (there is no way in the world I would suggest going down the reflection path to use a LGPL library... it would be much easier to rewrite the damn library or convince the author to change the licensing!) Still, I think we need to sort out all possible cases since they're going to come up again in the future. -- Stefano Mazzocchi [EMAIL PROTECTED] Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Stefano Mazzocchi wrote: Santiago Gala wrote: Stefano Mazzocchi wrote: Morgan Delagrange wrote: OK, Java-specific question. It seems likely that altering or inlining LGPL code pollutes the Apache license. Are you of the opinion that IMPORTING but not altering or distributing LGPL classes pollutes the Apache licecnse? And if so, can that be stated on the Wiki page? If LGPL code cannot be imported, it's pretty much useless in any capacity for Java projects. Bingo. The only *reasonable* way of dealing with LGLP stuff would be thru some for of reflection (reflection, for those who don't know, is the ability for java to connect to 'named' resources of classes. it's the most *dynamic* form of loading for a language which is already entirely dynamically loaded). So, suppose that LGPLObject is there somewhere in your classloading space (the classloader is the virtual machine subsystem that looks for your classes, classes being the objects and main units for java programs, all classes are always dynamically loaded) and this LGPLObject contains the method (java terminology for a function) called doSomething() If you use *regular* programming practices you have to do import LGPLObject; then LGPLObject o = new LGPLObject(); o.doSomething(); that will 1) ask the classloader to find that object 2) allocate memory for it 3) create the object 4) invoke the object method doSomething This means, mostly, for legal sakes that the LGPLObject *MUST* be in the classloading space during compilation time. In legal terms, your program will not build without a class named LGPLObject which has a public doSomething() method. Incorrect: it will *build*, but it will not *execute*. It will not build if the class is not in your classpath, it will execute and give an Exception if the class is not in your classpath. I'm speaking about *plain* import up here. So, you *depend* on it. In a sense, with import you're stating dependency in your sources. True. This is the reason why this legal route-around will not work against GPL, but only against LGPL. This dependency was stated for the plain import. Now, if we use reflection, we can do Class c = Class.forName(LGPLObject); Object o = c.newInstance(); Method doSomething = c.getMethod(doSomething); doSomething.invoke(); which compiles even without having the LGPL library in your classpath. In legal term, again, your program will *behave differently* if a class named LGPLObject exists in your runtime environment and it happens to have a doSomething() public method. With dynamic loading you're not stating dependency, merely *acknowledging existence*. This accademic trick is done to prove there is a way to totally isolate the virality of LGPL in Java (at least, that's my personal opinion). I think it would be pretty hard to state that my program can be considered part of the LGPL-ed library if I call build it even if it's not even present on my disk. I'm not sure about this one. You can write a work that is a derivative work from Vivaldi's Four Seasons from your memory, without having the score or a disk at home. As the concept of derivative work is about something that extends or change a preexisting work, the second approach will probably skip it (specially if your program tests for the result of the snippet code and survives when the given class is not in the path). Exactly. I don't think that even reflection will stand in court if your program cannot perform its duty without the given library being there. I.E. fine when alternate services can perform a task, or for non-essential components of a project. Again, you are not taking into account that I working again the LGPL, not the GPL. There is no way to route around GPL. It was very carefully designed for that purpose. True. I stand corrected. But, as Andy has just pointed in jakarta-general: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=14335 I'm not sure a plain import will break the LGPL rules. Dynamic loading of a full GPL thing (not essential) for use in a project, I'm not sure will raise any issue, and it is in a sense routing around it. I write this from a linux machine, and I'm not obliged to make GPL all of my works, as Andy pointed to me privately yesterdat. Though most of the things C stuff I compile does #include linux/something.h to build. And the source of all of these includes is in the kernel, which is GPL. I can use GNU-make to build, even to build propietary code, I think. What I cannot do is to modify GNU-make and keep modifications propietary. But see below. *BUT* programming java in this way is *FOOLISH*. Reflection was created to load classes programmatically at runtime, it was not created as a way to route around legal problems. +1 disclaimer type=IANAL ditto. Also, I am just a plain committer, so take it as just my opinion. /disclaimer The disclaimer applies doubly here. let me state again that I consider this discussion
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Morgan Delagrange wrote: OK, Java-specific question. It seems likely that altering or inlining LGPL code pollutes the Apache license. Are you of the opinion that IMPORTING but not altering or distributing LGPL classes pollutes the Apache licecnse? And if so, can that be stated on the Wiki page? If LGPL code cannot be imported, it's pretty much useless in any capacity for Java projects. Refer to Roy's messages of yesterday. Importing is enough to disallow the code from use within ASF code. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=1419 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=1429 Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Ken, can we get this on the Wiki page to protect feeble-minded folks like me? http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing I had just finished doing that. I hope that I got them right. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Conor MacNeill [EMAIL PROTECTED] writes: Morgan Delagrange wrote: OK, Java-specific question. It seems likely that altering or inlining LGPL code pollutes the Apache license. Are you of the opinion that IMPORTING but not altering or distributing LGPL classes pollutes the Apache licecnse? And if so, can that be stated on the Wiki page? If LGPL code cannot be imported, it's pretty much useless in any capacity for Java projects. Refer to Roy's messages of yesterday. Importing is enough to disallow the code from use within ASF code. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=1419 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=1429 As I understand it, class loading the code via configuration files (e.g. _not_ referencing the (L)GPL'd code in our .java sources at all) would be okay. -- Daniel Rall dlr@finemaltcoding.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Morgan Delagrange [EMAIL PROTECTED] writes: Dang, I wish that archive was searchable. [wink, wink] Pier, the unix permissions on the Lucene index directory for community@apache.org don't allow writes by the unix user apache which Catalina is running as: [EMAIL PROTECTED]:dlr$ ls -lad /opt/tomcat/webapps/eyebrowse/index/apche.org/community drwxr-sr-x 2 root apache 1536 Jan 30 12:10 /opt/tomcat/webapps/eyebrowse/index/apche.org/community/ nagoya gave me the finger when I tried to correct them: [EMAIL PROTECTED]:dlr$ chmod -R g+w /opt/tomcat/webapps/eyebrowse/index/apche.org/community chmod: WARNING: can't change /opt/tomcat/webapps/eyebrowse/index/apche.org/community Calvary? -- Daniel Rall dlr@finemaltcoding.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
--On Wednesday, February 05, 2003 21:25:47 -0800 Daniel Rall dlr@finemaltcoding.com wrote: can't change /opt/tomcat/webapps/eyebrowse/index/apche.org/community Man, I hope our search engine doesn't index www.apche.org. I actually encountered this site at ApacheCon while Brian and David were running etherpeg. ;-) -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Justin Erenkrantz [EMAIL PROTECTED] writes: --On Wednesday, February 05, 2003 21:25:47 -0800 Daniel Rall dlr@finemaltcoding.com wrote: can't change /opt/tomcat/webapps/eyebrowse/index/apche.org/community Man, I hope our search engine doesn't index www.apche.org. Heh, me too. I actually encountered this site at ApacheCon while Brian and David were running etherpeg. ;-) -- justin So the Lucene index directory really was set to apche.org in the database. I copied the Lucene meta data files over and ran a quick SQL update against the db to activate the apache.org version. Because of the unix permissions on that other directory, Lucene couldn't write to it and I can't remove it. Might want to nuke when you can steal a moment. -- Daniel Rall dlr@finemaltcoding.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
