| but at the same time, you have a problem with the GPL being
|viral so you give exceptions for people to use JBoss. Instead, what you
|should do is probably be using the MPL license which will solve your needs
|without having to constantly grant exceptions to people.
???
what 'exceptions'? we n
read that passage).
YES it is possible to aggregate Apache+Tomcat (but isn't tomcat going to do
http as well as?;-), Avalon (F we need JMX man, come on the 77 board ;-)
Castor, Tyrex (cause assaf still kicks ass), PostgreSQL and jBOSS.
And yes!! it is possible to include GPL packages with non-
|> | but at the same time, you have a problem with the GPL being
|> |viral so you give exceptions for people to use JBoss. Instead, what you
|> |should do is probably be using the MPL license which will solve
|your needs
|> |without having to constantly grant exceptions to people.
|>
|> ???
|>
|>
|That is how you interpret it, not how RMS interprets it.
I have a license and the wording is clear.
What people say he said isn't the question.
|I cannot take Tomcat and combine it with JBoss and make a
|distribution of it
|that is available from Apache.org because JBoss is under a GPL license.
ok jon et al...
it is trivial that APL software is incompatible with GPL, since for APL
software to "contain, derive or modify" GPL software is not possible, we all
agree on that. Aggregation of it is OK per the GPL.
The point was and is on ordering of containment that I think is creating
confu
|The amazing thing here is that the APL 1.1 license is one of the least
|restrictive licenses out there and definitely much less
|restrictive than the
|GPL. So, we are asking to not go to a MORE restrictive license, but to a
|LESS restrictive license. How can that be a bad thing?
jon,
True! it i
s admins, consultants etc etc... i.e. a real
platform.
we can do it, we need your help, so let's do it... forget the rest, it is
not real.
Peace Love and Good Code,
marc
Marc Fleury, PhD
CTO, Telkel Inc.
k in distribution. Our distributions are GPL
kosher.
Please don't be afraid of it, and feel free to discuss it...
regards
marc
|-Original Message-
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Friday, October 27, 2000 10:10 PM
|To: jBoss Developer; [EMAIL PROTECTED];
|[EMAIL
no be careful 2b is about containment, containment is the STRONGEST,
definition of the work is "CMD'ed work" and that is the MBeans in our case
(they are GPL).
marc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Öberg
|Sent: Sunday, Octobe
| This is truly unfortunate. There are definitely ares of code that
|could be shared - that *should* be shared, such as logging, dynamic
|proxies, thread pools, and so on. It's too bad that it doesn't happen
|until a javax package is available... Particularly since those are *not*
|open s
Alright forget it, one other reason I think we should stick to code is the
consistently fail to communicate one way and the other.
We send Rickard to the lists and the communication channel breaks down
fast...
So let's stick to code, java code, there are so many ways to interpret that
and I am c
|> There were 2 questions (my questions are indented)
|>
|> is integrating the library with other work (without any modification to
|> the
|> Library) a "modification of the Library" in case of the LGPL?
|>
|> No, it is not. It is just using the library. The whole reason for
|> the LGPL is to gi
Sorry from the crosspost
So we asked Mr Stallman to state the obvious, the man obliged.
it was a waste of time/energy
1- Using our library in ANY software, without modification, does not trigger
LGPL coverage.
2- Developing our libraries and linking to non Free software is permitted
with LGPL,
13 matches
Mail list logo
