Discussions

JBoss has filed an issue changing the license for the JBoss Application Server to be closer to the Red Hat license model - possibly indicating a fork to JBoss similar to that between Red Hat and Fedora, according to one TSS contributor. JBoss says that the license change only closes some loopholes regarding branding and export controls.
The license change issue applies this text to the JBoss Application Server. This appears essentially to be a slightly modified version of the Appendix 1 of the Red Hat Enterprise Linux license agreement. This change seems to have been prompted by Red Hat's acquisition of JBoss which was completed in May.
You may recall that Red Hat does not make Red Hat Enterprise Linux directly available for free, a model that Red Hat VP, General Manager, JBoss Division Marc Fleury praised in his August 26th, 2006 blog entry entitled "Wall Street, Oracle and Game Theory."

See, nowhere in the GPL is it said that we must distribute the software to you in the first place. Dion Cornett likes saying GPL != Public Domain. In fact, in the case of RHEL, RedHat doesn't distribute it to anybody, not for free that is.

This model has caused multiple forks of Red Hat's RHEL operating system, the most popular being Centos. According to the Wikipedia, Red Hat has aggressively pursued even Centos's use of Red Hat trademarks on their webpage as well as any lapses in thorough cleansing of the source.
While there has been some controversy in the free and open source communities about this, other figures such as Eric Raymond, author of "The Cathedral and the Bazaar" have praised the RHEL model.
However, removing Red Hat's trademarks and logos from a Linux distribution requires less effort than the least stringent removal from a Java application server, or at least JBoss's. Consider the effort to remove all org.jboss packages and replace them with org.foobar and any use of the word JBoss from the source with the exception of copyright statements. In a recent version of the JBoss source this would have meant modifying 41159 lines of code (source: find/grep of recent checkout using find . -name "*.java" -exec grep -Hi "jboss" |grep -v Copyright '{}' ';'). This obviously says nothing of the build scripts, directories, text and configuration files that must be altered. What does this mean for development on JBoss and for members of the JBoss community who wish to use, distribute and contribute patches? What does this mean for OEM uses of JBoss (JBoss has long claimed to be #1 in the OEM market for Application Servers?
One possibility is a new fork of JBoss similar to Fedora. This possibility was raised by Matthew Szulik in a recent article: "Marc Fleury is going through the pros and cons on that," Szulik said. "I don't think it would work any differently to the RHEL subscription model."
Supposing that Fleury reaches a positive conclusion in his study of this, as his blog seems to indicate he will, how would the Java and Java open source communities react?
JBoss replied to this suggestion, and said "the new changes in the EULA affect only those who redistribute JBoss products. If you're just using our products and developing applications, these changes have zero affect on you. In addition, the new EULA is not retroactive.
"The two major changes concern intellectual property rights and export control. In fact, you can consider this an effort to close existing loopholes in our old agreement.
"In terms of IP, if a company is redistributing our products and they are not a partner, they have to remove our logos (http://jboss.com/company/logos tells you exactly which logos, so there's no confusion here). Your scenario below about removing org.jboss packages and replacing them with org.foobar is inaccurate, as this IP clause affects logos only. We have had instances where companies (not partners of ours) redistribute modifications of our products under our name. This is false marketing and misleading to customers. When their customers have problems this product, it becomes our problem.
"In terms of export protection, this is standard for all software businesses, and something that was missing in our old EULA. Again, if you're a user, this really does not affect you. But if you plan to redistribute, the agreement asks that you comply by a law greater than JBoss - federal law."
JBoss also said that forking JBoss in a manner similar to Fedora and Red Hat was not going to happen, because "it is already the equivalent of Fedora."
What do you think?

I think Marc and Matthew should consider this very carefully. As Marc says in his treatise that game theory predicts that alternative players and substitute choices will prevent a monopoly from arising.
We have been big supporters of JBoss and the JBoss stack in the development of Alfresco and intend to do so going forward. We have happily participated in their partner and OEM programs and intend to in the future. I'm sure that they will make that easy going forward.

LGPL licensed source code can be changed and redistributed with LGPL (or GPL) too, package and class names are part of source code, JBoss protected name conflicts with GPL rules, I think GPL wins because source code is oldest than JBoss as a protected name, unless the source code was licensed with GPL + some kind of annex about JBoss name use.
I think JBoss has now enough budget to buy the source code copyrights to the original developers outside of JBoss/Red Hat company and change the license.
Jose M. Arranz
JNIEasy 1.1 Linux & Windows.

LGPL licensed source code can be changed and redistributed with LGPL (or GPL) too, package and class names are part of source code, JBoss protected name conflicts with GPL rules, I think GPL wins because source code is oldest than JBoss as a protected name, unless the source code was licensed with GPL + some kind of annex about JBoss name use.

FWIW I very much doubt that the trademark of "JBoss" would hold up in court, since many people (including me) used it way way way before JBoss Inc. registered the trademark.
I, and other former JBoss developers, have signed formal statements declaring this which are kept by lawyers if anyone should have the use for them in the future.

I think JBoss has now enough budget to buy the source code copyrights to the original developers outside of JBoss/Red Hat company and change the license.

Yup, I've said it before and I'll say it again: JBoss may buy my copyrights of the source code for the round and neat sum of $1M. Not only will they get the copyright, but any comments from me about details like the unenforcability of the trademark will go away too as an added bonus.

Uh, mistake, JBoss is LGPL licensed.
JBoss may buy my copyrights of the source code for the round and neat sum of $1M
1 million dollars? a nice gift :)
I think the industry needs a new open source license, something like: "this program is open sourced but no public source code changes can be made and can not be redistributed without owner permission", it is more appropriate to "business-driven" open source products.
Jose M. Arranz
AsPeopleSay.com The free online Google based syntactic corrector/spell checker.

