RE: [jBoss-Dev] Re: jboss on tomcat update
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). I need to go back to work / marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Öberg |Sent: Sunday, October 29, 2000 11:42 PM |To: jBoss Developer |Cc: tomcat-dev; Java Apache Framework |Subject: Re: [jBoss-Dev] Re: jboss on tomcat update | | |Dear all, | |I've read through the GPL license, and I'm not a legal expert but from |what I can see paragraph 2b is a killer. For example, I cannot see how |XO3 can redistribute jBoss with Tomcat and reasonably call it "mere |aggregation" (i.e. our JMX integration is not "mere aggregation", it is |much more than that), thus OpenJoda needs to "be licensed as a whole at |no charge to all third parties under the terms of this License." Which |breaks Tomcat's license, so it's out of the question. | |After listening to Marc's and all others arguments back and forth I have |the following thoughts (right or wrong, here they are): |* GPL paragraph 2b is a killer, and I cannot see how we can |bundle/integrate Tomcat without having to apply GPL to the whole |shebang. Sorry Marc, I just don't see it. The clause does not say "mere |aggregation in a Program" (which is what we do). It says "mere |aggregation of another work not based on the Program with the Program |(or with a work based on the Program) on a volume of a storage or |distribution medium", which is a completely different thing, closer to |Oles reference to RedHat CD's (BTW, yes I know I'm violating GPL |copyright by quoting it. So sue me) |* *Regardless* of whether we can do this or not, we can't "win". I don't |really care how *we* interpret GPL, and from what it seems our |interpretation is the loosest ever. It will do two things: |1) GPL hardcores will, pretty much, hate jBoss. Slashdot, here we come.. |2) "Suits" will stay away from jBoss ANYWAY, because it uses GPL. "So, |we can use it? Nah, my left foot says no, so that's it. I'm going with |OpenEJB. BSD gives me a fuzzy feeling". I don't care if it's rational or |not; there you have it. | |To me the solution seems clear. IMHO jBoss is not a "baby" anymore. We |do not have anything to gain by doing a crusade with GPL. We may not be |exactly where we want just yet (i.e. Project Game Over is not done), but |we sure are "enough" along the way to getting there. I may be wrong, but |that's my gut feeling anyway :-) | |So, for it to grow to the heights we want it if changing the license to |APL or MPL or BSD, or whatever makes sense (just not GPL), is what it |takes, then that's the way to go. IMHO of course. | |regards, | Rickard | |ps. Just to make it super-clear: These are the opinions of Rickard |Öberg, and are not necessarily representative of those of his employer. | |-- |Rickard Öberg | |Email: [EMAIL PROTECTED] |http://www.telkel.com |http://www.jboss.org |http://www.dreambean.com | | |
RE: [jBoss-Dev] Re: jboss on tomcat update
(EVERYONE: Please, PLEASE, leave the threats at the door. Honestly, raising the general level of antagonism is not getting us anywhere!) On Mon, 30 Oct 2000, marc fleury wrote: Aaron the bundling of APIs (JSP, EJB) that don't work together (JSP doesnt rely on EJB, and EJB doesnt rely on JSP) is PURE aggregation. It is useful for the beans. There is never CMD in the aggregate work. I am sorry but the line in the license is extremelly clear (yes specially 2b rickard). Marc, nothing in this entire discussion has convinced me that the GPL is "extremely clear" on anything - in fact, I find that quite the opposite to be true. No matter how many times you state "that is not true" or "the text is clear" it does not convince anyone else of anything. Perhaps you could substantiate your arguments slightly more? You seem to think that containment should be strictly interpreted as "a line of code from program X is placed in program Y". However, that is not clarified anywhere in the GPL. There is nothing in the wording of the license that leads me to believe that "containment" refers to "lines of source code" as opposed to "entire products". What leads you to this conclusion? And once again, the deciding factor is not what Marc Fleury thinks, or even what the jBoss Board thinks, it is what the users, observers, and lawyers think - what the "community" thinks. After all, nowhere in the license does it state that the composition of and/or opinions of the board will never change. Don't you find it just a little bit worrisome that no one who has spoken up from any of the Apache projects believes that jBoss can be legally integrated with Tomcat or Avalon? Even if every single one of them is wrong, don't you think this unanimous opposition from the groups we are trying to work with is going to cause problems with the adoption of the integrated work? Aaron In other words a J2EE server is pure "API together bundled" but I don't see the other API from my code, and I never have to add anything to anyone of them. All CMD work is GPL'ed (MBeans). Same mistake with JMX, it is VERY ignorant to claim linking - GPL. so GPL work does run on windows, because windows is not CMD work of GPL... this is getting tiring... JMX is not CMD work of jboss... marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder |Sent: Monday, October 30, 2000 6:49 AM |To: jBoss Developer |Subject: Re: [jBoss-Dev] Re: jboss on tomcat update | | |On Mon, 30 Oct 2000, Ole Husgaard wrote: | Before we go to such drastic steps as changing the license, | we should find out exactly what is the problem with the | license we have now. I've seen many flames and much hearsay, | and a lot of crying from both sides, but from facts and | valid arguments I have only been able to identify three | "problems": | | 1) jBoss cannot include the Tomcat code and distribute |the combination without breaking the APL license of |Tomcat. | 2) Tomcat cannot include the jBoss code and distribute |the combination without breaking the GPL license of |jBoss. | 3) Someone (forgot who) refuses to add the jBoss code |to their tree because they have a problem with the |GPL license. | | I think we need to add | | 4) It has been debated whether it is legal for jBoss to include | packages such as JMX which are neither GPL nor "safe" | operating system code | | In all three cases my opinion is "So what?". | | We're all entitled to an opinion. | | In the two first cases: These two programs can | easily be distributed seperately. | | I think the usefulness of a J2EE server is dramatically |higher than the usefulness of an EJB server. Thus I think it's |safe to say that it's a "good thing" to be able to integrate |jBoss and Tomcat. If you insist on keeping them separate, you |sacrifice performance (I don't think you could rationally claim |they're totally separate product when you distribute same-VM |integration code that deals with both directly - unless that's |yet another package), distribution (2 packages? How silly is |that?), and market (Let's see, I could have one integrated and |fully-tested product [Weblogic], or two completely separate |products that not even that authors believe can be safely run |together...) | | In the last case: Don't we already have our own | fine CVS tree? | | However, I say again that one of the fundamentals of open source |is that we should be able to share code. When someone puts together a |*really good* package Foo, everyone in the community who could benefit |from Foo should be able to use it and improve it. Isn't that what this is |all about? It does't make any sense to say "You are welcom
RE: [jBoss-Dev] Re: jboss on tomcat update
On Sat, 28 Oct 2000, marc fleury wrote: | What can I say? I agree that this is a reasonable interpretation. |But I don't think it's the only interpretation, and I'm not sure it's even |the interpretation intended by the authors. There's another section that |specifically allows distribution of GPL and non-GPL programs on the same |medium (Linux distributions), and that passage would be redundant if this |passage reads as you suggest. Listen it says if work is "containing, modifying, deriving" (CMD) of work that is GPL then GPL. If not, then not. (its' a mathematical if and only if) Ok let's loop on that for a while... Apache+Linux=aggregation, Apache is not CMD of Linux Frankly the wording is extremelly clear. GPL applies to "contained", "modified", or "derived" work not aggregated work and that is in the license what is not clear about it? I'll tell you, Marc, the word "contained" and the word "aggregated" as far as Java software goes, is what is extreemely unclear. The OO gurus do not even agree what the difference is between "contained" and "aggregated". Futhermore, I can change what I think is "contained" and what I think is "aggregated" in a Java program in a very technical fashion. So far I think Jon has a very salient point. -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jBoss-Dev] Re: jboss on tomcat update
On Sun, 29 Oct 2000, marc fleury wrote: THIS IS WHERE THE GPL DRAWS THE LINE FOR VIRALITY 4 Aggregation is the weakest, it just means bundling of work. GPL doesn't apply. Which to me means that the closest together the two can ever be is if Tomcat talks to JBoss and vice versa via a network socket. Then the two licenses can co-exist. Any code written to accept a Java interface after that network socket speaks would negate the legality, so you are stuck with something like http as your protocol. So why not just resort to sharp sticks and rocks while we're at it? But then as someone just mentioned, it matters not a stitch what you or I or Jon says, it matter what they lawyers say. -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jBoss-Dev] Re: jboss on tomcat update
Hi, Lots of flames and hearsay from both sides, but also some very valid arguments. I think we should try to find out exactly where we agree and where we disagree. This discussion is too important to use for another flamewar about licensing ideologies. We can both agree that neither of us want to violate the copyright of the other part, and that each copyright holder has a right to distribute _his_ copyrighted works under any license _he_ chooses. I also think we can agree that both jBoss and Tomcat are independent products that are both useful without the other part. (Just joking here) We have: usefulness(jBoss)+usefulness(Tomcat) = usefulness(jBoss+Tomcat) (synergy), and jBoss+Tomcat == (License problems). But usefulness(License problems) == 0, so unless we get this sorted out we have to derive: usefulness(jBoss)+usefulness(Tomcat) = 0. ;-) Peter Donald wrote: | I think it would definitely be safe to download a set of RPMs (one |per product) and then install them all and configure them to point to each |other (using network protocols, standard interfaces, etc.), but I think |it's very questionable whether you can put them in a single pre-configured |package. explain it to RedHat, This is turning silly RedHat complies. None of it's RPMs contain GPL and GPL incompatable products. They were blasted a while back because they broke this with one of their packages thou so I don't think they will make same mistake again. What red hat does is distribute a medium with multiple packages. I have this strange feeling that you both agree on this, but that none of you want to admit it... RedHat _does_ distribute software with GPL license and GPL-incompatible license on the same physical media. We can probably all agree that GPL does allow this due to the last paragraph of section 2: "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." What RedHat found out they could _not_ do was to combine software with GPL license and GPL-incompatible license into the same binary package, and then distribute this package. So I guess that the question boils down to: When do we have "mere aggregation" and when do we have "combined software" ? If I burn a CD with jboss.jar (as distributed from the jBoss site under GPL) and tomcat.jar (as distributed from the Tomcat site under APL) there should be no problems, as this is "mere aggregation". After all both distributions are seperate, except for the fact that they have been placed on the same physical media. It might become a little more tricky if I decide to order a batch of these CDs at a CD production facility. They want me to send an ISO image of the CD by email. But the ISO image is a single file and it contains both jars. Mailing the ISO image is distribution in the GPL sense, so _if_ the ISO image is "combined software" I would break the APL license. But is this ISO image "mere aggregation", or is it "combined software" ? There is a good argument in favor of "combined software": - The ISO image is a single file, so the software must have been combined rather than aggregated. There is another good argument in favor of "mere aggregation": - Neither the jboss.jar nor the tomcat.jar have been changed or modified in any way. They are both embedded in the same file, but they have not been combined. How do you think these two conflicting arguments would hold in a court of law? if tomcat is contained in same archive then it has to be GPL. This is similar to (though not the same) as the ISO image case above. If an archive containing unmodified jboss.jar and unmodified tomcat.jar is distributed under GPL, that would clearly be a violation of APL. And distributing it under APL would be a violation of GPL. But do we have to distribute the archive under one of these licenses? If both jboss.jar and tomcat.jar are unmodified, I guess that it would be possible to argue in favor of "mere aggregation" and claim that the archive containing them is simply a volume used for distribution. After all, they are both unmodified and neither jboss.jar nor tomcat.jar can be used until the archive is unpacked. Both GPL and APL allow distribution and neither are viral in case of simple aggregation, so it _should_ be possible to distribute an archive that simply aggregates the unmodified software from both of us. Do you agree on this? I think it makes sense to speak about _unmodified_ software only, as none of us are interested in any code forks. If dynamically linked via configuration file through a standard interface* and then there is some intermediate code that links to interface then that is OK. To do this you need to supply 3 archives. * jBoss archive (under GPL) * Tomcat archive (under APL) * linking layer (under APL and GPL compatable license - usually public
Re: [jBoss-Dev] Re: jboss on tomcat update
on 10/29/2000 8:46 PM, "Aaron Mulder" [EMAIL PROTECTED] wrote: I think we should do whatever we can to make jBoss universally acceptable. Because I want everyone in the universe to be able to choose to use it, on the basis of its features not on the basis of its license. Aaron So, then advocate that it uses a license which promotes such freedom. The truth is that the GPL is not one of those licenses. -jon -- http://scarab.tigris.org/| http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/
Re: [jBoss-Dev] Re: jboss on tomcat update
on 10/29/2000 11:19 PM, "Ole Husgaard" [EMAIL PROTECTED] wrote: I think we should try to find out exactly where we agree and where we disagree. This discussion is too important to use for another flamewar about licensing ideologies. Right, but at the core of the discussion IS the license so there is nothing that you can do about it. We can both agree that neither of us want to violate the copyright of the other part, and that each copyright holder has a right to distribute _his_ copyrighted works under any license _he_ chooses. I also think we can agree that both jBoss and Tomcat are independent products that are both useful without the other part. It is larger than just the copyright because it is about Marc wanting to protect his source code from the big bad corporations that are beating down his door trying to steal his source code from him. (Just joking here) We have: usefulness(jBoss)+usefulness(Tomcat) = usefulness(jBoss+Tomcat) (synergy), and jBoss+Tomcat == (License problems). But usefulness(License problems) == 0, so unless we get this sorted out we have to derive: usefulness(jBoss)+usefulness(Tomcat) = 0. ;-) Maybe so. Maybe that also says something about EJB. Maybe it is only something that should be provided by large corporations (ie: IBM/BEA) for exorbitant prices because it is something that is only really useful for such situations. -jon -- http://scarab.tigris.org/| http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jBoss-Dev] Re: jboss on tomcat update
On Sun, 29 Oct 2000, Dan OConnor wrote: In no way is the choice of license intended to prevent aggregation with Tomcat, nor to the best of my knowledge does the board--or the jBoss community in general--currently believe that this is the result. This sort of opinion is not like source code; we can't compile it and see it run (or not). I'm sorry about that. But there it is. Do you acknowledge that a number of people have a different opinion? If so, do you think their opinions count? That is, will you be happy if everyone on the jBoss board believes that jBoss can be legally integrated with Tomcat, or will you be happy if everyone in the world believes that jBoss can be legally integrated with Tomcat? In my case, it is not a case of what I believe, but what my company's clients believe, and unfortunately they do not see eye to eye with the jBoss board. Does that matter to you? It matters to me, because it matters to the people who decide what I will be paid to work on. :) I think we should do whatever we can to make jBoss universally acceptable. Because I want everyone in the universe to be able to choose to use it, on the basis of its features not on the basis of its license. Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jBoss-Dev] Re: jboss on tomcat update
Ok, I am sorry, I should actually provide some information. We use the GPL to protect the kernel. The virality of the GPL applies to the "derived work" or "modified work as a whole" of the kernel. Tomcat is not "derived work" of jboss, clearly, wouldn't you say? :). The "modified work as a whole" done in jboss to integrate the Tomcat jar is the MBean adapter (for JMX), the Tomcat Interceptors (classLoaders), and the J2EE deployer that we have developed. Those are GPL, as per the GPL derived work virality. The GPL applies to derived work 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 PROTECTED] |Subject: RE: [jBoss-Dev] Re: jboss on tomcat update | | || 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 never granted 'exceptions'. Please explain. | ||It is funny to me how you say that you are integrating our code which I ||think is great, but the real issue is that we can't integrate YOUR code ||because you choose to use the GPL license. | |why not? what exactly prevents you from integrating our work? |Please be explicit, | |let's not work from hearsay and "impressions" of the GPL, the GPL |is very explicit. | |regards | |marc | | | || ||Sigh. | | | || ||-jon || || ||
Re: [jBoss-Dev] Re: jboss on tomcat update
On Sat, 28 Oct 2000, Jon Stevens wrote: on 10/28/2000 4:06 PM, "marc fleury" [EMAIL PROTECTED] wrote: Indeed if the Avalon guy puts jBoss code in his tree and "contains" our work in his work then yeah.. that needs to be GPL. Bingo. So, this is something that is a major problem for me. 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 source (well, under a much more restrictive license, anyway). On Sat, 28 Oct 2000, marc fleury wrote: |2.b.) You must cause any work that you distribute or publish, that in |whole or in part contains or is derived from the Program or any part |thereof, to be licensed as a whole at no charge to all third parties under |the terms of this License. again, "work that contains the Program" is code that "contains" physically the Program (maybe thinking import in programming terms can help). What can I say? I agree that this is a reasonable interpretation. But I don't think it's the only interpretation, and I'm not sure it's even the interpretation intended by the authors. There's another section that specifically allows distribution of GPL and non-GPL programs on the same medium (Linux distributions), and that passage would be redundant if this passage reads as you suggest. I think it would definitely be safe to download a set of RPMs (one per product) and then install them all and configure them to point to each other (using network protocols, standard interfaces, etc.), but I think it's very questionable whether you can put them in a single pre-configured package. The problem is, I'm in a situation where (to quote "Ronin"), "Whenever there's a doubt, there is no doubt." Whatever you say, I haven't heard anything that convinces me that the interpretation is clear - I can easily see both sides of the disagreement. I suspect the only way for this to ultimately be resolved is to take it to a lawyer and/or RMS. Any volunteers? :) Overall, the most unfortunate thing here is that I don't believe either party is trying to lock out code from the other. But the fact that the licenses are not compatible means that one group or the other has to change licenses in order to enable true sharing of code, which is one of the greatest promises of open source. And it doesn't sound like either party is willing. Aaron
Re: [jBoss-Dev] Re: jboss on tomcat update
on 10/28/2000 5:41 PM, "Aaron Mulder" [EMAIL PROTECTED] wrote: Overall, the most unfortunate thing here is that I don't believe either party is trying to lock out code from the other. But the fact that the licenses are not compatible means that one group or the other has to change licenses in order to enable true sharing of code, which is one of the greatest promises of open source. And it doesn't sound like either party is willing. Aaron 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 -- http://scarab.tigris.org/| http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jBoss-Dev] Re: jboss on tomcat update
on 10/28/2000 5:22 PM, "Peter Donald" [EMAIL PROTECTED] wrote: Once RMS finds out about the project misusing the GPL he will start advocating all the GNU peopls stay away from it. Someone want to send an email to [EMAIL PROTECTED] recommending that RMS take a look at how the GPL is being used within the JBoss project? :-) -jon -- http://scarab.tigris.org/| http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[NOISE] Licenses (was: Re: [jBoss-Dev] Re: jboss on tomcat update)
on 10/28/2000 4:46 PM, "marc fleury" [EMAIL PROTECTED] wrote: |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. |Period. again that is an ASF decision (clean tree policy), not a license problem per se. Huh? The clean tree policy is completely related to the license problems of the GPL. |Marc, I'm definitely not afraid to tell you what I think and I'm tired of |discussing it. I'm burnt out on this war. It is completely stupid and it |looks like you are going to have to get yourself burnt before you see the |light. Sigh. wow, religious overtones... you are going to "burn me to see the light". You and what army, Torquemada? I'm not going to burn you. I didn't say that at all. I leave my quote above so that you can re-read it again and maybe understand it the second time you read it. |The only solution for you is to choose a NON GPL license for JBoss such as |MPL, BSD or APL. Period. You have no other choice unless you want to |completely loose control of JBoss and have all of your hard excellent work |completely ignored. the *only* final solution to what problem? the fact we can't live in your tree? well heck 60% of the world's OSS code lives in GPL... Again, you repeat this 60% value that has absolutely no context or any proof to back it up. Wake up, not everything is GPL. we already integrate, repeat, we already integrate No, you integrate with us because our license allows you to. We cannot integrate with you. That is where you don't quite get it. |I just went through this same exact stupid war with Justin Wells for nearly |4 months over WebMacro and he ended up releasing WM under the APL license |after he saw us take away his control of his product by producing a far |superior product under a APL license. hee hee threats... And you wonder why we are happy doing things our way... Not a threat at all. It is a factual statement of what happened and I'm warning you that you will probably have something similar happen to your product. Good luck. -jon
Re: [jBoss-Dev] Re: jboss on tomcat update
At 04:35 28/10/00 -0700, you wrote: on 10/28/2000 4:06 PM, "marc fleury" [EMAIL PROTECTED] wrote: Indeed if the Avalon guy puts jBoss code in his tree and "contains" our work in his work then yeah.. that needs to be GPL. Bingo. So, this is something that is a major problem for me. and me - I am that guy ;) This is the mutations I was talking about... but the ASF decides not to mingle with 60% of the world's OSS codebase *deliberately*. I'm sorry, but where exactly do you get that 60% number from? 60% is complete and utter BS with respect to java. Perhaps in c or c++ ma not with java. In my mind, OSS is about simply getting credit for the work that you do, not requiring people to either jump through hoops or give back their additions or changes to my source code. I don't give a rats ass what people do with my source code as long as they simply give me credit for my hard work. right. Thats the difference one philosophical difference between GPL and APL. GPL protects the code while APL protects the people. This results in a number of different things - one of which is frequency of forking. APL tends (from what I can see) to fork less often thou this may have a bit to do with institution (especially 2 codebases in one project approach) Cheers, Pete *--* | "Nearly all men can stand adversity, but if you want | | to test a man's character, give him power." | | -Abraham Lincoln | *--*
RE: [jBoss-Dev] Re: jboss on tomcat update
| 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 source (well, under a much more restrictive license, anyway). javax will solve the problem for the logging, the dynamic proxies are in 1.3 (if you want 1.2.2. then you need our stuff) the thread pools we might be very interested in, but *we* can "contain" your code so :)))s. Hey why don't you tell me *exactly* what you need, and we will see what we can do to accomodate your "clean tree" policy. | What can I say? I agree that this is a reasonable interpretation. |But I don't think it's the only interpretation, and I'm not sure it's even |the interpretation intended by the authors. There's another section that |specifically allows distribution of GPL and non-GPL programs on the same |medium (Linux distributions), and that passage would be redundant if this |passage reads as you suggest. Listen it says if work is "containing, modifying, deriving" (CMD) of work that is GPL then GPL. If not, then not. (its' a mathematical if and only if) Ok let's loop on that for a while... Apache+Linux=aggregation, Apache is not CMD of Linux Frankly the wording is extremelly clear. GPL applies to "contained", "modified", or "derived" work not aggregated work and that is in the license what is not clear about it? | I think it would definitely be safe to download a set of RPMs (one |per product) and then install them all and configure them to point to each |other (using network protocols, standard interfaces, etc.), but I think |it's very questionable whether you can put them in a single pre-configured |package. explain it to RedHat, This is turning silly | The problem is, I'm in a situation where (to quote "Ronin"), |"Whenever there's a doubt, there is no doubt." Whatever you say, I Listen, I like the ronin trick but there is NO doubt, Repeat if and only if work is CMD of GPL Work then GPL. Take Tomcat, is that "containing" "deriving" "modifying" work of jboss? NO you don't derive (although you might have been inspired by the interceptor layout;-) you don't modify (afaik) and you CERTAINLY don't contain. |haven't heard anything that convinces me that the interpretation is clear |- I can easily see both sides of the disagreement. I suspect the only way |for this to ultimately be resolved is to take it to a lawyer and/or RMS. |Any volunteers? :) 1- we have a LICENSE gentlemen, words, black on paper... That's what we work from. And the words are clear, I really honestly don't see why the big confusion. RMS could be a "auto-response-program" that spouted "all must be GPL" that I wouldn't care, 2- this is copyright telkel+jboss authors. | Overall, the most unfortunate thing here is that I don't believe |either party is trying to lock out code from the other. But the fact that |the licenses are not compatible means that one group or the other has to again the licenses are compatible, what is not compatible is that ASF doesn't want GPL code in the tree. It's a policy gentlemen, that forces us to do something if we want you guys to include code in your tree. Again I understand that, well I respect it more than I understand it, and that seems to mean "separate projects". I already stated my honest belief that many bees are better than a drunken duck (wow, that sounded good, I gotta reuse it and use that ronin trick )... |change licenses in order to enable true sharing of code, which is one of |the greatest promises of open source. And it doesn't sound like either |party is willing. to be very honest, I don't care that much, about the GPL, the APL, and the horses they rode in town on. I care even less about the grandiose statements about "philosophy" from "the ladies corner". Honestly all I care about is that our common code kicks ass. when all is said and all is done, IT DOES. Tomcat+jboss is a great j2ee stack, a credible alternative to a billion$ market, welcome ladies, start fighting cause the commercial EJB guys in front are not joking. Ok, I need to go now, I have a costumed halloween party and I need to dress up as Zorro... whistle/ good night... marc | |Aaron | | |
RE: [jBoss-Dev] Re: jboss on tomcat update
| What can I say? I agree that this is a reasonable interpretation. |But I don't think it's the only interpretation, and I'm not sure it's even |the interpretation intended by the authors. There's another section that |specifically allows distribution of GPL and non-GPL programs on the same |medium (Linux distributions), and that passage would be redundant if this |passage reads as you suggest. Listen it says if work is "containing, modifying, deriving" (CMD) of work that is GPL then GPL. If not, then not. (its' a mathematical if and only if) Ok let's loop on that for a while... Apache+Linux=aggregation, Apache is not CMD of Linux Frankly the wording is extremelly clear. GPL applies to "contained", "modified", or "derived" work not aggregated work and that is in the license what is not clear about it? well obviously enough that you don't understand it. You really should seek legal advice or at least advice from someone who knows what they are talking about (RMS for the GNU angle). | I think it would definitely be safe to download a set of RPMs (one |per product) and then install them all and configure them to point to each |other (using network protocols, standard interfaces, etc.), but I think |it's very questionable whether you can put them in a single pre-configured |package. explain it to RedHat, This is turning silly RedHat complies. None of it's RPMs contain GPL and GPL incompatable products. They were blasted a while back because they broke this with one of their packages thou so I don't think they will make same mistake again. What red hat does is distribute a medium with multiple packages. | The problem is, I'm in a situation where (to quote "Ronin"), |"Whenever there's a doubt, there is no doubt." Whatever you say, I Listen, I like the ronin trick but there is NO doubt, Repeat if and only if work is CMD of GPL Work then GPL. umm NO - go reread it again. Pay particular attention to all sections and then explain why clause 3 has a number of exceptions near the end ? If you are still not convinved then seek legal advice Take Tomcat, is that "containing" "deriving" "modifying" work of jboss? NO you don't derive (although you might have been inspired by the interceptor layout;-) you don't modify (afaik) and you CERTAINLY don't contain. if tomcat is contained in same archive then it has to be GPL. If code is contained in archive that links against tomcat then that code has to be GPL. If that code is GPL then tomcat has to be GPL. If dynamically linked via configuration file through a standard interface* and then there is some intermediate code that links to interface then that is OK. To do this you need to supply 3 archives. * jBoss archive (under GPL) * Tomcat archive (under APL) * linking layer (under APL and GPL compatable license - usually public domain) This is a PITA yes and that is the intended solution. RMS set the license up this way so that it makes it more desirable to GPL the whole work. |haven't heard anything that convinces me that the interpretation is clear |- I can easily see both sides of the disagreement. I suspect the only way |for this to ultimately be resolved is to take it to a lawyer and/or RMS. |Any volunteers? :) 1- we have a LICENSE gentlemen, words, black on paper... That's what we work from. And the words are clear, I really honestly don't see why the big confusion. RMS could be a "auto-response-program" that spouted "all must be GPL" that I wouldn't care, Then would you mind if I emailed him and informed him of the situation ? 2- this is copyright telkel+jboss authors. this has nothing to do with anything. | Overall, the most unfortunate thing here is that I don't believe |either party is trying to lock out code from the other. But the fact that |the licenses are not compatible means that one group or the other has to again the licenses are compatible, what is not compatible is that ASF doesn't want GPL code in the tree. NO they are NOT. RMS goes over the reasons on the web page. There is currently one remaining clause that makes APL not GPL compatable (thou hopefully eventually that will go away) It's a policy gentlemen, that forces us to do something if we want you guys to include code in your tree. Again I understand that, well I respect it more than I understand it, and that seems to mean "separate projects". It is not the APL that blocks it but the GPL. GPL is incompatable with APL and linking against it like you have done is illegal and all copyright holders are liable for such things. I would hate to be in that position when a large company adopts jBoss looses cash because you have mislicensed product and then goes after you. In my country (Australia) it means up to 10 years in jail - sound like fun ? I already stated my honest belief that many bees are better than a drunken duck (wow, that sounded good, I gotta reuse it and use that ronin trick )... I agree |change licenses in order to
RE: [jBoss-Dev] Re: jboss on tomcat update
| 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 never granted 'exceptions'. Please explain. |It is funny to me how you say that you are integrating our code which I |think is great, but the real issue is that we can't integrate YOUR code |because you choose to use the GPL license. why not? what exactly prevents you from integrating our work? Please be explicit, let's not work from hearsay and "impressions" of the GPL, the GPL is very explicit. regards marc | |Sigh. | |-jon | | |
