On 20 May 00, at 13:46, Oleg Nitz wrote:
> Phan Anh Tran wrote:
> PAT> Yeah, I know this should go to the developer list, but I am not subscribed to
> PAT> that list, so..
>
> PAT> .Anyway, I looked at the CASTOR project the other way and I can't help but
> PAT> think that some of the stuff they are doing could be re-used for JBOSS. I
> PAT> figure that if CASTOR and JBOSS are using the same licenses (which I don't
> PAT> know) it should make sense to borrow each others code.
> Wrong, Castor has BSD-like license, jBoss is GPL-ed.
> However, I hope that it will be possible to use Castor with jBoss 2.0
> somehow or other: as J2EE connector or as alternative CMP engine, so
> that it will be "normal use", not infected by GPL.
>
> Best regards,
> Oleg
>
For the most part, BSD-licensed code may be used with GPL-licensed
code. The one exception to license compatibility is what the GNU website
calls the "obnoxious BSD advertising clause." The incompatibility arises
because the BSD license imposes a requirement that does not exist in the
GNU license: to include a phrase in all advertising material. The
requirement read like this:
"All advertising materials mentioning features or use of this software must
display the following acknowledgement" + acknowledgement.
The "modified" BSD license, that removes this phrase, is completely
compatible with GPL-licensed software and may be used within it.
The Exolab license, under which Castor falls, has a version of the BSD
license that falls somewhere between. What it says is that "Due credit
should be given to the ExoLab Project."
Technically, this makes the license incompatible with a GPL license
because it imposes an additional requirement on the software. My opinion
is that "due credit" is not an unreasonable burden, and if there were
substantial benefits to be had by incorporating software that was under the
Exolab license, we could probably vote to have a simple addendum to our
GPL license along the lines of: "The due credit text file must accompany
all distributions of this software."
That having been said, it should be possible to incorporate Castor into
JBoss via GPL plug-ins. We shouldn't need to add any import statements
to Castor code of JBoss-specific classes, so license compatibility shouldn't
be an issue. If it is, we should adjust the plug-in architecture. My
understanding of our goal is that any competent third-party object/relational
mapping tool should be compatible with JBoss, regardless of its license.
Not only should we be able to integrate Castor without changing our license
or violating theirs, but we should be able to do the same for TOPLink.
These are just my opinions; in the absense of a board vote, I wouldn't want
to tell the Object People to go ahead with their TOPLink integration.
However, I do feel like Castor integration is a safe bet, because of their
_nearly_ compatible license. If anyone wants to work on this, I'd say go
ahead. (Anyone else have a contradictory opinion about the license?)
In any case, if someone does work on this, please submit any
improvements to Castor back to ExoLab. This is only fair, even if their
license does not require it.
-Dan
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]