At the going price of youtube.com these days $1M just has a Dr. Evil sound to it. (http://www.austinpowers.com/drevil/) For those that haven't seen the movie, I apologize. Please tell me you don't hold your pinky finger to your mouth when you say it. Rickard, hope you get paid for XDoclet too.
I think things like Ubuntu happen when Redhat changes its distrubution strategy. Geronimo, although not ready for primetime, and Glassfish have less volatile licensing. As these stabilize technically while JBoss destabilizes licensing, JBoss market share should become Fedora-ized as well.

Yup, I've said it before and I'll say it again: JBoss may buy my copyrights of the source code for the round and neat sum of $1M. Not only will they get the copyright, but any comments from me about details like the unenforcability of the trademark will go away too as an added bonus.

I love the way this guy is so direct. The world would be a less complex place to live if people were to be direct like Rickard!! Thumbs up, Rickard.
J

Yup, I've said it before and I'll say it again: JBoss may buy my copyrights of the source code for the round and neat sum of $1M. Not only will they get the copyright, but any comments from me about details like the unenforcability of the trademark will go away too as an added bonus.

I love the way this guy is so direct. The world would be a less complex place to live if people were to be direct like Rickard!! Thumbs up, Rickard.

J

Yeah. What we need is a few more Kim Jong Il's and Rickard Obergs and the world will truely be special.

Yeah. What we need is a few more Kim Jong Il's and Rickard Obergs and the world will truely be special.

Thanks Andy! That's the nicest thing you've ever said to me I think! Warms my heart to know that deep down you want more people like myself to help brighten yer day. I had a feeling you weren't like the other mindless drones that for whatever reason thoughtlessly repeat the Borgesque party lines that the Great Ones spew forth. You rock!

.. JBoss may buy my copyrights of the source code for the round and neat sum of just $500M, half of what Rickard is asking. Please email me for my bank account details. Rickard asks me to collect his on his behalf so I would expect $1.5M in my account.
Your Sweetest,
Jan

use Geronimo or GlassFish.... there licenses is still OEM friendly especially Geronimo as u can expect it to remain unchanged and its distribution policy is really highly stable(apache software)
ok... i really hate to say this but what to say... JBOSS put us in a very critical situation as we distribute a ready to go application, and now we have to switch...

use Geronimo or GlassFish.... there licenses is still OEM friendly especially Geronimo as u can expect it to remain unchanged and its distribution policy is really highly stable(apache software)ok... i really hate to say this but what to say... JBOSS put us in a very critical situation as we distribute a ready to go application, and now we have to switch...

This is false marketing and misleading to customers. When their customers have problems (with) this product, it becomes our problem.

The above statement is somewhat amusing since http://www.jboss.org/products/jbosside refers to "JBoss Eclipse IDE" under the products section of the left-hand side and also on the page title. INAL, but surely this goes against the Proper Usage of "Eclipse" trademark guidelines. One might go as far to say that this could be considered false marketing and misleading to customers?
I'd pointed this out to JBoss on Sept. 5, 2006 and have a response stating:
"JBoss IDE is the appropriate technical & internal name for the product. I'll forward this on to the correct people here at JBoss to see what we can do to rectify the problem...."Savio

The "JBoss" trademark, "Red Hat" trademark, the individual Software Package trademarks, and the "Shadowman" logo are registered trademarks of Red Hat and its affiliates in the U.S. and other countries. This agreement does not permit Client to distribute the Software Packages using Red Hat's trademarks. Client should read the information found at http://www.redhat.com/about/corporate/trademark/ before distributing a copy of the Software Packages, regardless of whether they have been modified. If Client makes a commercial redistribution of any Software Package(s), unless a separate agreement with Red Hat is executed or other permission granted, Client must replace all Red Hat trademarks and logos identified at http://www.jboss.com/company/logos.

Why not let a 3rd party ship an un-modified version of a JBoss product with all the JBoss logos? What harm is this 3rd party doing to the JBoss brand or to JBoss IP? I know that with WAS Community Edition, (WAS CE), built with Apache Geronimo, we let partners ship un-modified versions of WAS CE without having to enter into a business relationship with IBM (i.e. no royalties, revenue sharing, revenue targets, etc). Our lawyers, did require that the 3rd part accept liability for any copies that they shipped, which has more to do with IBM being a larger target for legal action than us forcing 3rd parties to share revenue with us for work they undertake on behalf of their customers. And as pointed out earlier, using Apache Geronimo removes any of these issues with modified or non-modified Geronimo files because it's under the ASF 2.0 license.
Is the EULA change intended to convince/force more 3rd party ISVs to enter into an OEM/partner agreement with JBoss? This surely keeps with Red Hat's strong push to attract channel partners (hint: honey attracts more than using a stick). However, what JBoss has to keep in mind, and what we in WAS CE land understood early on, is that smaller ISVs/SIs (who often wear both hats) price in support for their total solution when setting the price of the solution for their customer (often a small company). These ISVs/SIs do so because the customer is going to call them, not the individual vendors whose products make up the solution, when a problem arises.
It appears that Red Hat/JBoss wants to get their share of the support revenue that these smaller ISVs and SIs rely on, and for that matter, often deliver to their end customers without any direct relationship with JBoss or other vendors.
Savio

See, nowhere in the GPL is it said that we must distribute the software to you in the first place. Dion Cornett likes saying GPL != Public Domain. In fact, in the case of RHEL, RedHat doesn't distribute it to anybody, not for free that is.

this is nonsense
while GPL does not oblige you to distribute your software for free (or distribute it at all), anyone who buys the software from you has the right to also receive the sources and is allowed to re-distribute them (even for free) because that's what GPL says - freedom to re-distribute according to the terms of this licence
so, it doesn't matter if you will distribute your super cool GPL component only to people who are willing to pay you $1,000,000 because anyone who pays may start re-distributing it for free

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.