> Sorry to bring the sad news, but that's just not the whole story.
> The parts of Linux that matters for applications are _not_ using
> the GPL as is. For example the GNU C library is using the LGPL
> and the kernel license file have the following text prepended
> to the GPL:
>
> <quote>
> NOTE! This copyright does *not* cover user programs that use kernel
> services by normal system calls - this is merely considered normal use
> of the kernel, and does *not* fall under the heading of "derived work".
> Also note ...[snip]
> Linus Torvalds
> </quote>
well, Thanks Mats
the note does explicitely say that "normal use of the kernel by
programs" is *not* under "derived work".
which is exactly equivalent to "normal use (j2ee calls) of the container
by beans" is *not* under "derived work".
YOUR BEANS ARE NOT DERIVED WORK OF JBOSS. And a simple way of putting
it is that J2EE calls do not make your beans fall under derived work or
jBoss.
Actually this is sort of more powerful than the import rule since it
covers the case of dynamic calls as well (bypassing the import). The
import is simple and simple is good but saying "J2EE calls" is as simple
and clear.
If what you are suggesting is that we include such a "NOTE", as an
explicit *interpretation* of the GPL then I agree. They are just
explicitely saying "we are tired of hearing the same question over and
over and programs that do normal system calls do *not* fall under
derived work".
In our case it is even simpler. We have the j2ee API that makes sure
that your work is a "derived work" of SUN not ours. So we can clearly
define the notion of "normal use".
Finally the GNU C library comparison is simply off target, if we were to
ship an API definition a la gnuEJB then your work would be derived of
ours which is clearly what we are trying to avoid.
LET'S PUT THE BOARD TO WORK,
guys let's vote on a "prepend notification" of the GPL, a la Linux 2.0
so as to provide our interpretation of the GPL explicitely. We are
following their compenentization example as well as the license example.
regards
marc
> Making up rules like 'if you import ...' etc may sound fine,
> but as long as those rules aren't in the license text, they
> mean nothing. All that matters is what's in the license and
> ultimately how it is interpreted in a court if it ever goes
> that far. The license used for jBoss right now is the GPL
> only and nothing else, and its implications are rather clear
> if you just read it without any prior assumptions.
>
> Actually, the 'import' rule sounds like a good idea to me.
> Just adding it (or some variation of the text used by Linus)
> explicitly to the license text would do a great deal towards
> clearing things up.
>
> /mats
>
> Dan OConnor wrote:
>
> [...]
> You can consider an application to be beans+EJB container, if you
> want. Just like you can consider an application to be
> executable+operating system. But we don't, any more than the
> Linux community does. The "Web App" is the beans. The "Web
> OS" is the container.
>
> Can you tell me where this metaphor with Linux breaks down? Or
> if it doesn't, does Oracle have to open the code to its Linux port?
> [...]
>
> Thor Heinrichs-Wolpert wrote:
>
> [...]
> Agreed. But, we know for a fact the application on Linux fall outside of
> this. Yes the rely on common runtime libraries (Oracle on Linux for
> example) but they are independent of the GPL bits. EJB is a component spec,
> and the components are independent pieces which utilize services suplied by
> a container, much like applications are utilizing the services of a GPL'ed
> OS (Linux).
> [...]
>
> marc fleury wrote:
>
> [...]
> But stricly speaking *your* work is not based on *our* work, it does not
> even contain it, you never "import" GPL code.
> Your work does not contain our program. The work being discussed, your
> code, need not be GPL.
>
> That is a question that is fully settled in the Linux world, the package
> "Oracle 8i on Linux" contains Linux (GPL) and Oracle 8i (non-GPL).
> [...]
>
> marc fleury also wrote:
>
> [...]
> WE do not bring you anything as we implement it. GPL protects what is
> under the covers and that means the operating system itself. What we
> want is a "bubble" in which you are sure that all the community will see
> and share in the code. To provide a loophole in that bubble is of no
> interest to us (aka FreeBSD, LGPL). The propagation outside that bubble
> is non-existent, and Java makes that possible. A strict reading of the
> spec (definition of work = your work) and the precedent set by
> day-to-day usage of Linux should be a no-brainer... do you see the FSF
> (Free Software Foundation, author of the GPL and stuff) up in arms
> banging on Oracle for running on Linux? Did you ever hear their
> lawyers? no because the GPL doesn't cover Work as package/runtime but
> Work as code. Why our situation would be any different is beyond me.
>
> The really nice thing with Java is that we have a clear rule "if you
> import you're it, if not you are not". Jini is another case as it
> bypasses the imports altogether (bypasses the interfaces). All the
> reflection API poses a question, but we are not in that sphere... (you
> never reflect our classes). At least when you work on interfaces you
> have a clean definition and separation. Your beans import javax.ejb,
> javax.jndi, your work is a derivative of SUN's not ours and it is not
> reflexive. We both derivate from SUN we never knew each other before.
> GPL propagates down a tree of dependencies, not UP, so the "viral"
> nature is uni-directional.
> [...]
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
