Re: Hibernate question
Niclas Hedhman wrote: The FSF agenda is to drive all development into OSS, by forcing the choice of "economical OSS benefits" vs "costly in-house development". Wrong. This is the OSI agenda, not the FSF one. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Hibernate question
Dirk-Willem van Gulik wrote: On Wed, 11 Aug 2004, Ugo Cei wrote: Stupid and counter to what they have publicly stated many times, that their own interpretation of the LGPL is that it is not viral. However over the years we've not managed to get a public statement (or an updated L-GPL license) which makes clear that 'import foo' in java should be considered similar to the *.h/linking of C. The general drift seems to be 'do not use the lesser GPL, please use the real GPL' and leave it ambigious. Ugo is referring to the Hibernate guys, not the FSF people. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Hibernate question
Ugo Cei wrote: Il giorno 11/ago/04, alle 01:37, Stefano Mazzocchi ha scritto: Are they in trouble or are we wrong? Nobody is in trouble (unless the hibernate people go after them, which would be a pretty stupid thing to do anyway) Stupid and counter to what they have publicly stated many times, that their own interpretation of the LGPL is that it is not viral. For the record: interpretation with which I personally agree. If I redistribute a jar file that has the exact same MD5 of the one they distribute I am *not* modifying the library, even if my code extends one of their classes. But the FSF (who doesn't like the LGPL but the cat is out of the bag) does not want to make such a public statement. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Hibernate question
On Aug 11, 2004, at 5:18 AM, Gianugo Rabellino wrote: > * aopalliance/aopalliance.jar > - AOP Alliance 1.0 (http://aopalliance.sourceforge.net) Originally released LGPL, I chatted with Rod Johnson about it several months ago and he said he was changing the AOP Alliance license to BSD or ASL. Haven't followed up. -Brian
Re: Hibernate question
Ugo Cei wrote:
P.S.: this message imports classes from a library that is covered by
the LGPL, so it's probably safe to assume that it is covered by the
LGPL as well. If you are redistributing it or quoting it, make sure
that you comply with the terms of the license as laid out in
http://www.gnu.org/copyleft/lesser.html
Ugo, what have you done?!?!?!?
Since we can find links that go from http://www.apache.org/ to the mail
archives and thus to your post, the whole ASF code base is now LGPL'ed.
Aaargh!!!
;-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: Hibernate question
Ugo Cei <[EMAIL PROTECTED]> writers: > > Il giorno 11/ago/04, alle 11:18, Andrew Thornton ha scritto: > > > I'm really not sure how Spring decides which ORM backend is being > > used. But I would be very surprised if it did it in some hardcoded > > way. > > src/org/springframework/orm/hibernate/HibernateTemplate.java: > > import net.sf.hibernate.Criteria; > import net.sf.hibernate.FlushMode; > import net.sf.hibernate.HibernateException; > ... > > If you're not using the HibernateTemplate class in your code, > all this > is never loaded. If you're using it, you need to have > hibernate.jar in > your classpath. > > Ugo > > P.S.: this message imports classes from a library that is covered by > the LGPL, so it's probably safe to assume that it is covered by the > LGPL as well. If you are redistributing it or quoting it, make sure > that you comply with the terms of the license as laid out in > http://www.gnu.org/copyleft/lesser.html > > ;-) (just in case) > Hah! Strangely enough my mail reader didn't complain about the fact that it couldn't find the hibernate classes even though they are not present on my machine
Re: Hibernate question
On Aug 11, 2004, at 11:48 AM, Steven Noels wrote: On 11 Aug 2004, at 11:18, Gianugo Rabellino wrote: On Aug 11, 2004, at 10:53 AM, Steven Noels wrote: So yes, we must remove Hibernate-related code from what we redistribute from Spring. I'm not even sure this is enough. It is from a purely legal POV, but it might be confusing for users: unless we clearly state that Apache Cocoon is protected by the AL 2.0 if and only if you use the shipped version of the Spring jars, not the official ones, there is a risk of someone redistributing Cocoon with different/updated/custom built/whatever Spring jars which could be viral. We can only assure the legal sanity and license condition consistency of our own ASF releases. If people add stuff to that afterwards, they'll have to work out for themselves whether the AL2 still applies. True, but the original proposal was to mangle ourselves the distributed jar fil of spring, stripping away hibernate stuff. Not exactly what I would define as making user's life easy... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
Re: [OT] thought on license discussions (was: Re: Hibernate question)
Steven Noels dijo: > On 09 Aug 2004, at 21:53, Leszek Gawron wrote: > >> Let's imagine we base cocoon on spring. There was a discussion about >> including hibernate in cocoon and it failed (licensing). Spring being >> ASL 2.0 ships with hibernate library, even if not - it contains code >> that was compiled against hibernate interfaces. Wouldn't this be an >> issue? > > Before anyone makes the obligatory remark license discussions are > boring, let's just not forget what Debian has been doing in this field > since many years - http://lists.debian.org/debian-legal/ > > Granted, the number of license discussions has been increasing over the > past year(s), but if they can cope, so should we. It is the crux of the > contract we provide to our users. A mail list for that is good idea, I think a better idea is to state clear in a web page what kind of licenses are valid for us -> this will avoid further discussions And for the LGPL case I prefer to be safe than sorry. Best Regards, Antonio Gallardo.
Re: Hibernate question
Il giorno 11/ago/04, alle 11:48, Steven Noels ha scritto: I reckon we won't be packaging the full Spring dist into Cocoon, no? Just to be on the safe side, I removed spring-aop.jar and aopalliance.jar from src/branches/butterfly/lib, since they are not used at the moment. This leaves spring-core, spring-context and spring-web. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
[OT] thought on license discussions (was: Re: Hibernate question)
On 09 Aug 2004, at 21:53, Leszek Gawron wrote: Let's imagine we base cocoon on spring. There was a discussion about including hibernate in cocoon and it failed (licensing). Spring being ASL 2.0 ships with hibernate library, even if not - it contains code that was compiled against hibernate interfaces. Wouldn't this be an issue? Before anyone makes the obligatory remark license discussions are boring, let's just not forget what Debian has been doing in this field since many years - http://lists.debian.org/debian-legal/ Granted, the number of license discussions has been increasing over the past year(s), but if they can cope, so should we. It is the crux of the contract we provide to our users. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Hibernate question
On 11 Aug 2004, at 11:18, Gianugo Rabellino wrote: On Aug 11, 2004, at 10:53 AM, Steven Noels wrote: So yes, we must remove Hibernate-related code from what we redistribute from Spring. I'm not even sure this is enough. It is from a purely legal POV, but it might be confusing for users: unless we clearly state that Apache Cocoon is protected by the AL 2.0 if and only if you use the shipped version of the Spring jars, not the official ones, there is a risk of someone redistributing Cocoon with different/updated/custom built/whatever Spring jars which could be viral. We can only assure the legal sanity and license condition consistency of our own ASF releases. If people add stuff to that afterwards, they'll have to work out for themselves whether the AL2 still applies. With all this in mind, I have an hard time defining Spring as a safe bet licensing wise. I reckon we won't be packaging the full Spring dist into Cocoon, no? -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Hibernate question
Gianugo Rabellino wrote:
On Aug 11, 2004, at 10:53 AM, Steven Noels wrote:
So yes, we must remove Hibernate-related code from what we
redistribute from Spring.
I'm not even sure this is enough. It is from a purely legal POV, but
it might be confusing for users: unless we clearly state that Apache
Cocoon is protected by the AL 2.0 if and only if you use the shipped
version of the Spring jars, not the official ones, there is a risk of
someone redistributing Cocoon with different/updated/custom
built/whatever Spring jars which could be viral.
OTOH, I find strange that this slipped away:
> This is the readme file from spring lib directory:
[...]
> * aopalliance/aopalliance.jar
> - AOP Alliance 1.0 (http://aopalliance.sourceforge.net)
Couldn't find license. Public Domain?
... a bunch of J2EE files, and...
> * jboss/jboss-common-jdbc-wrapper.jar
> - JBoss connection pool classes (http://www.jboss.org)
*Dangerous* stuff. Definitely viral.
With all this in mind, I have an hard time defining Spring as a safe
bet licensing wise.
There are parts that may be subject to LGPL virality, but 99% of Spring
doesn't rely on LGPL'ed libraries.
So if we ever want to include Spring in an ASF repository, we could ask
the Spring folks to make separate jars for those files whose licensing
status could be suspicious, and not include them on the repository.
That wouldn't remove much of the value of Spring, as one of its main
purposes is to cut strong dependencies with the actual ORM or Datasource
implementations used.
The license of AOPAlliance has to be clarified, though.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Hibernate question
Il giorno 11/ago/04, alle 11:18, Andrew Thornton ha scritto: I'm really not sure how Spring decides which ORM backend is being used. But I would be very surprised if it did it in some hardcoded way. src/org/springframework/orm/hibernate/HibernateTemplate.java: import net.sf.hibernate.Criteria; import net.sf.hibernate.FlushMode; import net.sf.hibernate.HibernateException; ... If you're not using the HibernateTemplate class in your code, all this is never loaded. If you're using it, you need to have hibernate.jar in your classpath. Ugo P.S.: this message imports classes from a library that is covered by the LGPL, so it's probably safe to assume that it is covered by the LGPL as well. If you are redistributing it or quoting it, make sure that you comply with the terms of the license as laid out in http://www.gnu.org/copyleft/lesser.html ;-) (just in case) -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Hibernate question
Il giorno 11/ago/04, alle 11:18, Gianugo Rabellino ha scritto: I'm not even sure this is enough. It is from a purely legal POV, but it might be confusing for users: unless we clearly state that Apache Cocoon is protected by the AL 2.0 if and only if you use the shipped version of the Spring jars, not the official ones, there is a risk of someone redistributing Cocoon with different/updated/custom built/whatever Spring jars which could be viral. If someone downloads whatever product from somewhere else than an official ASF repository, isn't it *their* fscking problem to make sure they are complying with whatever license the things they are downloading are covered by? If I were to provide a version of Cocoon on my FTP server, bundled with a closed-source or GPL version of JMS and JavaMail libraries, just because I want my customers to be able to use these features without having to replace the mocks we provide with a real impl., wouldn't the ASF have the same problem, assuming it was an ASF problem to begin with? Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Hibernate question
Dirk-Willem van Gulik wrote: On Wed, 11 Aug 2004, Steven Noels wrote: ASF codebase, regardless of what the Hibernate folks state themselves. Unelss they donate a second version of the code under a Software grant and ongoing CLA - but i doubt that it would ever be clean enough for incubation without that whole community going for it. Shouldn't we be asking Spring to check this situation out? If the classes that are tainted can be separated out in to a separate jar, and are only referred to by class name parametrically then that jar can be relicensed as LGPL and the LGPL'ness can be contained. I'm really not sure how Spring decides which ORM backend is being used. But I would be very surprised if it did it in some hardcoded way. andy -- [EMAIL PROTECTED] / [EMAIL PROTECTED] "Absinthe makes the hog Jane Fonda"
Re: Hibernate question
On Aug 11, 2004, at 10:53 AM, Steven Noels wrote: So yes, we must remove Hibernate-related code from what we redistribute from Spring. I'm not even sure this is enough. It is from a purely legal POV, but it might be confusing for users: unless we clearly state that Apache Cocoon is protected by the AL 2.0 if and only if you use the shipped version of the Spring jars, not the official ones, there is a risk of someone redistributing Cocoon with different/updated/custom built/whatever Spring jars which could be viral. OTOH, I find strange that this slipped away: > This is the readme file from spring lib directory: [...] > * aopalliance/aopalliance.jar > - AOP Alliance 1.0 (http://aopalliance.sourceforge.net) Couldn't find license. Public Domain? ... a bunch of J2EE files, and... > * jboss/jboss-common-jdbc-wrapper.jar > - JBoss connection pool classes (http://www.jboss.org) *Dangerous* stuff. Definitely viral. With all this in mind, I have an hard time defining Spring as a safe bet licensing wise. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
Re: Hibernate question
On Wednesday 11 August 2004 17:03, Niclas Hedhman wrote: > Somehow I trust the FSF legal counsel more than a set of developers trying > to interpret the fairly complex LGPL text. Which, btw, happens to co-incide with the ASF legal counsel's view as well. -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+
Re: Hibernate question
On Wednesday 11 August 2004 16:16, Sylvain Wallez wrote: > Ugo Cei wrote: > > Il giorno 11/ago/04, alle 01:37, Stefano Mazzocchi ha scritto: > >>> Are they in trouble or are we wrong? > >> > >> Nobody is in trouble (unless the hibernate people go after them, > >> which would be a pretty stupid thing to do anyway) > > > > Stupid and counter to what they have publicly stated many times, that > > their own interpretation of the LGPL is that it is not viral. > > For interested folks, this is written here: > http://www.hibernate.org/196.html Unfortunately, it is not for them to decide. It will be the courts' job, and any big-shot lawyer suing on their behalf. Somehow I trust the FSF legal counsel more than a set of developers trying to interpret the fairly complex LGPL text. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+
Re: Hibernate question
On 11 Aug 2004, at 10:47, Dirk-Willem van Gulik wrote: On Wed, 11 Aug 2004, Steven Noels wrote: ASF codebase, regardless of what the Hibernate folks state themselves. Unelss they donate a second version of the code under a Software grant and ongoing CLA - but i doubt that it would ever be clean enough for incubation without that whole community going for it. Yep. Let's dream on! ;-) -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Hibernate question
On Wed, 11 Aug 2004, Steven Noels wrote: > ASF codebase, regardless of what the Hibernate folks state themselves. Unelss they donate a second version of the code under a Software grant and ongoing CLA - but i doubt that it would ever be clean enough for incubation without that whole community going for it. Dw.
Re: Hibernate question
On Wednesday 11 August 2004 16:45, Ugo Cei wrote: > Il giorno 11/ago/04, alle 10:34, Niclas Hedhman ha scritto: > > Probability. One could wonder though, is Spring a trust-worthy liason, > > legality-wise? > > Are you running any of your applications on Linux? is Linux a > trust-worthy liason, legality-wise, in light of the SCO claims? _I_ don't have any 'code dependency' on Linux, and IMHO the SCO issue is different. Any developer can be sued by any other developer for patent and copyright infringements. This case is that hypothetically, if IBM builds a commercial product with Hibernate in there somewhere, Microsoft can (AFAIU) sue IBM on behalf of the Hibernate folks, even though no Microsoft code/copyright/patent is involved. Absurd? Yes of course, but possible. > If you want to be really paranoid, you can start developing everything > in-house, but where do you stop? The FSF agenda is to drive all development into OSS, by forcing the choice of "economical OSS benefits" vs "costly in-house development". And IMO, they seems to be doing a pretty good job at that. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+
Re: Hibernate question
On 11 Aug 2004, at 10:34, Niclas Hedhman wrote: IAANAL, I think that Hibernate may be violating the LGPL by assigning their interpretation. LGPLing your product implies certain things, and the FSF have been very elaborate in their wording (so that you and I don't really understand it) to make sure that, individual projects don't assign their own interpretation What could happen is a chain of legal nightmare, where someone brings Hibernate, Spring and Cocoon into court because CommercialA is using Cocoon and being sued by its competitor CommercialB. Even if Hibernate, Spring and Cocoon are not directly affected by such a case, it would damage ASF permanently, as the foundation is no longer considered 'clean'. I'm not a fan of Doom scenarios, but given the fact that JBoss, Inc. owns Hibernate to quite some extent, and that they are known for carefully watching our steps, I wouldn't want to give a legal/PR poison pill to them by including any Hibernate/LGPL code or reference in an ASF codebase, regardless of what the Hibernate folks state themselves. So yes, we must remove Hibernate-related code from what we redistribute from Spring. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Hibernate question
Il giorno 11/ago/04, alle 10:34, Niclas Hedhman ha scritto: Probability. One could wonder though, is Spring a trust-worthy liason, legality-wise? Are you running any of your applications on Linux? is Linux a trust-worthy liason, legality-wise, in light of the SCO claims? If you want to be really paranoid, you can start developing everything in-house, but where do you stop? Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Hibernate question
On Wednesday 11 August 2004 16:09, Ugo Cei wrote: > I'm aware of this. What I meant is that the Hibernate guys (and not the > FSF) have publicly stated that their own interpretation of the license > they have attached to their own code is that you can use it from a > project that has a different license (even a closed-source one) and not > be forced to distribute your own code under the (L)GPL. > > It would be hard, I think, to state the opposite in a court, but IANAL > ;-) IAANAL, I think that Hibernate may be violating the LGPL by assigning their interpretation. LGPLing your product implies certain things, and the FSF have been very elaborate in their wording (so that you and I don't really understand it) to make sure that, individual projects don't assign their own interpretation and that, IIUIC, anyone can act on behalf of the copyright holder. > In any case, what we are discussing is not importing or even > distributing Hibernate code, but importing (and possibly distributing) > Spring code which is contained in a JAR file that contains other > classes that import Hibernate classes, even if we don't use the former > (Spring) classes at all. It would be pretty hard to say that Cocoon > becomes a derivative work of Hibernate because of that. But then again, > IANAL. What could happen is a chain of legal nightmare, where someone brings Hibernate, Spring and Cocoon into court because CommercialA is using Cocoon and being sued by its competitor CommercialB. Even if Hibernate, Spring and Cocoon are not directly affected by such a case, it would damage ASF permanently, as the foundation is no longer considered 'clean'. > And if we really want to cover our asses against this possibility, we > can always strip the offending classes from the spring-orm.jar archive, > since we wouldn't be depending on them at all. Probability. One could wonder though, is Spring a trust-worthy liason, legality-wise? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+
Re: Hibernate question
Ugo Cei wrote:
Il giorno 11/ago/04, alle 01:37, Stefano Mazzocchi ha scritto:
Are they in trouble or are we wrong?
Nobody is in trouble (unless the hibernate people go after them,
which would be a pretty stupid thing to do anyway)
Stupid and counter to what they have publicly stated many times, that
their own interpretation of the LGPL is that it is not viral.
For interested folks, this is written here:
http://www.hibernate.org/196.html
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Hibernate question
Il giorno 11/ago/04, alle 09:41, Dirk-Willem van Gulik ha scritto: On Wed, 11 Aug 2004, Ugo Cei wrote: Stupid and counter to what they have publicly stated many times, that their own interpretation of the LGPL is that it is not viral. However over the years we've not managed to get a public statement (or an updated L-GPL license) which makes clear that 'import foo' in java should be considered similar to the *.h/linking of C. I'm aware of this. What I meant is that the Hibernate guys (and not the FSF) have publicly stated that their own interpretation of the license they have attached to their own code is that you can use it from a project that has a different license (even a closed-source one) and not be forced to distribute your own code under the (L)GPL. It would be hard, I think, to state the opposite in a court, but IANAL ;-) In any case, what we are discussing is not importing or even distributing Hibernate code, but importing (and possibly distributing) Spring code which is contained in a JAR file that contains other classes that import Hibernate classes, even if we don't use the former (Spring) classes at all. It would be pretty hard to say that Cocoon becomes a derivative work of Hibernate because of that. But then again, IANAL. And if we really want to cover our asses against this possibility, we can always strip the offending classes from the spring-orm.jar archive, since we wouldn't be depending on them at all. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Hibernate question
On Wed, 11 Aug 2004, Ugo Cei wrote: > Stupid and counter to what they have publicly stated many times, that > their own interpretation of the LGPL is that it is not viral. However over the years we've not managed to get a public statement (or an updated L-GPL license) which makes clear that 'import foo' in java should be considered similar to the *.h/linking of C. The general drift seems to be 'do not use the lesser GPL, please use the real GPL' and leave it ambigious. Dw
Re: Hibernate question
On Wed, 11 Aug 2004, Leszek Gawron wrote: > I am suprised of one fact: how can Spring be distributed with ASL 2.0 Note that at this time the stance of the ASF is that the LGPL should be considered tainting when used with the 'import' of java code until such point that the FSF publicly states that java 'import' is seen as 'linking' in C currently is or some form of precedence. But without that stay well clear of it. Yes - this is a tradeoff. What we are really doing is protecting the -existing- code base at the expense of a certain level of community dynamics, features and functionaly. This is not a black or white choise (esp. as most people personally blieve/guess that the FSF will eventually admit/see it as linking) but a self imposed line in the ground. In general you will always find some tension between the dev@ lists and the members@/board@ lists; the first will want to go forward and consider new things; the latter will do their utmost to be a good steward of already existing code. Balance is good :-) Note that this position may change over time; either due to the FSF finally giving answers or due to events in the community. Dw
Re: Hibernate question
Il giorno 11/ago/04, alle 01:37, Stefano Mazzocchi ha scritto: Are they in trouble or are we wrong? Nobody is in trouble (unless the hibernate people go after them, which would be a pretty stupid thing to do anyway) Stupid and counter to what they have publicly stated many times, that their own interpretation of the LGPL is that it is not viral. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Hibernate question
Il giorno 11/ago/04, alle 01:37, Stefano Mazzocchi ha scritto: Are they in trouble or are we wrong? Nobody is in trouble (unless the hibernate people go after them, which would be a pretty stupid thing to do anyway) Stupid and counter to what they have publicly stated many times, that their own interpretation of the LGPL is that it is not viral. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Hibernate question
Leszek Gawron wrote: Stefano Mazzocchi wrote: Leszek Gawron wrote: Let's imagine we base cocoon on spring. There was a discussion about including hibernate in cocoon and it failed (licensing). Spring being ASL 2.0 ships with hibernate library, even if not - it contains code that was compiled against hibernate interfaces. Wouldn't this be an issue? Ouch. yes. Can you outline the dependencies more? Spring has a support for hibernate OOTB. There are 2 packages dependant on hibernate: org.springframework.orm.hibernate org.springframework.orm.hibernate.support The problem is that the distribution consists of : - either single spring.jar that contains all - or spring-XXX.jar where XXX is core, orm, aop and so on. you could drop whole spring-orm.jar but then you loose all support for any OR framework. I am suprised of one fact: how can Spring be distributed with ASL 2.0 license if it is compiled against LGPL code (and redistributes this code in compiled form also)? The ASF (well, some directors) believe that the LGPL is still viral for java code. This has never been tested in court, nor the FSF has publicly stated a clear opinion on the subject, so the ASF prefers to stay away from it. Personally, I don't think there any problem in LGPL dependencies. Are they in trouble or are we wrong? Nobody is in trouble (unless the hibernate people go after them, which would be a pretty stupid thing to do anyway) This is the readme file from spring lib directory: The following libraries are included in the Spring Framework distribution because they are required either for building the framework or for running the sample apps. Note that each of these libraries is subject to the respective license; check the respective project distribution/website before using any of them in your own applications. * ant/ant.jar - Ant 1.6.1 (http://ant.apache.org) - used to build the framework and the sample apps * aopalliance/aopalliance.jar - AOP Alliance 1.0 (http://aopalliance.sourceforge.net) - required for building the framework - required at runtime when using AOP functionality * axis/axis.jar, axis/saaj.jar, axis/wsdl.jar - Apache Axis 1.1 (http://ws.apache.org/axis) - required for running JPetStore * caucho/burlap-2.1.12.jar - Burlap 2.1.12 (http://www.caucho.com/burlap) - required for building the framework - required at runtime when Spring's Burlap remoting support * caucho/hessian-2.1.12.jar - Hessian 2.1.12 (http://www.caucho.com/hessian) - required for building the framework - required at runtime when Spring's Hessian remoting support * cglib/cglib-2.0.1.jar, cglib/asm.jar - CGLIB 2.0.1 with ObjectWeb ASM 1.4 (http://cglib.sourceforge.net) - required for building the framework - required at runtime when proxying full target classes via Spring AOP * cos/cos.jar - Jason Hunter's COS 05Nov02 (http://www.servlets.com/cos) - required for building the framework - required at runtime when using Spring's CosMultipartResolver or CosMailSender * dom4j/dom4j.jar - DOM4J 1.4 XML parser (http://dom4j.sourceforge.net) - required for running Petclinic (by Hibernate) * easymock/easymock.jar, easymock/easymockclassextension.jar - EasyMock 1.1 (http://www.easymock.org) - required for building the test suite * freemarker/freemarker.jar - FreeMarker 2.3 RC4 (http://www.freemarker.org) - required for building the framework - required at runtime when using Spring's FreeMarker support * hibernate/ehcache.jar - EHCache 0.6 (http://ehcache.sourceforge.net) - required for running Petclinic (by Hibernate) * hibernate/hibernate2.jar, hibernate/odmg.jar - Hibernate 2.1.3 (http://www.hibernate.org) - required for building the framework - required at runtime when using Spring's Hibernate support * hsqldb/hsqldb.jar - HSQLDB 1.7.1 (http://hsqldb.sourceforge.net) - required for running JPetStore and Petclinic * ibatis/ibatis-common.jar, ibatis/ibatis-sqlmap.jar, ibatis/ibatis-sqlmap-2.jar - iBATIS SQL Maps 1.3.1 and 2.0 RC5 (http://www.ibatis.com) - required for building the framework - required at runtime when using Spring's iBATIS SQL Maps support * itext/itext-1.02b.jar - iText PDF 1.02 (http://www.lowagie.com/itext) - required for building the framework - required at runtime when using Spring's AbstractPdfView * j2ee/activation.jar - JavaBeans Activation Framework 1.0.1 (http://java.sun.com/products/javabeans/glasgow/jaf.html) - required for building the framework - required at runtime when using Spring's JavaMailSender * j2ee/connector-api.jar - J2EE Connector Architecture 1.5 (http://java.sun.com/j2ee/connector) - required at runtime when using Hibernate's JCA Connector * j2ee/ejb.jar - Enterprise JavaBeans API 2.0 (http://java.sun.com/products/ejb) - required for building the framework - required at runtime when using Spring's EJB support * j2ee/jaxrpc.jar - JAX-RPC API 1.0 (http://java.sun.com/xml/jaxrpc) - required for building the framework - required at runtime when using Spring's JAX-RPC support * j2ee/jdbc2_0-stdext.jar - J
Re: Hibernate question
Stefano Mazzocchi wrote: Leszek Gawron wrote: Let's imagine we base cocoon on spring. There was a discussion about including hibernate in cocoon and it failed (licensing). Spring being ASL 2.0 ships with hibernate library, even if not - it contains code that was compiled against hibernate interfaces. Wouldn't this be an issue? Ouch. yes. Can you outline the dependencies more? Spring has a support for hibernate OOTB. There are 2 packages dependant on hibernate: org.springframework.orm.hibernate org.springframework.orm.hibernate.support The problem is that the distribution consists of : - either single spring.jar that contains all - or spring-XXX.jar where XXX is core, orm, aop and so on. you could drop whole spring-orm.jar but then you loose all support for any OR framework. I am suprised of one fact: how can Spring be distributed with ASL 2.0 license if it is compiled against LGPL code (and redistributes this code in compiled form also)? Are they in trouble or are we wrong? This is the readme file from spring lib directory: The following libraries are included in the Spring Framework distribution because they are required either for building the framework or for running the sample apps. Note that each of these libraries is subject to the respective license; check the respective project distribution/website before using any of them in your own applications. * ant/ant.jar - Ant 1.6.1 (http://ant.apache.org) - used to build the framework and the sample apps * aopalliance/aopalliance.jar - AOP Alliance 1.0 (http://aopalliance.sourceforge.net) - required for building the framework - required at runtime when using AOP functionality * axis/axis.jar, axis/saaj.jar, axis/wsdl.jar - Apache Axis 1.1 (http://ws.apache.org/axis) - required for running JPetStore * caucho/burlap-2.1.12.jar - Burlap 2.1.12 (http://www.caucho.com/burlap) - required for building the framework - required at runtime when Spring's Burlap remoting support * caucho/hessian-2.1.12.jar - Hessian 2.1.12 (http://www.caucho.com/hessian) - required for building the framework - required at runtime when Spring's Hessian remoting support * cglib/cglib-2.0.1.jar, cglib/asm.jar - CGLIB 2.0.1 with ObjectWeb ASM 1.4 (http://cglib.sourceforge.net) - required for building the framework - required at runtime when proxying full target classes via Spring AOP * cos/cos.jar - Jason Hunter's COS 05Nov02 (http://www.servlets.com/cos) - required for building the framework - required at runtime when using Spring's CosMultipartResolver or CosMailSender * dom4j/dom4j.jar - DOM4J 1.4 XML parser (http://dom4j.sourceforge.net) - required for running Petclinic (by Hibernate) * easymock/easymock.jar, easymock/easymockclassextension.jar - EasyMock 1.1 (http://www.easymock.org) - required for building the test suite * freemarker/freemarker.jar - FreeMarker 2.3 RC4 (http://www.freemarker.org) - required for building the framework - required at runtime when using Spring's FreeMarker support * hibernate/ehcache.jar - EHCache 0.6 (http://ehcache.sourceforge.net) - required for running Petclinic (by Hibernate) * hibernate/hibernate2.jar, hibernate/odmg.jar - Hibernate 2.1.3 (http://www.hibernate.org) - required for building the framework - required at runtime when using Spring's Hibernate support * hsqldb/hsqldb.jar - HSQLDB 1.7.1 (http://hsqldb.sourceforge.net) - required for running JPetStore and Petclinic * ibatis/ibatis-common.jar, ibatis/ibatis-sqlmap.jar, ibatis/ibatis-sqlmap-2.jar - iBATIS SQL Maps 1.3.1 and 2.0 RC5 (http://www.ibatis.com) - required for building the framework - required at runtime when using Spring's iBATIS SQL Maps support * itext/itext-1.02b.jar - iText PDF 1.02 (http://www.lowagie.com/itext) - required for building the framework - required at runtime when using Spring's AbstractPdfView * j2ee/activation.jar - JavaBeans Activation Framework 1.0.1 (http://java.sun.com/products/javabeans/glasgow/jaf.html) - required for building the framework - required at runtime when using Spring's JavaMailSender * j2ee/connector-api.jar - J2EE Connector Architecture 1.5 (http://java.sun.com/j2ee/connector) - required at runtime when using Hibernate's JCA Connector * j2ee/ejb.jar - Enterprise JavaBeans API 2.0 (http://java.sun.com/products/ejb) - required for building the framework - required at runtime when using Spring's EJB support * j2ee/jaxrpc.jar - JAX-RPC API 1.0 (http://java.sun.com/xml/jaxrpc) - required for building the framework - required at runtime when using Spring's JAX-RPC support * j2ee/jdbc2_0-stdext.jar - JDBC 2.0 Standard Extensions (http://java.sun.com/products/jdbc) - required for building the framework on J2SE 1.3 - required at runtime when using Spring's JDBC support on J2SE 1.3 * j2ee/jms.jar - Java Message Service API 1.0.2b (java.sun.com/products/jms) - required for building the framework - required at runtime when using Spring's AbstractJmsMessageDrivenBean * j2ee/jstl.jar - JSP Standard Tag Library API 1.0 (http://java.su
Re: Hibernate question
Leszek Gawron wrote: Let's imagine we base cocoon on spring. There was a discussion about including hibernate in cocoon and it failed (licensing). Spring being ASL 2.0 ships with hibernate library, even if not - it contains code that was compiled against hibernate interfaces. Wouldn't this be an issue? Ouch. yes. Can you outline the dependencies more? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Hibernate question
Il giorno 10/ago/04, alle 04:14, Vadim Gritsenko ha scritto: even if not - it contains code that was compiled against hibernate interfaces. Wouldn't this be an issue? It would not be an issue as long as classes compiled against Hibernate are not included into Spring JAR which is (in this imaginary situation) used by Cocoon. Anything else becomes grey area, and as such, most probably should be avoided all together. Spring's ORM support is distributed as a separate jar (spring-orm.jar) and is not needed to use the rest of spring (core, mvc, AOP, etc.). This should cover our asses in case we bundle Spring with Cocoon. OTOH, If you are using Hibernate you are agreeing to the terms of the LGPL anyway, but if you want to use, say, OJB, which is supported in Spring 1.1, you'd have to include spring-orm.jar in your application and that includes also code compiled against Hibernate's interfaces. Would that force you to distribute your code under the (L)GPL? I don't know, but in any case you could always strip all Hibernate-dependent classes from the jar and keep only the OJB-dependent ones. Anyway, IANAL but this is getting painful :( Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Hibernate question
Leszek Gawron wrote: Let's imagine we base cocoon on spring. There was a discussion about including hibernate in cocoon and it failed (licensing). Spring being ASL 2.0 ships with hibernate library If it does, it means you have to agree to two licenses in order to use Spring: ASL 2.0 and LGPL (Hibernate is LGPL, right?). even if not - it contains code that was compiled against hibernate interfaces. Wouldn't this be an issue? It would not be an issue as long as classes compiled against Hibernate are not included into Spring JAR which is (in this imaginary situation) used by Cocoon. Anything else becomes grey area, and as such, most probably should be avoided all together. Vadim
