Dan,
as usual right on the money (sort of) and right on time...
I was thinking about this, this morning on a completely unrelated
example, and created the board mailing list just so that we could
discuss it...
read my comments below.
Dan OConnor wrote:
> > 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."
I think there are 2 things being discussed
1- The implications of BSD style license plugins in jBoss redistribution
________________________________________________________________________
Regarding 1 I think we might side step this, and I think there is no
incompatibility at all.
Our license covers "jboss" code, we redistribute "plugin" code (ala Bull
today, maybe castor tomorrow) and comply to the terms of their licenses
in redistribution but our license doesn't cover their stuff.
If *you* (our user, Startup comp) want to redistribute the whole thing,
you must comply to our license in redistribution of our stuff (provide
our source) and comply to the 3rd party license of the stuff you are
redistributing (Exolab requires "credit").
The software is licensed under the terms of their respective owners. In
other words, there is no need for us to add a "NOTE" that explicitely
modifies the understanding of the GPL since we are NOT re-licensing the
software of third parties merely redistributing it. In short the 2
licenses do not apply to the same body of code and I by definition we
have a non issue here.
2- The implications of GPL based containers to the plugins writing and
redistribution.
______________________________________________________________________________________
This is the real point we need to address. I think that in the same way
we added a "NOTE" for bean and application developers we should *maybe*
add a "NOTE" explaining how we view GPL infectation of plugins.
The GPL reasoning and formulation is simple : if your plugin is a
derivative work of ours then it needs to be GPL. If your work is not a
derivative work of ours then no. TOPLink is not a derivative work of
ours (clearly) and Castor is not either (clearly). Their stuff should
not be GPL as per the GPL wording... however.
So how do we put this in CLEAR to avoir questions, just like LInux and
jBoss 2.0 do for applications?
In case of "beans and applications" running on top of jBoss we have a
clear definition of "derivative work", e.g. J2EE interface calls do not
qualify. Do we have the same thing with plugins? Clearly not J2EE
since J2EE doesn't define plugins (maybe some in EJB2.0 but still). So
defining non-derivative work as J2EE is clearly silly.
Still we will get 1001 "what about plugins" if we don't clearly state
the interpretation of the GPL.
Here the "import rule" is the closest I can think of. As we discussed
previously there can be abuses i.e. dynamic classes and calls designed
to bypass this rule but I think this will be the exception. I don't
want to design our rules based on the exception (design by exception is
the worst software philosophy and the reason of all bureaucratic
kafkaianism) and make a too restrictive rule just to weed out the few
bad elements that will abuse us anyway, I would rather make sure that
95% of people understand and apply in good faith the simple "import
rule" for the plugins.
If a plugin "imports" GPL code it is GPL, if not, not. Simple right?
So "glue" code that we would provide as part of the jBoss project needs
to be GPL, but not the TOPLinks of the world. We still keep all the
org.jboss extensions GPL. A bit like saying in linux: the drivers are
GPL the plugin is not.
Again GPL only states "derivative work" and intuitively TOPLink is not
derivative, but I think we gain by stating clearly what we understand by
"derivative work" for plugins the way we did for beans and
applications. And the way Linux does.
> 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?)
Regardless of the licenses it is the GPL that is to be looked at.
Again we do not change their licenses and comply with their terms.
This is a non-issue.
> 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.
Absolutely!!!! even though their license doesn't require it (it is
actually designed to be closed in the container features at some point
<beware/>, unlike GPL stuff) I think we should keep the real spirit of
the GPL which is "give back your kernel code"
Let's take some more input and move to board for that...
regards
marc
>
> -Dan
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
----------------------------------------------------------------
Visit Telkel at JavaOne(SM), Sun's 2000 Worldwide Java Developer
Conference(SM)
June 5-9, 2000 - Moscone Center - San Francisco
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
