Apache Geronimo: Apache Initiates open source J2EE project

Discussions

News: Apache Geronimo: Apache Initiates open source J2EE project

  1. Apache has started a project to create an open source, Apache-licenses implementation of J2EE. One of the core commitments is for the J2EE implementation to be fully J2EE compliant. The Apache Foundation has access to the J2EE TCKs, which make the certification possible. The core developers who have "signed up" include: Richard
    Monson-Haefel (OpenEJB), Geir Magnusson Jr. (Apache), Dain Sundstrum (Core Dev Network), James Strachan (Apache), and more.

    Editor's Note August 8, 2003

    You can find more information about the Incubator for Apache Geronimo at http://incubator.apache.org/


    Apache Email Memo:

    As you may have heard by now, the Apache Software Foundation has initiated a project to develop an open source, Apache-licensed implementation of the J2EE specification. In addition, the project is committed to certifying the implementation as J2EE compliant. This is an ambitious goal and will present a formidable challenge for the people involved, given the wide range of technologies covered by the specification.

    The project (tentatively named "Apache Geronimo") builds upon the many Java projects at the Apache Software Foundation. In addition, the project is bringing together leading members of the Castor, JBoss, MX4J and OpenEJB communities. We would like to extend an open invitation to everyone involved in the J2EE space, both commercial entities and talented individuals, to join the community and build a world-class J2EE implementation.

    The Apache Software Foundation is in a unique position to build a J2EE compliant platform. Our non-profit, charity status, and our relationship with Sun Microsystems, provides the Foundation with access to the J2EE TCKs, making it possible to achieve certification. In addition, our flexible and unrestrictive licensing makes it possible for a wide variety of participants to assist in the development of Apache Geronimo, and to build their own solutions upon the platform.

    Apache Geronimo has been launched within the Apache Incubator. You can find more information about the Incubator at http://incubator.apache.org/. To find out more about this project or if you would like to become involved, please send email to the incubator mailing list: general at incubator dot apache dot org

        On behalf of the Apache Geronimo Team,

        Greg Stein,
        Chairman of the Apache Software Foundation

    Email sent to the general incubator apache mailing list:

    Proposal for an Apache J2EE server project
    ==========================================

    05 Aug 2003 : Geir Magnusson Jr., James Strachan and Richard Monson-Haefel

    Section 0 : Rationale
    ---------------------

    The Java 2, Enterprise Edition (J2EE) platform is employed widely by organizations implementing enterprise applications. It is ommonly used in business-to-consumer and most recently in Web service deployments. Most of the largest business organizations today have deployed applications on a J2EE platform.

    While the J2EE specification is implemented by a number of large and small vendors, there is no open source J2EE container available with a BSD or BSD-derived licence nor is there an open source project today that provides a fully compliant implementation. Verifiable compliance with the J2EE specification is important to business because it ensures that applications deployed by developers are portable and interoperable across J2EE providers.
    As a result organizations large and small have felt compelled to pay thousands of dollars to commercial vendors in order to deploy applications based on J2EE compliant servers.

    The Apache foundation supports several projects that implement pieces of the J2EE platform such as Servlets, JSP, Tag Libraries, and a Web services stack. However, Apache does not currently support a J2EE project.

    The aim of the project is to produce a large and healthy community of J2EE developers tasked with the development of an open source, certified J2EE server which is ASF licensed and passes Sun's TCK reusing the best
    ASF/BSD licensed code available today and adding new code to complete the J2EE stack.


    Section 0.1: criteria
    ----------------------

    We feel that this project has a good chance for success as the following project aspects are carefully considered :

    a) Meritocracy: The project will be meritocratic - the usual Apache meritocracy rules would apply.

    b) Community: The user community for this project is potentially massive. The initial developer community for this project consists of developers from Apache, Castor, JBoss, mx4j, and OpenEJB projects. The aim is for this community to grow considerably once this project goes public.

    c) Core Developers: The initial developers are listed below and consist of some existing Apache committers together with committers from Castor, JBoss, mx4j and OpenEJB. We believe that as the project grows, the modular nature of the J2EE stack will require steady expansion of the committer group that is considered 'core' - thus providing a healthier, more robust developer community.

    d) Alignment: There is clear alignment with many existing Apache projects. From Jakarta projects such as Tomcat, James and log4j initially as well as possibly others along the way. J2EE now includes a web services stack and so there will be some alignment with the WS project, Axis in particular, along with the reuse of several XML projects. In addition the J2EE Server project may reuse other ASF/BSD licensed code which is not currently hosted in source form at Apache such as (at time of writing) mx4j, openjms and tyrex.

    However we see the J2EE Server project as a separate project to existing Apache projects, serving two primary roles

    * integration of various existing and new code bases into a J2EE stack, with those codebases existing both inside and outside of the project
    * certification of the J2EE stack

    Note that the J2EE server project can happily support competition within the J2EE services stack (for example, offering choices for elements such as the servlet engine like Tomcat or Jetty, or some new JTA implementation versus Tyrex or some new JMS implementation versus OpenJMS etc).


    Section 0.2 : warning signs
    ----------------------------
    We feel that this project has a good chance for success as the following warning signs do not apply to the project we are proposing :

    a) Orphaned products: This project is starting with a new code base together with reusing lots of the currently available high quality J2EE open source code out there which is ASF/BSD licensed.

    b) Inexperience with open source: The initial community is made up of existing Apache, Castor, JBoss, mx4j , and OpenEJB committers.

    c) Homogeneous developers: The current list of committers represents developers from various backgrounds and open source projects, employed by various companies and based around the globe in the US, Europe, Asia and Australia. There will be no majority bloc, at least from the start.

    d) Reliance on salaried developers: None of the initial developers are currently paid to work on the J2EE project.

    e) No ties to other Apache products: The J2EE Server project is complementary to existing technologies at Apache. Indeed it will integrate many of those technologies in an effort to provide a code base that can be J2EE certified according to the JCP process.

    f) A fascination with the Apache brand: The committers are interested in developing a healthy open source community around an ASF/BSD licensed J2EE certified server, whether Apache is the right place or not. The aspects of Apache that attract this effort are the experienced stewardship of open source projects by the ASF, the non-profit status of the ASF for TCK
    certification, and the existing Java community that has been a longstanding part of the ASF.

    Section 1 : scope of the project
    --------------------------------

    There are two main aspects to this Apache project :

    * a complete J2EE certified server which is fully ASF/BSD licensed and backed by a healthy open source community.

    * to create a fully modular J2EE stack so that the Apache community can use whichever parts of the J2EE stack they require separate from the J2EE server project.


    Section 2 : initial source from which the project is to be populated
    --------------------------------------------------------------------

    There are several potential initial contributions. Upon formation of the project our first action will be an open, public call for contribution and comment from the J2EE community. Because of recent circumstances in the J2EE OSS community, all code proposed for inclusion must be publicly reviewed and open to public comment.

    Section 3: identify the ASF resources to be created
    ----------------------------------------------------

    Section 3.1 : mailing lists

    * geronimo-dev
    * geronimo-user

    Section 3.2: CVS repositories

    * geronimo

    Section 3.3: Bugzilla

    * geronimo

    Though would there be an issue with using JIRA?


    Section 4: identify the initial set of committers
    -------------------------------------------------

    The committers are listed below, along with the open source project(s) where they also have commit privileges.

    * Bruce Snyder (Castor JDO)
    * Dain Sundstrom (JBoss)
    * David Blevins (OpenEJB)
    * David Jencks (JBoss)
    * Geir Magnusson Jr. (Apache)
    * Greg Wilkins (JBoss/Jetty)
    * James Strachan (Apache)
    * Jan Bartel (JBoss/Jetty)
    * Jason Dillon (JBoss)
    * Jeremy Boynes (JBoss)
    * Jim Jagielski (Apache)
    * Jules Golsnell (JBoss/Jetty)
    * Richard Monson-Haefel (OpenEJB)
    * Remigio Chirino (JBoss)
    * Simone Bordet (mx4j)

    Announcements:

    Apache Announcement
    Core Developers Network

    Threaded Messages (138)

  2. Yes!!![ Go to top ]

    I've been waiting for this for quite some time.

    Best,

    John C. Dale
  3. What's the point?[ Go to top ]

    Seems like a waste of time. I cannot imagine anything production ready coming out of this until year 2005.

    Apache had the keys to be a player in the J2EE space four years ago. And they decided not to. So what's the point of trying to re-enter now four years later? This doesn't make a whole lot of sense to me.

    /T
  4. Re: What's the point?[ Go to top ]

    Many of the reasons for this project are described in the
    first paragraph of www.apache.org:

    "The Apache Software Foundation provides support for the Apache community of open-source software projects. The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users."
  5. I think it's useful[ Go to top ]

    We need a J2EE Server that is Open Source,the JBOSS is fine.but we also need another that is open sourced. I'm looking forward it.
  6. their is already an other one[ Go to top ]

    At present time, there is already Jonas (http://jonas.objectweb.org/) that is an OS competitor for Jboss... But it's right that an other J2EE project can't be bad :)
  7. We need strong competition![ Go to top ]

    I agree that JBoss is great, we use it for more than a year now.
    I am happy that JBoss folks are going to buy J2EE 1.4 TCK and decided to get JBoss J2EE 1.4 certified.
    Mark Fleury & Co have built a successful business behind JBoss which give them ability to finance the JBoss future development, but there is strong possibility that first of all this development will go in interests of JBoss Group the same way WebSphere has been developed in interests of IBM: some J2EE API may be not implemented, some addidtional API has been included to differentiate their product. As a result of such a move we should forget about portability and commit ourself to JBoss.
    That's why we need a strong competitor in OSS J2EE implementations!
    Exolab moved almost everything to SourceForge, and has some strong solutuions, such as OpenORB (the best CORBA OOS IMHO) and Castor, but OpenEJB if definitely behind the current specs.
    I am less familiar with ObjectWeb tools, I used to use JOnAS more then 3 years ago; and now it can not compete with JBoss, IMHO.
    Only ASF has strong reputation, experience and financial resources to begin such a project now, and I hope they'll succeed.
  8. I think this is great. Look at how competition between KDE and Gnome has improved both of those projects. I think JBOSS needs another open source competitior.

    JBoss seems to be going far beyond a J2EE server, which is ok if you don't mind getting locked in. I hope that this apache project sticks to the fundamentals and makes a good J2EE implementation.

    Looking forward to it! Go Apache!

    Mike
  9. Competition[ Go to top ]

    There's already OS competition for JBOSS, and for some time, AFAIK: Project JOnAS (http://jonas.objectweb.org/). I wonder why no one talks about Jonas, just about JBOSS. Jonas seems to need more active bosses. mmmm... no. Bad idea... :)

    Even if in the end Apache comes too late to the J2EE market (if it does apply to an open source project, anyway), at least this effort will create more synergy in Apache's set of projects. I just hope it doesn't create more dependencies between them.

    Good luck!
  10. Competition[ Go to top ]

    Yes, Jonas is an other alternative.

    Jonas has good tech but has a majority of French business partners (with less money than potential US ones ;-)). Initialy, the open source community wasn't as well federated as for JBoss (I think that it was a company named Lutris ??). In 2001, When I was looking for a free open source J2EE container, i think that Jonas wasn't in LGPL (to confim but ...).

    So, for the open source community, Jonas came later than JBoss (which can explain that less people know it). Perhaps that with ObjectWeb forge this will change. What we can say is that it's hard to arrive after ( I think to Geronimo ...). Perhaps that the "open source marketing" machinery of Apache could solve this ;-) !

    FredJ.
  11. ObjectWeb[ Go to top ]

    I think, ObjectWeb (including JOnAS, Enhydra, C-JDBC, Octopus, etc.) deserves more than what they've received until now. Enhydra and JOnAS are really good products and can deliver solutions for production environments.

    If you see the architecture of JOnAS, it is component-based and it integrates many other components available like Joram for JMS; Medor and JORM for CMP EB 2.0; Carol for RMI and Tomcat/Jetty for Servlet container. Enhydra is also the same. It integrates many other components available like XMLC (XML Compiler), DODS (O/R Mapper), Kelp (IDE Integrators), Director (Load Balancer), etc.

    I would say that ObjectWeb produces many good quality of products just the same as Apache...

    Regards,
    Lofi.
    http://www.openuss.org
  12. So good![ Go to top ]

    Good news for us to involved it.
  13. Sounds Interesting[ Go to top ]

    Come baby, come baby, baby come come!
  14. Good news
  15. Wooohooo, it's about time.
  16. It looks like lots of JBoss people are joining this project. Are the so fed up with Jboss !.
    Now what will happen to Jboss.
  17. I just hope this new initiative would be a full meal!!!
  18. A few questions:

    What does the JBoss Group people say about this? Is all their code GPLed or otherwise open licensed for this so that JBoss can't mess with it? What will be the license on the new codebase?

    Is this a branch of the 3.x or 4.x trees?

    Is there still the rush to AOP support, or are infrastructure, performance, integration, and other issues going to be leading?

    Is there going to be an effort to build direct bridges with other projects not named? For example, hibernate, open adaptor, etc..?

    thanks! I'm glad to see this!
  19. I just hope that the Apache goal isn't just to offer us another J2EE container : an Open Source project must always integrate "innovation", no ?

    I was exciting each time JBoss initiators Richard O and Marc F. offered us
    their concepts and innovations in their J2EE implementation : First with JMX, next with the first Message Driven Bean implementation, and last with AOP (they are more but ...).

    I have a question :
    Can the Apache initiave be as innovative as JBoss if they only use proven concepts ?

    As they said they will reuse the more code they can in the existing projects
    (even JBoss).
    Good ! but where is the innovation ?

    If the real difference between JBoss and Geronimo is the J2EE licence agreement of Sun, this could change as they are in negociation with SUN.

    see :
    http://www.crn.com/sections/BreakingNews/dailyarchives.asp?ArticleID=43672

    If they make the deal, Geronimo will have to bring community lots of goods thing to be attractive ;-) !

    Hope this will be !!

    FredJ.
  20. A minor note: I believe that (the now defunct) Bluestone Software had the first available MDB implemenation.

    Greg
  21. Yes I agree, this was my initial reaction as well.

    So many Open Source projects are playing copycats to what the big commercial guys are doing, cloning the existing software and lagging couple of years behind rather than trying to innovate. That's why I think JBoss has been such a delightful exception. Just look at the recent news in the J2EE arena, JBoss the Open Source project is the spearhead of J2EE innovation driving the platform forward along with BEA and others. They are not the followers.

    Apache's J2EE effort is lukewarm. They're not attempting to push the platform further. They're not interested in fighting the .NET threat from Microsoft. They talk about building a clone of what the commercial vendors and JBoss Group has done for the past years. Like Marc Fleury said in his recent News email, Apache is 'a bunch of fat ladies drinking tea'. They're interested in the past, not the future. They had a chance to be part of the future four years ago and turned it down.

    This is why I think that the creation of JBoss Group along with the JBoss Open Source project has been so pivotal. They have a direct financial interest to be the best, to drive the innovation, to push the technology. Apache has none of that. At best, in couple of years we get yet another reference implementation from Apache. Not terribly exciting.

    /T
  22. What does the JBoss Group people say about this? Is all their code

    > GPLed or otherwise open licensed for this so that JBoss can't mess
    > with it? What will be the license on the new codebase?

    Quoting from the news letter yesterday:
    "Apache J2EE effort.
    First a bit of history. I offered EJBoss when it was 4 month old to
    Apache. The guys at Jakarta vote OK unanimously and their vote was
    overridden by Brian Behlendorf. The reason from behlendorf was that they
    'were not the dust bin of open source projects'. I heard the Apache
    crowd got offended for me calling them "a bunch of fat ladies drinking
    tea" at a later date when they were running around telling us how to run
    our project. We had reports that this was the non-official reason for
    this "challenge". Challenge accepted. More seriously as we overtake
    them in corporate penetration and business model, I guess they are
    finally looking beyond the HTTPD C codebase and imitation is the
    sincerest form of flattery.

    We are the real thing, all we have so far is talk and announcement,
    announcements are a dime a dozen. Apache code on this project has yet
    to be released and then production reached and then maturity bla bla
    bla. I have little comment on the project except to say that JBOSS IS
    NOT A PART OF IT. In a misleading announcement Apache chairman's Greg
    Stein implied JBoss was participating and that JBOSS CODE WAS PART OF
    THE PROJECT. No current JBoss developers are participating in the
    Apache J2EE project and since JBoss is LGPL only full copyright holders
    can offer JBoss code under other licenses. Bottom line? JBoss can't be
    forked by apache. As our customers know, we are a business, a serious
    one and we seriously believe in and defend "professional open source".
    That includes legal protection of IP. Make no mistakes, JBoss will
    AGGRESIVELY defend its copyright and LGPL license.
    "

     
    > Is this a branch of the 3.x or 4.x trees?

    Looks like neither, Apache cannot change the license on it.

    It's a brand new project without a single line of proven code in it yet.

    /T
  23. JBoss and Geronimo[ Go to top ]

    Alright, this may be a good news ... but what happen to JBoss core developer ( was ? ), such as David Jencks, Dain Sundstrom, Jeremy Boynes, Jasson Dillon, etc ? Are they still part of JBoss developer or 'partner' ? Have their CVS access have been revoked, like Andy Schaefer ?

    Just curious ...
  24. JBoss and Geronimo[ Go to top ]

    According to The Inquirer (one of my favourite morning reads, I have to say!), all four have had their commit rights removed.

    JBoss goes Corporate

    It looks very much like a predictable knee-jerk reaction from Marc F - and one that, in my opinion, will not help JBoss at all.

    On the other hand, the Geronimo project is excellent news - looks to have the right people involved, and has appeared at the right time in the growing maturity of the J2EE market, IMHO.

    I wish them the best of luck.

    /david
  25. JBoss and Geronimo[ Go to top ]

    Some cool reads about JBoss and their lost of developers
    http://www.eweek.com/article2/0,3959,1123080,00.asp

    http://www.eweek.com/article2/0,3959,1209799,00.asp
  26. JBoss[ Go to top ]

    According to The Inquirer (one of my favourite morning reads, I have to say!),

    > all four have had their commit rights removed.

    What I don't get is why do they keep whining to the press about the whole thing? They wanted to build their own business and they wanted to build their own server with Apache, what's with all this bitching, whining and finger pointing to your ex-employer?

    Grow up, kids. It doesn't look professional and certainly does not increase the credibility of what you're trying to do. You're acting like a bunch of spoiled teenagers.

    Plus it appears that the Inquirer writer is in bed with them too.

    /T
  27. license[ Go to top ]

    Can anybody enlights on what are the differences between
    BSD license, GPL, LGPL, MIT, Mozilla Public License ?
  28. license[ Go to top ]

    Check out these links.

    http://www.gnu.org/licenses/licenses.html
    http://www.gnu.org/licenses/gpl-faq.html
    http://www.opensource.org/
  29. JBoss[ Go to top ]

    <thomas>What I don't get is why do they keep whining to the press about the whole thing?</thomas>

    Are they? I've only seen three articles on l'Inq in the last month (or so). I guess what is one person's openness is another's whining - it depends on your perspective.

    <thomas>what's with all this bitching, whining and finger pointing to your ex-employer?</thomas>

    Wait a moment, this is still (ostensibly) an open-source project that we're talking about, not a company: They donated that code to the project and they weren't paid directly (AFAIK) for it. It's not really the same as a company-employee releationship now, is it?

    <thomas>Plus it appears that the Inquirer writer is in bed with them too.</thomas>

    Clearly. And to me it's great to have an inside track on the people who are involved in making the news. It's not overly concerned with being balanced, but there are plenty of other sites that regurgitate anodyne press-releases, if you like that kind of thing.

    <off-topic>
    For the exact same reason, my favourite current affairs programme is the BBC's From Our Own Correspondent, where the BBC's foreign correspondents are allowed to stop trying to be scrupulously balanced, and tell it as they see it.

    Yes, you get one person's opinion, but it is one from someone who is actually there (or was there - the reports are often filed after the correspondent has moved on to another posting and can consequently speak more freely).

    Anyway, the BBC's site is here, and it is often worth listening to the audio stream, because quite a number of the reports don't get typed up.
    </off-topic>

    /david
  30. JBoss[ Go to top ]

    It's not really the same as a company-employee releationship now, is it?


    Unless my memory is miserably failing, they were all listed as consultants working for the JBoss Group. I think that's a pretty typical company-employee relationship. As for the Inquirerer, they seem to make pot shots at JBoss Group -- not JBoss.org -- at every chance they get.

    It looks like adolescent behavior to me. Not to mention their relationship with this so called "reporter" that feeds forums like this seriously undermines their credibility. In my opinion. Yours may differ of course.

    I would have thought a group of young people starting their own venture would have much more important things to do. I would.

    /T
  31. JBoss[ Go to top ]

    <thomas>Unless my memory is miserably failing, they were all listed as consultants working for the JBoss Group.</thomas>

    Hmmmm - JBoss Group is a relatively recent entity - and one that, IIRC, was a primary element in their decision to fork from jboss. After all, when I attended a talk by Marc F some 18 months ago he seemed uncertain of the business/income model for jboss. (I tried then to convince him then that there was a model - based on the playstation model of subsidise the product, recoup on the related work - but this wasn't quite what I had in mind!!)

    Bottom line is that, yes they were consultants, but that post-dates their contribututions to the system - they were included in the group because of their work, not employed as such.

    <thomas>As for the Inquirer, they seem to make pot shots at JBoss Group at every chance they get.</thomas>

    C'mon - get with the programme - they do that with everyone (or at least all commercial groups - OSS they seem to like!).

    <thomas>Not to mention their relationship with this so called "reporter" that feeds forums like this seriously undermines their credibility.</thomas>

    OK - how else would you expect to find out that their commit privileges have been revoked? Get Marc F to email you and tell you?

    <thomas>I would have thought a group of young people starting their own venture would have much more important things to do.</thomas>

    My take on this is that they're typical OSS contributors - they do it for the enjoyment, challenge and love of it. The commercial aspects do not seem to be their primary motivation - it just pays the bills.

    /david
  32. JBoss[ Go to top ]

    Hmmmm - JBoss Group is a relatively recent entity


    According to their website founded in 2001.

    > not employed as such.

    According to their own statements they were, or is getting paid by JBoss Group not employment?

    > how else would you expect to find out that their commit privileges
    > have been revoked?

    I don't personally understand why it is even a news event or not expected. Most other businesses would have dropped them like flies on the day of their announcement. After all, they went all the way to the press to describe how they went "under-the-radar" to deliver this shocking blow.

    I was personally surprised of the amount of lenience JBoss Group was showing them, letting them continue in the project as if nothing had happened. Despite of the fact how they decided to make their departure. And they seem to continue the same type of misbehavior still today. That is the part that boggles me. They MUST have so many other important things to take care of that should take much higher priority.

    /T
  33. JBoss[ Go to top ]

    David: how else would you expect to find out that their commit privileges have been revoked?

    Thomas: I don't personally understand why it is even a news event or not expected. Most other businesses would have dropped them like flies on the day of their announcement. After all, they went all the way to the press to describe how they went "under-the-radar" to deliver this shocking blow.

    So it sounds like "JBoss the business" has a right to terminate their commit privileges? Obviously, it wasn't "JBoss the project" that terminated their privileges, because they were part of "JBoss the project".

    How can you have it both ways? It's either an open source project, or it's a business. You can't just select whichever skin is more comfortable for the problem at hand.

    Thomas, you (and Chip Tyler and Fredd Grott etc.) seem extremely worried by this new project. Is this project going to somehow hurt your own work? I am really wondering what the reason is for all of the negativity I'm perceiving. It almost seems that you guys oppose the right of people to contribute to whatever open source project(s) that they want to. Is there more going on behind the scenes that the rest of us are not aware of?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  34. JBoss[ Go to top ]

    So it sounds like "JBoss the business" has a right to terminate

    > their commit privileges? Obviously, it wasn't "JBoss the project"
    > that terminated their privileges, because they were part of "JBoss
    > the project".

    I find your separation confusing. The "project" never granted them any priviledges in the first place. It was the "business" that gave them the CVS access, so why cannot the entity that gave them the right to commit to the CVS take it away as well? Please explain. When did the rights of the people who maintain and manage the project suddenly disappear? You seem to be saying that once someone receives CVS privileges to a project they cannot ever be removed...? Is that correct?


    > How can you have it both ways? It's either an open source project,
    > or it's a business.

    No Cameron. You're confused. Open source is a license. It grants some specific rights to distribute and modify code. Comparing license to business is completely absurd.

    > You can't just select whichever skin is more comfortable for the
    > problem at hand.

    I really do not understand your logic in this case.


    > Thomas, you (and Chip Tyler and Fredd Grott etc.) seem extremely
    > worried by this new project. Is this project going to somehow
    > hurt your own work?

    At the moment, doesn't look like it. There clearly exists potential problems if people carelessly cross the boundaries between licenses (as would easily happen if one is too familiar with a LGPL codebase one does not own and thinks about recreating it under another incompatible license). I'm certainly not the first person to have such worries, it has been hashed back and forth between ASF and FSF many times over. I'm sure you can find the annals yourself.

    /T
  35. JBoss[ Go to top ]

    Cameron: So it sounds like "JBoss the business" has a right to terminate their commit privileges? Obviously, it wasn't "JBoss the project" that terminated their privileges, because they were part of "JBoss the project".

    Thomas: I find your separation confusing. The "project" never granted them any priviledges in the first place. It was the "business" that gave them the CVS access, so why cannot the entity that gave them the right to commit to the CVS take it away as well? Please explain. When did the rights of the people who maintain and manage the project suddenly disappear?

    So, for clarification, the project is rightfully owned and controlled by "JBoss the business"? They can allow or disallow anyone from participating? Are you sure that Marc wants you speaking for JBoss Group on these matters? The answers you're giving sound pretty scary to me.

    (Maybe what you said is normal for GPL and LGPL open source projects. I'm a bit worried by your answers though.)

    Cameron: Thomas, you (and Chip Tyler and Fredd Grott etc.) seem extremely worried by this new project. Is this project going to somehow hurt your own work?

    Thomas: At the moment, doesn't look like it. There clearly exists potential problems if people carelessly cross the boundaries between licenses (as would easily happen if one is too familiar with a LGPL codebase one does not own and thinks about recreating it under another incompatible license).

    So you are concerned that Apache will steal JBoss code? And that is your only concern? OK, I guess that could be a reasonable concern. I'm pretty sure that they understand the licensing issues pretty well, though, and probably have an ace or two up their sleeve when it comes to getting a "jump start" on a code base.

    BTW - What is your relationship to JBoss, if any? None? Simply a user? A contributor? An employee? (To reciprocate, I will say that I personally use JBoss at times, and at least a dozen or so of our customers use JBoss extensively with our Coherence product, so I consider myself both a user and an ISV with respect to JBoss, although we have no official relationship with JBoss the project or the business.)

    Thomas: I'm sure you can find the annals yourself.

    All I can say is: Thank God that Fred wasn't typing that sentence! ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  36. JBoss[ Go to top ]

    So, for clarification, the project is rightfully owned and

    > controlled by "JBoss the business"?

    Well, Cameron... They own the trademark, the website, and the project administrator rights at Sourceforge. So yes, looks like it to me. JBossGroup is JBoss (I mean, if they own the TM then how else is anyone going to call their version JBoss?)

    > They can allow or disallow anyone from participating?

    If they are the keepers and administrators of the project then yes... If what you are asking is if they follow the ASF style voting system that allows all committers to vote, then as far as I can tell they do not. JBossGroup is in charge of what goes into JBoss.

    It does make sense - thinking about it - if you're in the business of selling 'insurance' to companies in terms of support that you would like to know and understand exactly what is going on in your codebase, no?

    /T
  37. JBoss[ Go to top ]

    Looks like it is a good idea to start a j2ee implementation controlled by
    community.

    > > So, for clarification, the project is rightfully owned and
    > > controlled by "JBoss the business"?
    >
    > Well, Cameron... They own the trademark, the website, and the project administrator rights at Sourceforge. So yes, looks like it to me. JBossGroup is JBoss (I mean, if they own the TM then how else is anyone going to call their version JBoss?)
    >
    > > They can allow or disallow anyone from participating?
    >
    > If they are the keepers and administrators of the project then yes... If what you are asking is if they follow the ASF style voting system that allows all committers to vote, then as far as I can tell they do not. JBossGroup is in charge of what goes into JBoss.
    >
    > It does make sense - thinking about it - if you're in the business of selling 'insurance' to companies in terms of support that you would like to know and understand exactly what is going on in your codebase, no?
    >
    > /T
  38. Thomas: The "project" never granted them any priviledges in the first place. It was the "business" that gave them the CVS access, so why cannot the entity that gave them the right to commit to the CVS take it away as well?

    as far as i can remember: the project was in place quite long before the business.

    Thomas: When did the rights of the people who maintain and manage the project suddenly disappear?

    from another post:
    http://marc.theaimsgroup.com/?l=jboss-user&m=106023542516928&w=2

    i think this says it all.

    Thomas: You seem to be saying that once someone receives CVS privileges to a project they cannot ever be removed...? Is that correct?

    You seem to be saying that from the moment the project-lead starts to dislike your nose, your privileges should be removed regardless on what you contributed so far?

    Thomas: At the moment, doesn't look like it. There clearly exists potential problems if people carelessly cross the boundaries between licenses (as would easily happen if one is too familiar with a LGPL codebase one does not own and thinks about recreating it under another incompatible license). I'm certainly not the first person to have such worries, it has been hashed back and forth between ASF and FSF many times over. I'm sure you can find the annals yourself.

    same applies for the endless debate and guesses on when the jboss-group will start to change jboss to a closed license - which will become easier and easier with every cvs-commiter they scare away.

    just my 0.02$

    jan
  39. Project != business[ Go to top ]

    The problem with JBoss, as Cameron Purdy correctly noted, is that they try to market themselves as a genuine open-source project when in fact much of their operation is geared towards making money for Marc Fleury and other JBoss Group employees and contractors. There is nothing wrong in trying to make money out of a fine product; however, JBoss tries to mix the project and the business in a way that can hardly be called wholly ethical. There was probably no technical reason to revoke CDN members' CVS access. They did not, judging by the evidence available in this thread, try to sabotage the project in any way. JBoss Group's business interests, on the other hand, will for obvious reasons be served by the ban, as JBoss Group can now position itself as the sole source for JBoss services.

    Marc Fleury & co. should accept fair competition in the service space and restore the commit privileges of the individuals concerned.
  40. LGPL semantics[ Go to top ]

    As far as copyrights go, I think the only thing that the JBoss group "owns" is the registered "JBoss" trademark.

    There LGPL copyright does not restrict project forking, though in this case the new project would probably have to be under a name other than JBoss. Of course, if you fork it, and use the same code, typically you will have to LGPL or GPL that code as well.

    Anybody on the planet could rename the project and start working on the same code again with a new direction. Of course, all changes could potentially be incorporated back into the main JBoss repository.

    Also, let me tell you that any claims of being able to pull off copyright enforcement on JBoss' part are not necessarily all that definite. I've extensive discussions with legal sources as part of my work, where we often bundle open source projects, and some of the guarantees are pretty loose.

    The one thing that the JBoss project could guarantee in the event of a fork is that all changes and updates present in the forks will be available to them as well.

    I do not know of much existing case law in the area of GPL/LGPL licensing. The GPL and LGPL are reckoned by lawyers to be "mostly enforceable", provided there has been some sort of acknowledgement on the part of the licensee that they have accepted the terms of the agreement.

    http://www.ilaw.com.au/public/licencearticle.html had some interesting thoughts on some of this stuff.

    Personally, I think the Apache decision is a good one. Right now, it would be good to have a JBoss competitor, besides Jonas. And as far as taking years to get a production-ready server out the door, I don't think it will take that long for them to get some decent code out there. But that's just my opinion.

    Sandeep
  41. LGPL semantics[ Go to top ]

    There LGPL copyright does not restrict project forking, though in this case the new project would probably have to be under a name other than JBoss. Of course, if you fork it, and use the same code, typically you will have to LGPL or GPL that code as well.


    Oh, and don't forget - you can mix and match licenses in an overall distribution, provided all the licenses are compatible. So, theoretically speaking, you can have all the JBoss-derived pieces be LGPLed and the rest be any other license, even an proprietary, non-open source one.

    It's kind of tricky though - notions such as "linking with libraries" are sometimes not clear depending on the platforms, languages and technologies being used.

    Sandeep

    [LGPL Preamble] "When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library."
  42. LGPL semantics[ Go to top ]

    Well, here is a real case of GPL License Violation:

    http://miranda-icq.sourceforge.net/zeez-im/030718-license.html

    Let's see where this will end. I was also curious about what would happen when someone decided (intentionally or not) to break GPL license, like, who would be in charge of sueing (sp?), who would pay the costs, what kind of setences could be enforced by the judge, etc.

    Regards,
  43. JBoss[ Go to top ]

    "Thomas, you (and Chip Tyler and Fredd Grott etc.) seem extremely worried by this new project. Is this project going to somehow hurt your own work? I am really wondering what the reason is for all of the negativity I'm perceiving."

    Not at all. Although, Cameron, I think you do have a history of making rather negative comments on JBoss threads. Are you worried that JBoss is going to hurt Tangosol's business? By the way, can I have RW access to Tangosol's code, I mean in the spirt of openness, peace and love, and all that? Even in open source, I wouldn't want to use software that didn't have some sort of coherence, consistency and control mechanism for direct contributions.
  44. JBoss[ Go to top ]

    Chip: Although, Cameron, I think you do have a history of making rather negative comments on JBoss threads.

    I highly doubt that. Just because I don't accept everything about JBoss as The Word of God doesn't mean that I'm negative about JBoss. And I certainly was not being negative here. I am trying to find out something that is of great importance to many people that use JBoss and participate in the project, which is how decisions regarding "JBoss the project" are made. From the answers I have received from Thomas (who won't explain his own relationship with JBoss, so I don't know what credence to give his answers), it unfortunately appears that -- at times -- "JBoss the business" takes unilateral control of "JBoss the project".

    Speaking of which, do you have any particular relationship with JBoss the project or the business?

    Chip: Are you worried that JBoss is going to hurt Tangosol's business?

    Maybe if we buy BEA. ;-)

    Chip: By the way, can I have RW access to Tangosol's code, I mean in the spirt of openness, peace and love, and all that?

    If you were a Tangosol employee, yes you would have RW access. We have a pretty clear model, and haven't had anyone accuse us of doing something other than we say we do.

    Chip: Even in open source, I wouldn't want to use software that didn't have some sort of coherence, consistency and control mechanism for direct contributions.

    Yes, I understand that entirely, and of course I agree. However, the reason that they were removed as committers was that they announced the Geronimo project? Does that automatically mean that all of them want to stop contributing to JBoss? (One of them complained that he found out about his loss of committer rights only when he was trying to check in more contributions into the project.) Look, if they were trying to sabotage something, then say so. Otherwise, what is the reason for kicking them out? Open source is a "contribution model", and some of these guys were still contributing. If they write something, it is their right as the copyright holder to contribute it both to Geronimo (ASL) and JBoss (LGPL), for example.

    I do think I have a pretty balanced view of the situation (see "Turnabout is Apache Play".) In the end, IMHO, this particular decision just looks and smells bad. And don't for a second think that I'm being negative on JBoss because I say that I think a decision is bad. If you can't have a rational conversation like this without crying "FUD" then you should probably relocate to Jonestown.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  45. JBoss[ Go to top ]

    Cameron,
    Read your blog entry. I stand corrected.

    The real issue is two groups of people with different views of how you do open source. Neither one is wrong. I personally didn't find the RW thing shocking. Tangosol would not give RW access to a competing product even if you could give it to non-Tangosol employees. Whether it is proprietary or open source, software development teams pretty much function in the same way. There is a group dynamic that has to work and a control process that has to occur. Regardless of the other conflicts between dual projects, professional objectives and licenses, I wouldn't expect people who have such a clear dislike for each other to work together in any meaningful way--it would be counterproductive and negatively impact the project.

    The Apache people who used to work with JBoss have made it clear that they have very different objectives and want to move on. In my mind, that is exactly what they should do. Whining about RW rings like a hollow bid for public sympathy to me.
  46. JBoss[ Go to top ]

    Cameron:
    Maybe if we buy BEA. ;-)

    Note to self: Buy BEAS stock

    ;)
  47. JBoss CVS removals[ Go to top ]


    JBoss Group, as caretaker of the JBoss project, has recently decided to
    remove CVS access committers for a few of our committers. We do not remove
    from CVS without good reason nor without just cause. These are the reasons
    for the removals:

    1. These individuals have refused to discuss design issues on our public
    forums. It is crucial to have a public record of design discussions so that
    others may particpate in future work.

    2. More importantly, we have learned that they have forked JBoss. We also
    believe they are preparing to submit it, or some derivation, to the new
    Apache Geronimo project which would violate copyright and LGPL. Our proof?

    http://sourceforge.net/projects/elba

    3. There is just too much conflict of interest of developers working on two
    different J2EE projects that are being developed under two very different
    open-source licenses.

    JBoss Group believes strongly in the LGPL license and will protect all
    copyrights held by any JBoss contributor.

    XXXXXXXXXXXXXXXX
    Bill Burke
    Chief Architect
    JBoss Group, LLC
    XXXXXXXXXXXXXXXX


    It seem to me that this JBoss Group was in the right to remove CVS access. I would have done the same. I wish they announced the reasons at same time of removal and their PR abilities still seem a bit raw.

    I watch this CDN/JBoss Group struggle from beginning. From my point of view this looks like CDN first try to take control of business with their announcements before JavaOne in June. I was very surprised JBoss Group did not remove their CVS access then. Now CDN try to take control of JBoss project by their fork. All disgusting moves that just show jealousy and greed. This move by CDN to fork just shows their selfishness as this is clearly not good for hte JBoss community. Their egos seem bigger than Mr. Marc Fury.

    I do not like though that JBoss Group has removed these people from team page. They could have at least moved them to the retired section.

    Just my two Euro cents,

    Ciao,

    Hans
  48. Reasons for fork, as i see it[ Go to top ]

    Hans,
    I also watch this since the first announcement of CDN creation was made.
    Let me give a different point of view on what's going on.

    CDN was created by those members of the project who wanted to concur with JBoss Group in JBoss services. Were they happy doing this? Definitely. Why? We'll never know, I guess. Is their move fair? Yes. Is it legal? Yes.

    JBoss Group's immediate response was a little tough but fairly acceptable, too, IMHO.

    I guess after this some undercover moves from both sides began.

    As first visible result we got CDN memebers refused to participate in JBoss developer forums. Let me assume that the reason was clearly explained: these forums are been hosted on the JBoss Group's, not the JBoss project's web site. Everything written there can become the JBoss Group's IP. Is this appropriate for those who feel a mistrust between them and JBoss Group? Never, I guess.

    As a second result, we got a Geronymo announcement, and got a JBoss fork (project 'alba') _created_to_die_.
    The only reason as I see it, was to get a current snapshot of JBoss 3.2.2 code (licensed mostly under LGPL).
    Let's see. To donate their code to Geronimo, CDN folks have to change the license from LGPL and Artistic to the ASL. To do this they shall get approval from everybody who wrote this code, including patches.
    They can check all the previous code revisions authority for any chunk of code at Sourceforge CVS as anybody else can do, and find out if they can change it's license terms and donate.
    They can also ask permission to do so from independent coders and can get such approval from some of them.
    And now the point: JBoss Group memebers are not able to make any changes to a fork. Let's assume that after Geronymo announcement JBoss Group members start making small changes to the source code created and maintained by CDN folks. This code can not be donated to Geronimo without their permission which never could be obtained, and it would be time consuming to get the previous revisions not touched by the JBoss Group folks. This fork just saves the time and has nothing common with stealing alliens IP as JBoss Group folks worry about, because saving the Apache Software Foundation's high reputation requires checking of IP rights for the code donated to their projects, and I am positive, this will be done in this case with double accuracy.
  49. Well... the reasons, IMHO, are always regarding the same old thing: money. Whenever great amounts of money are in stake, you can be sure differences will show up. Pity. All this fighting is staining some good names in OS community, for sure. IMHO, the mixing of business and OS projects still has a long way to go, until they find some way to coexist without so many problems. Or maybe it will never be possible, because of fundamental differences in business' and OS's philosophy.

    Regards,
  50. Forking should be OK[ Go to top ]

    I watch this CDN/JBoss Group struggle from beginning. From my point of view this looks like CDN first try to take control of business with their announcements before JavaOne in June. I was very surprised JBoss Group did not remove their CVS access then. Now CDN try to take control of JBoss project by their fork. All disgusting moves that just show jealousy and greed. This move by CDN to fork just shows their selfishness as this is clearly not good for hte JBoss community. Their egos seem bigger than Mr. Marc Fury.

    Don't forget that licenses such as the LGPL are explicitly designed to allow forking. If you don't like the current management of a project, just take the code and start a project of your own. This idea is central to how open source works. I see little wrong in forking JBoss. Two projects built on the same code base can compete and borrow from each other, leading to faster development and more choice for the customer. This is not profiting from the work of others. CDN members were significant contributors to the JBoss effort and, more important, every contributor who placed his/her work under the LGPL expressly acknowledged that forking of the code may occur.

    It would be wrong, of course, to put the LGPL'd code under the ASF without the contributor's approval. Mr. Burke offers no direct support for his claim that "we also believe they are preparing to submit it, or some derivation, to the new Apache Geronimo project"; if they are planning to do that, I trust they would seek approval of the relevant persons. JBoss Group members cannot be expected to give such approval, though, so only parts of the code base would probably be donated.

    Bill's "conflict of interest" claim is also less then foolproof. As I wrote above, two projects working on the same code base can definitely co-exist happily. If the relationship turns out to be problematic -- if clear sabotage were to occur, for example -- then revoke CVS commit privileges. Do not do that based on mere speculation.

    It is mildly ironic to note Bills' words "JBoss Group believes strongly in the LPGL license", when their actions show they do NOT understand the nature of the LGPL, and instead try to squash legitimate competition in the open-source application server arena.

    Pietari Laurila
  51. Forking should be OK[ Go to top ]

    | It is mildly ironic to note Bills' words "JBoss Group believes strongly
    | in the LPGL license", when their actions show they do NOT understand the
    | nature of the LGPL, and instead try to squash legitimate competition in
    | the open-source application server arena.

    Ho hum.

    LGPL is a license. Let me repeat that again. LGPL is a license. License that exists to grant additional rights to use, distribute and modify the source code that would otherwise be restricted by the author's copyright.

    What is the "nature" of the LGPL license? It's nature is how it interacts with the intellectual property laws of a given country. To "understand the nature of the LGPL" -- as you put it -- means to understand its legal implications to IP law.

    To put this differently: the nature of LGPL license DOES NOT have anything to do with project management. It DOES NOT have anything to do with granting or revoking CVS rights or does it have ANYTHING to do with how to manage relationships between different business entities. All these qualities above and beyond IP law that you are assigning to the LGPL license do NOT in fact EXIST.

    License != Project Management && License != Copyright && License != Business Model

    You should do well to visit FSF and educate yourself about the different licenses and educate yourself with the IP law of your country of residence before you start lecturing others about "the nature of the LGPL license". As it stands, its nature is strictly and ONLY bound to IP law. Anything else is purely a figment of your imagination and uneducated assumptions you've made based on PROJECT MANAGEMENT, not IP LAW.
  52. Forking should be OK[ Go to top ]

    You should do well to visit FSF and educate yourself about the different licenses and educate yourself with the IP law of your country of residence before you start lecturing others about "the nature of the LGPL license". As it stands, its nature is strictly and ONLY bound to IP law. Anything else is purely a figment of your imagination and uneducated assumptions you've made based on PROJECT MANAGEMENT, not IP LAW.


    Um, Thomas, I don't think you and the fellow you're replying to are talking about the same thing. The way I read it, he is talking about IP as well, as well as about the consequences of its ownership, about copyrights relating to it, and access to its manifestations. Intellectual property is not always an intangible thing. Managing source code, including access to it, rights to change it, rights to use the changed code etc. are all relevant consequences of the LGPL license.

    Both the GPL and the LGPL extensively discuss these sort of things.

    Sandeep.
  53. Forking should be OK[ Go to top ]

    Managing source code, including access to it, rights to change it,

    > rights to use the changed code etc. are all relevant consequences
    > of the LGPL license.
    >
    > Both the GPL and the LGPL extensively discuss these sort of things.

    Two things:

    1) Everyone can access and change the JBoss code. Nothing has changed with regards to that.
    2) There's no section in the LGPL that says that everyone must be allowed write access to the same CVS repository. This is purely project management and clearly outside the scope of LGPL and GPL.
  54. Forking should be OK[ Go to top ]

    As the header says, forking should be (and is) OK under LGPL.

    On the area you quoted, it was clear from context (at least to me) that Bill and Marc and JBoss Group can't threaten legal action just against someone just forking LGPL code and then modifying it. You also can't threaten legal action for things for which you don't own the copyright - and it's not clear what JBoss Group can claim copyright to, and what individual developers (like CDN) people have rights to.

    Certainly things like CVS access and project management aren't part of the LGPL. But at the same time, if a group of project owners (like the larger JBoss community) don't play nice with each other, a subset of that group is entirely within its rights to fork the codebase and go off on their own. The only restriction is that the source code to such endeavours be available under LGPL. And that can be waived by people who own copyright to specific bits.

    Lastly, you've stated alot about IP law - but please cite me _actual_ LP law that has anything to say whatsoever about the GPL or LGPL. As far as I know, both licenses have yet to be tested in a court of law. In fact the legal community doesn't really know what will happen when/if someone tries to test it.

         -Mike
  55. Forking should be OK[ Go to top ]

    Besides the fact that there is no such thing as "IP law" ... copyright law says you don't have the right do copy an original work without the authors permission. As far as I know, there is nothing in the actual copyright statutes which limit what the author can ask for to get permission to copy an original work (obviously the author cannot ask for something which would cause you to be committing a crime). If the author wants you to give him $100,000,000 that is his right. You may or may not agree with the terms and as such, you have every right to not participate in the contract. What does this have to do with the GPL? Basically, there is no need to "test" the GPL. It's a contract which, unless you enter, you have no legal rights to reproduce the GPL'd work. What may need to be tested are the individual clauses of the GPL, specifically those which govern "linking" and "deriviative works" since both of them use what can be considered somewhat non-standard definitions. I highly doubt, however, that you'll get a court to overturn the basic premise of the license which says "if you redistribute this you need to provide the source code, including the source to any modifications you made". Especially since any modifications you made directly to the source itself are clearly deriviative works.

    In other words, there isn't much to test in a court of law in respect to the GPL and LGPL. If there was, you would have seen big companies with lots of lawyers like IBM and Microsoft running all over it years ago. And the only comments from lawyers I have heard are from lawyers from foreign (i.e. not the United States) countries stating that copyright law is different enough there that the license might not be enforcable or lawyers stating (as I did, not that I'm a lawyer :-) that a court might interpret some of the less explicit sections and sections that differ from common usage of the contract differently then the FSF does.
  56. Forking should be OK[ Go to top ]

    \Chris Conrad\
     Basically, there is no need to "test" the GPL. It's a contract which, unless you enter, you have no legal rights to reproduce the GPL'd work. What may need to be tested are the individual clauses of the GPL, specifically those which govern "linking" and "deriviative works" since both of them use what can be considered somewhat non-standard definitions. I highly doubt, however, that you'll get a court to overturn the basic premise of the license which says "if you redistribute this you need to provide the source code, including the source to any modifications you made". Especially since any modifications you made directly to the source itself are clearly deriviative works.
    \Chris Conrad\

    When something "new" pops up that isn't adequately covered by past precedents and laws, it's legal status is always a little bit up in the air. "New" may be a new technology, a novel new way of doing business...or a new way to license software. The GPL is "new" enough in what it tries to do beyond normal copyright practices that, as I said, nobody really knows what will happen if someone challenges it.

    This is made really, really complex in the general open source world with multiple independent contributors plus corporations. In normal copyright situations, you end up with two possibilities. One, all work is done within a corporation, and individuals sign over their patent/copyright rights to the corporation. Two, an individual or very small group creates a copyrightable work. In this case, you've generally got a static work, like a book or a song, which somebody banged out and is clearly owned by a person or small group of people.

    In an open source project, who "owns" the copyright? If "Joe" creates foo.java,and Bob and Laura and Alice modify it in some form (perhaps even copies a piece of foo.java to another file, and deletes foo.java due to refactoring), who "owns" foo.java (and bits and pieces of foo.java that have scattered hither and thon).

    The law is much more subtle and complex than you make it out to be, and things are not nearly as cut and dried.

    \Chris Conrad\
    In other words, there isn't much to test in a court of law in respect to the GPL and LGPL. If there was, you would have seen big companies with lots of lawyers like IBM and Microsoft running all over it years ago. And the only comments from lawyers I have heard are from lawyers from foreign (i.e. not the United States) countries stating that copyright law is different enough there that the license might not be enforcable or lawyers stating (as I did, not that I'm a lawyer :-) that a court might interpret some of the less explicit sections and sections that differ from common usage of the contract differently then the FSF does.
    \Chris Conrad\

    I disagree. Part of the issue is that there isn't all _that_ much interesting (emphasis on interesting!) GPL/LGPL software in the world beyond Linux. There's a huge amount of Apache/BSD style licensed stuff out there, where the license is so liberal that it doesn't pose a problem to anyone wanting to use that stuff. The only issue is the relatively small world of GPL/LGPL stuff.

    In that world - the fact that IBM, Microsoft et al haven't challenged a GPL license doesn't mean that the license can't be challenged. All it means is that they haven't found a reason to so far. Secondly, I'd bet my bottom dollar that there are _many_ uses of GPL code that go against the license, but nobody has noticed (or cared). The problem is, unless a product is very high profile and in wide use, how can you tell if something uses a bit o' GPL code in binary form? If someone takes GPL stuff, creates a product, and sells it to 10 customers, do you think those ten customers are going to go through it with a fine toothed comb to look for GPL code?

    My point isn't that this is a good thing, or to even say how widespread it is, but to point out that proving a GPL license violation can be rather hard to do. Further, as I mentioned, figuring out who owns a piece of GPL'd code can also be rather difficult. It's even more difficult if you consider that standards have a tendency to constrain the possible solution set, so that vendor A's JMS code may look suspiciously alot like Vendor B's JMS code in some portions (for example).

    Lastly, as long as you don't change the license and you make the source code freely available, other people can do pretty much whatever they want with it, including copying it wholesale, renaming it "Foobar AppServer", and making minor or extensive changes to it. You're only going to trigger a GPL 'violation' if you try to change the license or don't distribute the source - which in and of itself makes the number of possible GPL test cases rather small. This is even more true if you end up with a code base which is part BSD-style license and part GPL/LGPL - in such a code base, which license "wins"? Can BSD dominate and magically flip the GPL code to BSD, or can the GPL dominate the BSD code and reverse their license, or do neither code bases "win" (and therefore possibly violate the GPL's derivative works clauses implicitly)? Imagine 50,000 lines of GPL code, 50,000 lines of BSD-style code, and each is changed to make a source-level call to the other (thereby linking them together at the source level), and combined in one in source form bundle. Which license wins? Is my BSD code forcibly pulled into GPL because of one line of code, or is my GPL code negated by another one line of code, or do those two lines of code not matter and both pieces are still considered seperate?

    As I said, things are a bit more complex then you've led on, and until an actual court makes an actual ruling one way or another, nobody knows how these sorts of issues will play out.

        -Mike
  57. Forking should be OK[ Go to top ]

    I'm sorry but this is quite clearly covered by past precedents and rulings. A copyright holder can license his orginal work however he or she feels fit. Unless you can find a hole in the contract itself or there is something in the copyright statutes of the district you are in that limit the terms of the license in some way then there's not much to talk about. The GPL doesn't try to do anything beyond normal copyright practices, it is a simple contract which, unless you agree to, you have no right to copy the software. This isn't an EULA which is trying to go beyond what normal copyright law allows. Furthermore, if you don't agree to the GPL then you're commiting willful copyright infringement. Unless you have a better argument then "it's a new contract" then you're not being very persuasive.

    Multiple copyright holders is not a particularly complex subject. The person who wrote the code holds the copyright. The fact that code is removed in a new version is irrelevant, the code that was removed is still owned by the orginal contributor, the new code is owned by the new contributor. This isn't even uncommon in the commercial software world. The SysV Unix license which IBM has (see the attachments to the original and ammended SCO complaints) quite clearly state that AT&T owns the SysV code, IBM owns whatever they produce. The fact that it happens on a larger scale in open source development makes it no more or less confusing.

    IBM's countersuit against SCO includes a complaint for breach of the GNU GPL. Linksys has recently been forced to provide the source code for their modifications of Linux which they use in their linux powered hardware. The FSF, I'm sure, will provide you other cases where a company has voluntarily released or modified their code due to a GPL violation. It's no more difficult to find a GPL violation then it is to find a violation of proprietary code, it's just easier to violate GPL code. That, however, is completely irrelevant to the fact that it is a copyright violation. Since, under normal circumstances, you have no right to reproduce someone's work without a license and the only license it's available is the GPL, you'd be hard pressed to find a court which will just let you violate the license and continue to distribute the copyrighted work. Even if the license is deemed invalid, the disputed work will fall under normal copyright law where you have no right to redistribute it.

    Although you attempt to cloud the issue, it's very simple. Without a license you can't copy a copyrighted work. If the only license it's available under is the GPL, then you have to agree with it. How, exactly, do you think an entity could argue their way out of copyright infringment? Saying, well, I didn't know who the copyright holder is isn't going to work. Saying, well I don't think the license is valid isn't going to work. Both of those cases would be an instance of willful copyright infringment which can result in treble damages. Unless you have some novel case law which shows courts regularly overturning the license under which a copyrighted work is under then I don't think there is much to worry about when it comes to the GPL.

    I will note again, as I did in my original post, that all of this doesnt mean that a court might interpret portions of the license differently then the FSF does. That however, does not change the fact that courts have traditionaly included the intent of the copyright holder in their interpretation of license terms.

    Oh, and your final point about the BSD and GPL code being mixed just shows a lack of knowledge of standard contract law. In that case you are being provided a derivative work which is covered under two licenses. Since the GPL is more strict, it will "win" when it comes to the derivative work as a whole. In reality, neither of them "win", you simply have to satisfy all the conditions of all the licenses the code is under. The FSF's website even includes a list of licenses which are "compatible" with the GPL. By "compatible" they mean that both licenses can be satisfied concurrently. If both licenses can't be satisified then you would end up in a situation where the work cannot legally be redistributed (which was the case with KDE before Trolltech GPL'd Qt). The individual bits are still covered by their individual licenses.

    If you wanted to show a confusing situation when it comes to licensing copyrighted work you should have talked about a dual licensing scheme or something of that nature. Just about everything you've brought up is fairly straightforward contract law.
  58. Forking should be OK[ Go to top ]

    Furthermore, if you don't agree to the GPL then you're commiting willful

    > copyright infringement.

    Correction, "Furthermore, if you [copy the software and] don't agree to the GPL then you're commiting willful copyright infringement.".

    You're perfectly free to reject the GPL, but you lose the benefits of being able to copy the software because the default copyright license doesn't allow copying without the author's explicit permission.
  59. Forking should be OK[ Go to top ]

    Yes, of course, I had assumed mistakenly assumed that I was clear that I was talking about redistribution. Specifically, the GPL doesn't address usage at all. It is purely a redistribution contract which interacts with copyright law in a simple well defined way. Thank you for clarifying that. =)

    I also should have been also pointed out that, one of the more subtle nuances of copyright law is that in order for you to be able to claim copyright on a modification, your modification needs to be substantial. I don't think there is any clear definition of what a substantial modification is, however. So in the case of person A modifying person B's code, person A will own the copyright on the modified portion if the modification is substantial enough to be worthy of copyright protection. Otherwise, person B would still own the copyright for the entire work. I'm sure that some small trivial cleanup like fixing misspellings in a comment or a one line fix wouldn't be substantial enough, but I couldn't tell you where the dividing line is. I would think that the line is derived by the scope of the modification and possibly the size of the original work, but that is pure speculation. Having worked in a company that was dealing with copyright assignment, I remember our lawyer pointing out that things like localizing software isn't substantial enough since there is no actual creativity in the work. It was certainly hard, time consuming work to translate all the strings, but it wasn't enough. You should always consult your own lawyer before deciding what is or isn't a big enough modification in which copyright assignment might be an issue.
  60. Forking should be OK[ Go to top ]

    Chris, everything you're saying makes sense except for one small aspect - GPL (and to a lesser extent LGPL) attempt to extend their license to code not written under the GPL. If I take 5 source files from a GPL system and embed it into a system of 5,000 files, and change one of the original 5 files, and attempt to distribute it, GPL claims that all 5,005 files are now GPL. This is rather novel compared to normal copyright laws.

    As to ownership, much of what you say is true, and claiming ignorance of ownership isn't a defense. At the same time - ownership isn't always clearcut, and your statement "The fact that it happens on a larger scale in open source development makes it no more or less confusing" is a bit ridiculous. In many cases ownership is not "clearcut", and court battles have raged on over exactly who owns what. This is especially true if someone claims ownership and it is disputed.

    To your statement: "you have no right to reproduce someone's work without a license and the only license it's available is the GPL, you'd be hard pressed to find a court which will just let you violate the license and continue to distribute the copyrighted work"...you're completly missing a fundamental point of contract law. The license itself can be found to not be legally blindly since it conflicts with other points of law. You cannot, as you insinuate, make up any copyright terms you wish, they must be _legal_ copyright terms. And it is not at all clear in the courts that it's legal for a GPL license to be extended to non-GPL work via a derivative work clause.

    "Oh, and your final point about the BSD and GPL code being mixed just shows a lack of knowledge of standard contract law".

    Actually, it doesn't. You say (again) that things are clear cut, but they are not. Put the examples I specified in front of a judge and he may have a very, very different opinion than you do. The fact is that the very definition of "derivative work" can be difficult to pin down, and my example purposely skirts that line. A judge could quite reasonably rule in such a case that GPL terms only apply to the owners' copyrighted code, and cannot reasonably be extended to code owned by others under other licenses (because it would violate the contract and rights of the ownership of the non-GPL code). In my example of 50,000 lines of GPL, 50,000 lines of BSD, with a few changes on both sides, imagine the "few changes" and packaging of the two is done by a third party. The third party can legally take the source to, and change, both BSD style and GPL code. They can redistribute such code as well - _but under what license_? FYI, this is not clear-cut. It is clear that I can take "virgin" BSD and GPL stuff, and create a patch for each side (under respective seperate BSD and GPL licenses), and create instructions for someone to combine these in a whole. In this case I'll have two original packages (a BSD style and GPL style), two "patches" respectively under BSD and GPL, and a final document on how to put them together. None of this violates any license and doesn't involve distributing code, but it has the same effect - the GPL code is isolated and doesn't effect the BSD code in the least (no, the most restrictive does _not_ necessarily win!), and yet the two code bases are effectively linked via the patches. This is an impractical concept in the pre-software world, but emminently practical for software.

    In fact, the Geronimo people could take exactly this approach. Legally fork JBoss, create their own seperate BSD-style code, then release BSD covered patches and GPL covered patches to hook the two together, with instructions on how to do so (it may even be possible to automate this, on that I'm not sure).

    As an aside - if contract law were as crystal clear as you claim, I'm quite sure we wouldn't have quite so many laywers out there making six figures.

        -Mike
  61. Forking should be OK[ Go to top ]

    Again, you're trying to go and make this complicated and cloud the issue. The GPL and LGPL doen't attempt to extend thier license to anything. The GPL and LGPL say that in order for you to reproduce this code you much voluntarily release your derivative work under the original license. You have no legal right to take 5 source files from a GPL program and embed them in anything without permission from the original author. The original author says that in order to do that you have to release your entire program under the GPL. You can either agree or disagree, but you cannot just take those 5 files. And, as a matter of fact, that isn't at all novel. The original AT&T SysV license stated that any modifications made to the SysV code is owned by AT&T. Other licenses like the Apple Public Souce License and the Netscape Public License made similar claims. In your example you can either agree to the license or you are commiting willful copyright infringment. So, again, unless you can show that the license isn't valid in your district or can find a loophole in the license there is no good, legal theory as to why the GPL isn't valid.

    As to ownership, yes, people have battled in court over who owns what. But when there is a name, email address and clear copyright statement (whether directly in the code or easily obtainable through source control logs) where is the confusion? Changing the subject and talking about ownership disputes doesn't make my original point about having multiple owners any less valid.

    As I stated several times, if you can find a reason in your district as to why the GPL cannot be applied then do so. I also stated in my original post that the license cannot force the person to break other laws in order to satisfy the license. And again, the GPL doesn't apply itself to a non-GPL work. The GPL applies itself to the original work. In order to use that original work you must satisfy the GPL. In order to do that you must either GPL your work or you must not use the code in the GPL'd work. Please give me an example of where exactly the GPL attempts to stake claim over someone else's code. However, a court would probably not force a company to GPL their work if they were found to be committing copyright infringement. What would happen (based on what normally happens with commercial software) is that the infringer would be given an amount of time in which to remove the infringing work. That is prefectly valid and the FSF has allowed that resolution of a dispute in the past. By removing the code, they are no longer infringing the GPL. Depending on the circumstances, the original auther may also receieve damages due to the infringment. Note that I never stated that a company would be forced to open source their code if they infringe on the GPL. I've simply stated that there is no reason to think that the GPL is not valid and wouldn't stand up in court.

    You can attempt to make the discussion as complicated as you want, but it still isnt complicated. If a work contains code licensed under two different licenses (the amount of code still doesn't matter) then in order to redistribute it you need to simultaneously satisfy both licenses. If you can't do that then you cannot distribute the work as a whole. Now, code A licensed under license A is still licensed under license A. The fact that it's distributed with code B under license B doesnt change that. Code B under license B is still under license B. You, as a third party can choose to use only code A under license A, that is perfectly valid. But to distribute the code as a whole, you have to simutaneously satisfy all the licenses. As far as a third party going and redistributing the code, since you have failed to state any specifics it is impossible to answer what will happen. If you are combining two works into a third program then it is a derivative of the two original works and would need to be licensed under both licenses (assuming, of course, the the licenses are compatible, if they aren't you cant distribute it at all). If you're talking about something like a linux distribution then you've created a brand new collective work which can be licensed under any license you want. The original pieces within the collective still retain their original license and the distributor of the collective needs to honor them. For example, Red Hat takes bits and pieces under lots of different licenses and licenses the whole thing under the GPL. You can take one of the BSD programs and make it proprietary since it's still under the BSD. Combining two licensed works or distributing a collective work is still not new in copyright law.

    No matter what the example, however, the license underwhich a program is distributed does not change when you modify it or redistribute it as part of a collective. It doesn't matter how you modify it or what you combine it with. The only person who can change the license on a piece of code is the original author(s). In your example, a judge would only apply the GPL to the GPL'd part of the work. But to distribute the entire work as a single piece of code you'd need to simultaneously satisfy the GPL and BSD. Copyright law is very clear: The license that applies is the license the original author put the code under. There is code under several different licenses in the Linux kernel. Each of those licenses are compatible with the GPL. The work, as a whole, must be distributed so as to satisfy, simultaneously, all the liceses the complete work contains. Individual bits of code are still licensed under the license the original author put it under. Note that this is how you can include BSD code in a proprietary work. The BSD license doesn't magically disappear, it just happens to say that you don't need to redistribute the code.

    If you'd like an example from the commercial world of you can take MacOS X. They used the open source Mach microkernel, the APSL'd Darwin code, the LGPL'd KHTML renderer, BSD licensed utilities and purely proprietary code from several different companies, mixed it together and out comes OS X. How can they do that when there are so many different copyright holders and licenses? It's because it's simple, Apple can simultaneously satisfy all the licenses of all the code it's distributing.

    As for Geronimo, the only reason that they can't use the LGPL'd fork is that the ASF requires the use of the Apache license on all it's products. Otherwise, they could take JBoss, fork it and contribute patches under a variety of different licenses (as long as they are compatible) and all would be happy. It's purely a policy thing which prevents them from doing that.

    To summarize, the license an auther puts his code under can only be changed by that author. If you can't satisfy that license you have no right to redistribute the code. That doesn't change if you modify the code, combine it with other code, etc, etc.
  62. Forking should be OK[ Go to top ]

    First off, it must be nice to live in the black and white universe you inhabit. The one I'm in is a bit more complex.

    For example, you say:
    "The GPL and LGPL doen't attempt to extend thier license to anything. The GPL and LGPL say that in order for you to reproduce this code you much voluntarily release your derivative work under the original license."

    What the GPL actually say:

    "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. "

    Clearly, according to the above, if you include any GPL code in anything you publish, the GPL mandates that you can only do distribute _your copyrighted_ work under _the GPL license_. Note the emphasis. Note also that the GPL does not contain the word "derivative work", which you use repeatedly. "Derivative work" has a legal definition. GPL does not say that - it says "...in whole or in part contains or is derived from the Program or any part thereof".

    Please attempt to understand how "any part thereof" differs from "derivative work". If I a paragraph from a copyrighted work it's called "fair use". If I copy a method from a GPL code base and distribute, suddenly my whole program has to be GPL. Please note the difference.

    "The original AT&T SysV license stated that any modifications made to the SysV code is owned by AT&T"

    Yes, and so what? Their license is a pretty simple case of defining derivative work. Where the GPL is special is in that it says, in effect, "this code is free, and if you use and distribute it any code that's packaged with also has to be free". Note that the SysV license et al say nothing about non-AT&T code.

    "So, again, unless you can show that the license isn't valid in your district or can find a loophole in the license there is no good, legal theory as to why the GPL isn't valid. "

    The questions revolve around issues like "what is a program", what does "linking" mean, "what is a derivative work", "when do changes render a piece of code no longer under the ownership of the original writer", and "can a copyright license force itself to apply to code not owned by the licenser". These are not clear cut issues, not in our legal system at least (perhaps in yours?).

    You go on to say:

    "And again, the GPL doesn't apply itself to a non-GPL work. The GPL applies itself to the original work"

    This is pretty much completely incorrect. The GPL applies it self to any work which contains any amount of GPL in it which someone then attempts to distribute.

    " As to ownership, yes, people have battled in court over who owns what. But when there is a name, email address and clear copyright statement (whether directly in the code or easily obtainable through source control logs) where is the confusion? Changing the subject and talking about ownership disputes doesn't make my original point about having multiple owners any less valid."

    OK, if it's so simple, here's a test. Go to elba.sourceforge.net, find the JMS XAResource source code. Now - tell me who owns the copyright to that. Sorry, the copyright banner doesn't help - people have applied patches through CVS who were not the original copyrighters and did not assign their rights. Also, people can remove the copyright notices altogether and it's still LGPL. Code can also bounce from server to server (like, say, from SpyderMQ's CVS to JBoss CVS to Elba CVS). So, please, this is such an easy task - please tell me who owns the copyright to that one little piece of the code.

    "You can attempt to make the discussion as complicated as you want, but it still isnt complicated. If a work contains code licensed under two different licenses (the amount of code still doesn't matter) then in order to redistribute it you need to simultaneously satisfy both licenses. "

    I appear to dislike thought experiments (they must not work in the black and white universe), but try this on for size: what if you "released" a work with two licenses - BSD-style for the BSD-style bits, and GPL for the GPL bits. You claim that GPL does not apply to non-GPL works, so please explain how I could do the above. My BSD-style code is my own, and I wish to distribute it as BSD-style. I'll keep the GPL stuff "off on the side" as GPL-only. How do I do this?

    " But to distribute the entire work as a single piece of code you'd need to simultaneously satisfy the GPL and BSD."

    Ah, the black and white world again. Back in the less contrasty universe, please define "single piece of code".

     
    "If you'd like an example from the commercial world of you can take MacOS X. They used the open source Mach microkernel, the APSL'd Darwin code, the LGPL'd KHTML renderer, BSD licensed utilities and purely proprietary code from several different companies, mixed it together and out comes OS X. How can they do that when there are so many different copyright holders and licenses?"

    Excellent example! And your answer isn't quite right. The reason they can do that is actually because of the fuzzy definition of "single piece of code". The questions you've avoided are where is the single piece of code line drawn.

    "Note that this is how you can include BSD code in a proprietary work. The BSD license doesn't magically disappear, it just happens to say that you don't need to redistribute the code. "

    No one takes issue with a BSD-style license - there's no monetary cost, and no other requirements other than acknowledging the original authors. In business terms, this is called a slam dunk. GPL is an entirely different story, and at issue is what happens if you mix GPL stuff with something like BSD stuff. You seem to claim that a GPL license can legally dominate a BSD license, and then go on to contradict yourself talking about "individual bits of code". In case you missed it, GPL does not apply to individual bits of code - it applies to an entire "program", including non-GPL stuff (whatever a "program" is).
     
    "As for Geronimo, the only reason that they can't use the LGPL'd fork is that the ASF requires the use of the Apache license on all it's products. Otherwise, they could take JBoss, fork it and contribute patches under a variety of different licenses (as long as they are compatible) and all would be happy. It's purely a policy thing which prevents them from doing that."

    Remember, this is the less contrasty universe, and the facts are a little harder to discern. In case you missed it __the Geronimo team has forked the JBoss LGPL code, and intends to use it as part of Geronimo__. They are, in fact, pretty much doing what I described in one of my thought experiments (but I supposed you missed it). The subtly, again, is in the definition of "what is a program". This as it turns out is rather tough to deduce in a dynamic classloader system like Java.

    "To summarize, the license an auther puts his code under can only be changed by that author. If you can't satisfy that license you have no right to redistribute the code. That doesn't change if you modify the code, combine it with other code, etc, etc."

    To summarize - my question, which you haven't answered, is "can someone else's license affect work they do not own?" This is what the GPL attempts to do.

    To use a more specific example - if I want to use an author's short story in an anthology, I have to secure that right from the author. OK, fine. But please show me an example where that author's ownership of the short story can in _any_ way apply to other works in the same anthology? Please point to one example (please, outside of software!) that has a license like the GPL which attempts to affects the rights of works not owned by the original copyright holder.

      -Mike
  63. Research on GPL et al[ Go to top ]

    As an aside, you may want to research the feasibility of software licenses like the GPL and LGPL through avenues such as Google. It can be difficult - Linux and FSF sites dominate the search results, as well as rabid Microsoft vs. Linux debates. But there are kernels of real information in there if you dig far enough.

    Examples include worries about GPL's legality in German law, analysis of its applicability in French law, as well as analysis of enforcability in US law.

    To whet your whistle, here's one quote:

    \Harvard University\
    UCC Article 2B attempts to curtail the possibility that licenses will be enforced which contain "impermissible" or "unconscionable" clauses --- clauses which run against the grain of expectations of either party involved in the license, or are particularly bizarre or oppressive. Viewed one way, the intent of the GPL to free the basic material of intellectual property (the program source code and any modifications made to it), while allowing the author to retain copyright ownership, could be viewed as "unconscionable". Indeed, the draft of Article 2B contains the proposed text:

    SECTION 2B-110: IMPERMISSIBLE CONTRACT OR TERM.
    (a) If a court as a matter of law finds the contract or any term of the contract to have been unconscionable or contrary to public policies relating to innovation, competition, and free expression at the time it was made, the court may refuse to enforce the contract, ... [rest omitted]

    This clause dealing with "public policies relating to innovation, competition, and free expression" appear to be targeted directly at licenses such as the GPL, which in effect prevent any author from exercising intellectual property rights on GPL-code derived works. As such this might be considered as running contrary to innovation and competition, as the author is unable to gain directly from the intellectual property itself --- Richard Stallman's intent here is that programmers using the GPL would benefit from activities such as consulting, not programming.
    \Harvard University\

    The astute reader will note the chilling words in the above: "(a) If a court as a matter of law finds the contract or any term of the contract to have been unconscionable or contrary to public policies relating to innovation, competition, and free expression at the time it was made, the court may refuse to enforce the contract"

    For the record, I'm not against open source licenses in general, or the GPL specifically. I think the GPL is a rather dumb idea on several levels, but that's another matter entirely. But I also believe (and am backed up by mountains of evidence) that the GPL stands today not because it's "legal", but because no one has yet challenged it. In fact, many legal discussions around the world (by real lawyers) have been rather astouned that no one's been brave enough to butt up against it directly yet.

    To summarize, your quotes and arguments are pure FSF propaganda, and the world is not nearly so clearcut.

        -Mike
  64. Research on GPL et al[ Go to top ]

    This clause dealing with "public policies relating to innovation, competition,

    > and free expression" appear to be targeted directly at licenses such as the
    > GPL, which in effect prevent any author from exercising intellectual property
    > rights on GPL-code derived works.

    The GPL claims no such rights. If I want to link GPLed code to proprietary code, it's legal. I just can't distribute that combined code unless I agree to relicense the proprietary code under the GPL. As I stated above, you don't *have* to accept the GPL, but if you don't, the formerly GPLed code reverts back to standard copyright. In that case, you can't distribute the program anyway. How on earth can the GPL reduce innovation when it gives you *more* rights than regular copyright law?

    >
    > For the record, I'm not against open source licenses in general, or the GPL
    > specifically. I think the GPL is a rather dumb idea on several levels, but
    > that's another matter entirely. But I also believe (and am backed up by
    > mountains of evidence) that the GPL stands today not because it's "legal",
    > but because no one has yet challenged it.

    Actually, the GPL is based on a very old legal idea which any lawyer or judge is familiar with. It's called "quid pro quo", which is in more common words means "I'll scratch your back if you scratch mine". It's a pretty reasonable request. After all, few people want to do something for nothing. It's about capitalism. Not all payments need to be made with money. In the GPL's case, when GPLed code is combined with other code, the payment for using the GPL is the code that was added. If you don't like the price, then write your own code. Heck, you can even use the GPLed code to give you ideas on how to write your own replacement code, like the Apache Geronimo project is doing. What's wrong with that?
  65. Research on GPL et al[ Go to top ]

    "To summarize, your quotes and arguments are pure FSF propaganda, and the world is not nearly so clearcut."

    Lol. How about this, because you have yet to refute a single claim of mine you instead attempt to attack me. Well, if that makes you feel good, so be it.

    As to the rest of your post, I have stated several times that there may be loopholes in the GPL and that it may or may not stand up in the district you are in. Perhaps in your rabid attempts to prove me wrong you haven't noticed that. I believe, however, that I have gone out of my way to explain copyright law and the applicable portions of contract law in a manner which anyone here reading might understand. Now, in regards to UCC Article 2B. First, I cannot find if that is still a proposal or has been enacted. If it's still a proposal it doesn't mean much at all. Even if it is, however, you should note that Article 2B is specifically aimed at EULAs. As stated in 2B

    "The transaction must be with an end user. ... An end user in this sense is not engaged in the business of reselling, distributing, or sublicensing the information or rights to third parties, ... or in otherwise making the information available commercially to third parties."

    The GPL is not an end user license agreement. Indeed, the GPL specifically states that no license is needed in order to use the work (in other words, the GPL includes a "right to use" clause). The GPL is a redistribution agreement which it does not look like Article 2B says anything about. Like I said, however, I cannot find anything about Article 2B that is newer than 1998 or so and thus cannot really say much about it. That also means that it could be possible to modify the GPL in a manner which worked around any limitiations which Article 2B created. I haven't seen any commentary by anyone in the open source community about this subject and I am sure I would have if someone felt it would cause an issue.

    Finally, IBM, right now, has filed a counterclaim against SCO for a breach of the GNU GPL. I would assume that if there was no chance the GPL would stand up in court, IBM's lawyers would not even try that avenue. Or do you believe that IBM's lawyers are wrong too?

    I don't believe that it is worth my time to continue this discussion. I have explained, in length, why standard open source projects and licensing is not unduly complex. I have shown why your attempts to make things more complicated do not, in fact complicate the situation, nor are they abnormal situations. I have provided examples of commercial software which is distributed under similar circumstances as open source software. After being unable to refute anythign that I have said, you have resorted to name calling which I don't have the time to waste on.

    As to anyone else that has been reading this. My advice is and always will be: consult your attorney. Nothing that I have written should be construed as legal advice, nor am I a licensed lawyer.
  66. Research on GPL et al[ Go to top ]

    \Conrad\
    Lol. How about this, because you have yet to refute a single claim of mine you instead attempt to attack me. Well, if that makes you feel good, so be it.
    \Conrad\

    I didn't realize that a comment about "your quotes" was an attack against you - I thought it was an argument against your words.

    As to refuting your claims - I have attempted to do so, and you've responded by saying (to paraphrase) "all of your complex theories" don't matter. That is, in fact, your sole substantive response - to paraphrase again "I'm write 'cuz I say so".

    As I mentioned in a follow up, you may want to research the matter in detail to see exactly where the GPL may have enforcibility problems. Or you can just keep saying that the most restrictive license always wins.

    \Conrad\
    As to the rest of your post, I have stated several times that there may be loopholes in the GPL and that it may or may not stand up in the district you are in.
    \Conrad\

    Actually, no you didn't. You might want to re-read what you posted vs. what you may have thought you posted.

    \Conrad\
     I believe, however, that I have gone out of my way to explain copyright law and the applicable portions of contract law in a manner which anyone here reading might understand. Now, in regards to UCC Article 2B. First, I cannot find if that is still a proposal or has been enacted. If it's still a proposal it doesn't mean much at all. Even if it is, however, you should note that Article 2B is specifically aimed at EULAs. As stated in 2B
    \Conrad\

    In other words, your response is (to paraphrase yet again) "Ah, I don't know anything about that". From your reponses it seems that you don't know squat about any legal challenges to the GPL, real or imagined.

    You may also note that that my quote was only one example. Yet again, you may want to actually research the subject of GPL enforcibility beyond perusing the FSF web site.

    \Conrad on Article 2B\
     I haven't seen any commentary by anyone in the open source community about this subject and I am sure I would have if someone felt it would cause an issue.
    \Conrad\

    Perhaps you've missed my point, and if so my tone is certainly contributing to it. Rather than referring to the "open source community" on opinions on legal matters relating to the GPL, you _may_ want to broaden your horizons and see contrary opinions as well.

    Just like it would be a little warped to go to Microsoft exclusively to find interpretations of open source licenses (and yes, they do have pages that do so!), it's just as warped to rely strictly on open source sources.

    \Conrad\
    Finally, IBM, right now, has filed a counterclaim against SCO for a breach of the GNU GPL. I would assume that if there was no chance the GPL would stand up in court, IBM's lawyers would not even try that avenue. Or do you believe that IBM's lawyers are wrong too?
    \Conrad\

    This is the first suit I've seen that may cut to the heart of GPL, and it will be interesting to see the outcome. To see a real court hearing substantial arguments about the GPL directly (or, the GPL may never come up).

    As for counterclaims in general - I've yet to see a significant initial court claim which wasn't quickly followed up by a counter-claim. Have you? First year interns at law firms know that you don't let an aggressive opponent go unopposed - you find the any means you can to file counter claims and bring the fight back to them. Even if its ultimately futile, it may at least give you some leverage in negotiations.

    And no, this is not an opinion on whether SCO or IBM is right - it's a general observation about how law is practiced in the U.S. If you think a counter claim means anything on face value, then you've got a long way to go in understanding law in this country.

    \Conrad\
    I don't believe that it is worth my time to continue this discussion. I have explained, in length, why standard open source projects and licensing is not unduly complex. I have shown why your attempts to make things more complicated do not, in fact complicate the situation, nor are they abnormal situations. I have provided examples of commercial software which is distributed under similar circumstances as open source software. After being unable to refute anythign that I have said, you have resorted to name calling which I don't have the time to waste on.
    \Conrad\

    I wasn't aware that I called you names. I did think that I ridiculed your argument to some extent. You do understand the difference, yes?

    As for "explaining in length", you've given no references, cited no legal sources, cited no precedents. All of your arguments boil down to "the most restrictive license wins" (and that's _not_ a paraphrase). You haven't even quoted the GPL. In fact, you've quoted nothing, referenced nothing, and proved nothing. Your argument is "well, darn it, that's the way I say it is and that's the way it should be!".

    To anyone who may have the fortitutde to still be reading this: you may want to consider researching this matter beyond the usual Open Source suspect sites. And you may be surprised that some legal experts have the _audacity_ to disagree with Richard Stallman and his FSF legal team. You may be further appalled to find that the largest criticisms of the GPL come from people who most want it to succeed (or perhaps it would be better to say that they wish to see the generalized spirit of freely available open source software to succeed, but see signficant legal problems with the GPL trying to get there).

       -Mike
  67. Research on GPL et al[ Go to top ]

    I've already explained that I'm tired of this conversation with you so I'm going to keep this short and simple.

    \Spille\
    "Actually, no you didn't. You might want to re-read what you posted vs. what you may have thought you posted."
    \Spille\

    In my very first comment on the topic I stated "What may need to be tested are the individual clauses of the GPL, specifically those which govern "linking" and "deriviative works" since both of them use what can be considered somewhat non-standard definitions." Both of those are possible loopholes that I pointed out in the GPL. In nearly ever post I've stated the GPL may not be valid if "there is something in the copyright statutes of the district you are in that limit the terms of the license in some way".

    \Spille\
    "In other words, your response is (to paraphrase yet again) "Ah, I don't know anything about that". From your reponses it seems that you don't know squat about any legal challenges to the GPL, real or imagined. "
    \Spille\

    Next, you take a quote which states honestly that I am unable to ascertain whether or not Article 2B has been enacted. I checked, but could not come up with anything and I'm not going to pay to have a search done. In the research that I was able to do, however, I state (in the very same paragraph I might add) "Even if it is, however, you should note that Article 2B is specifically aimed at EULAs". I then provide a quote directly from the Article which backs up my assertion.

    Since your first comment shows that you are either not reading what I've written, or have a stunningly low reading comprehension level and your second comment shows that you are willing to blatently quote me out of context and ignore what I've said, I don't think I am going to address the rest of your comment. Feel free to continue to think however you want, you've already shown anyone who is reading this that you have no desire to have your mind changed (or even entertain a conflicting view) and are willing to make a fool of yourself to prove yourself right.
  68. Research on GPL et al[ Go to top ]

    Chris,

    don't worry. Spille is unable to discuss. He shows that in every thread he posts. So don't spend your time with trolls.

    -- Andreas
  69. The implications of the LPGL[ Go to top ]

    The LPGL -- perhaps unsurprisingly, given its FSF origin -- is a pretty strong license. Among other things, it guarantees that anybody can create a fork of an LPGL'd code base at any time. When an individual commits code to an LPGL'd project, he expressly accepts that a fork may be created. Thus, the individual gives a legal as well as a moral license to fork the code. JBoss Group officials have expressed their dissatisfaction with the Elba fork and have taken actions which, in my view, are not in the interests of the community (but certainly could prove beneficial to JBoss Group). The LPGL says: let forks happen, don't care. The JBoss Group says: forks are bad for business and therefore must be eliminated. This is why JBoss Group does not get the nature of the LPGL as a free software license. Indeed, by choosing the LPGL as their license JBoss made an implicit commitment to tolerate forks, even if they did not realize this themselves.

    As should be clear from the discussion above, by "nature" I did not mean the "legal implications" of the LPGL. We are talking about different things here.

    Pietari Laurila
  70. The implications of the LPGL[ Go to top ]

    The GPL and LGPL don't say anything about forks. The fact that a fork can occur is purely a side effect of the contract. The FSF also does not say anything about forks, and forks that they have been a part of (emacs vs xemacs, gcc vs egcs) are not always exactly what you would call friendly. I don't think that any development group is ever happy when someone forks their codebase since you are explicitly saying that you don't like they way they are running the show.

    As far as the "interests of the community" being hurt, I dont see how. Yes, in some cases developers manage to live on both sides of the fence after a fork, but that rarely happens. Normally after a fork, the developers who fork are kicked out of the project and get their commit rights revoked. Go ask Theo and the OpenBSD team how long they kept their commit priveledges after they forked NetBSD. Go ask jwz how well he got along with the gnu emacs team right after the xemacs fork.

    It seems to me that some people don't like the way the JBoss Group runs the JBoss Project and would like to project their image of how things normally happen the the Open Source world on them. Well, the image everyone wants to project is not even close to the reality. People are thrown out of projects all the time. The founder and maintainer of Galeon was thrown out of his own project, which he then forked and started Epiphany. That's life in OSS. I would say what the JBoss Group did is mild compared to some of the all out hate fests which happen after a fork or disagreement happens.
  71. JBoss - OSS - Business[ Go to top ]

    Cameron, you are my hero. I'll have to find some use for Coherence in our company :)

    I really don't get all this about controlling the Jboss line etc. I thought OSS was all about freedom, guys? Of course, if you fork the code, you should call it something else than Jboss. But I do have to say that I'm not very knowledgeable about OSS licensing in general..

    //ras
  72. JBoss is not so open after all[ Go to top ]

    I always thought with JBoss, I could grab the code, make some changes, call it TonyServer and sell it however i wanted, and that was legal. That's what would make it OPEN to me. Now I'm learning JBossGroup controls what is done, who does it, EVERYTHING. It's sounds ver CLOSED to me. My support of JBoss is starting to take a 180 degree turn against it.
  73. JBoss is not so open after all[ Go to top ]

    I always thought with JBoss, I could grab the code, make some changes, call it TonyServer and sell it however i wanted, and that was legal. That's what would make it OPEN to me. Now I'm learning JBossGroup controls what is done, who does it, EVERYTHING. It's sounds ver CLOSED to me. My support of JBoss is starting to take a 180 degree turn against it.


    Yes, looks like this kind of "Open" source is useless, I have some source code from "closed" products in my "download" directory and looks like I have the same "freedom" with this "open" product too.
  74. JBoss is not so open after all[ Go to top ]

    You can do that. And it is legal. That doesnt mean that the JBoss group is going to be friends with you afterwards. The JBoss Group controls JBoss. You would be controlling TonyServer. See the difference?
  75. You can replace code piece by piece[ Go to top ]

    I don't want to be friends with them, I just don't want them ignorance or Fear Uncertainty and Doubt.

    Everyone needs to know the following: I can grab JBoss code, and piece by piece replace it with BSD or Apache licensed software, just as if they replaced custom logging with Log4J (which is under the Apache license), or replace a custome Servlet container with Tomcat (which is under the Apache license also). Isn't that the wonders of opensource and JMX? ;)
  76. JBoss is not so open after all[ Go to top ]

    You can do that. And it is legal. That doesnt mean that the JBoss group is going to be friends with you afterwards. The JBoss Group controls JBoss. You would be controlling TonyServer. See the difference?


    "Close" JBoss if you do not like your license, why do you need enemies ?
  77. JBoss[ Go to top ]

    <thomas>According to their website founded in 2001.</thomas>

    And the contributions of Masters Jenks et al. began when? Please do tell..

    <thomas>According to their own statements they were, or is getting paid by JBoss Group not employment?</thomas>

    I'm sorry Thomas - have you just beamed down to earth or something? It seems that you are missing a large chunk of the picture and trying to make up for it via web searches.

    JBoss is/was an Open Source project. Go read Eric Raymond's the Cathedral and the Bazaar if you don't understand this.

    If you to discuss this further, how come the developers were reported as summarily terminating their contracts with JBoss group - how many employees do that (legally)?

    While the reasons for their departures from JBoss apparently varied from individual to individual the common theme seemed to be one of rejection of the terms of the conditions of the JBoss Group options scheme - which was the main way that these 'employees' would actually get to see any of the money that they had earned for the company.

    <thomas>I don't personally understand why it is even a news event or not expected. Most other businesses would have dropped them like flies on the day of their announcement.</thomas>

    Do you want to get a clue about what we're talking about here? This is an OSS based business that relies on volunteer labour - a company in JBoss's position with your attitude would quickly have a developer community of one...

    <thomas>I was personally surprised of the amount of lenience JBoss Group was showing them, letting them continue in the project as if nothing had happened. Despite of the fact how they decided to make their departure.</thomas>

    Yep, and if I was in Marc F's position I would have carried on as if nothing had happened. Why - because developers are the lifeblood of OSS projects. As long as they we committing to the codebase they were contributing to JBoss, regardless of who they were working for. I know that Marc's biggest problem is ensuring a supply of quality developers - he admitted as much 18 monthhs ago.

    The key point about OSS is that consultancy makes the money. It doesn't matter one fig who developed the code - it's just who understands it best that is important. OK, that's usually the writer of the code, but it doesn't have to be that way.

    <thomas>That is the part that boggles me. They MUST have so many other important things to take care of that should take much higher priority</thomas>

    How long does it take to talk a journalist for that kind of article - 10 minutes? Get real.

    /david
  78. JBoss[ Go to top ]

    And the contributions of Masters Jenks et al. began when? Please do tell..


    Apparently around summer year 2001, clearly after the formation of the JBoss Group company (and yes I had to use my browser again). I'm sorry but I'm missing what you're after here. Care to elaborate?

    > I'm sorry Thomas - have you just beamed down to earth or something?

    I guess I must have...

    /t
  79. The National Inquirer[ Go to top ]

    Oh please, the personal morning after confessional style might be interesting if the subject in question was Angelina Jolie...but when it's just some disgruntled open source punk--it's laughable.

    That publication truly is a rag, wonder what the qualifications are to write for them...or maybe I don't.
  80. PLENTY...[ Go to top ]

    This is the era of PLENTY for J2EE. It would be better if J2ee "caring" developers decide to concentrate on one single Project in every field. Every single project from Apache OS foundation is useful.So I am sure this project will have the same success
    All the best!
    Fa
  81. Integration Server[ Go to top ]

    I wish instead of building an appserver they would build and integration server on top of jboss. Webmethods seems to think it is a good idea. That is what we really need, not another appserver.

    just my two cents

    Matt
  82. Re: PLENTY...[ Go to top ]

    This is the era of PLENTY for J2EE. It would be better if J2ee

    > "caring" developers decide to concentrate on one single Project
    > in every field. Every single project from Apache OS foundation
    > is useful.So I am sure this project will have the same success

    Maybe you should release the name of the drug you consume on a regulary basis.

    Every single Apache OS Foundation projects is useful? Haha. Most of the java related Apache projects are poorly documented, a bug nightmare, give a shit about performance or specifications and claim they are the best you can get. It took 4 versions of tomcat to get a halfway decent JSP/Servlet container. Projects such as log4j seem to require at least 20 times more source code than other projects to handle a trivial task such as LOGGING. Not to mention the new plaque called jakarta commons-* which forces you to including 10 libraries with an unclear version structure and strange assumptions about the runtime environment, so basically every .ear deployment will fail on a serious j2ee platform.

    Get a cup of reality outside the tomcat, struts and log4j world ...

    (Yes, there are some really good Apache related projects, but others just don't deserve their current community status)
  83. The National I/Enquirer[ Go to top ]

    <chip> That publication truly is a rag, wonder what the qualifications are to write for them...or maybe I don't.</chip>

    Errrmm... I'm confused. Are you talking about the National Enquirer (with an E), or www.inquirer.net here? I was talking about the latter, but a search of their site for 'Jolie' yields nothing... can you clarify?

    As for inquirer.net, AFAIK they're a group of ex-theregister.co.uk people. Is it me, or has the inquirer taken over from the register for 'IT News with Attitude'?

    /david
  84. JBoss and Geronimo[ Go to top ]

    According to The Inquirer (one of my favourite morning reads, I have to say!), all four have had their commit rights removed.

    >
    > JBoss goes Corporate

    In a former thread someone pointed out, that such thing would not be possible, as they were administrators, not being able to voted out against their will. Does somebody now the exact mechanics of this (I think it's some kind of SourceForge rule)?

    Anyway, a quick scan for David Jencks on the JBoss conbtributor's page gave nothing. That in contrast to his past contributions (and him being one of the featured contributors when JBoss was SF project of the month) just looks smelly.
  85. 9 of the sixteen developers listed are part of Core Developers Network, which is a fork of the commercial JBoss Group ( see this thread: http://www.theserverside.com/home/printthread.jsp?thread_id=1965).
    Seem's to be that Floyd was wrong and we indeed see a split of the project now.

    btw.: as far as I know, even Monson-Haefel once had some business relationship with marc, and they split up in an unfriendly manner.
  86. I am qurious how will Sun and IBM view a certified open source J2EE server. As a good thing that promotes Java or as a bad thing that ruins their business?

    Has Apache already verified Sun's and IBM's position on this, or they are acting on their own? As far as I know they are the biggest sponsors of Apache, so this question is important.
  87. Apache J2EE app server[ Go to top ]

    This seems like a lot of hot air. Unless Sun or IBM comes out and sponsors this project, you're just talking about the usual Apache sandal brigade here. JBoss is already a mature product and will be J2EE certified well before the Apache releases an production-ready app server if they ultimately get that far.

    Apache is BSD and JBoss is LGPL, so they cannot fork JBoss code--they have to re-write most everything from scratch.
  88. re: How will Sun and IBM react to it...[ Go to top ]

    There are really 2 tiers to the J2EE servers: Tier 1) those that provide a complete middleware stack needed to build "enterprise" applications and Tier 2) those that provide enough of the middleware stack to build applications.

    Tier 2 includes servlet/JSP, EJB, JMS and all the necessary J2EE pieces. Servers that fall under this space include JRun, JBoss and many others.

    Tier 1 includes everything from Tier 2 plus integration tools (typically BPM capabilities), advanced transaction tools (e.g., TXSeries), portal, commerce and more. Servers that fall under this space include WebSphere, WebLogic, 9iAS and Sun ONE.

    I don't think the tier 1 vendors really try to compete for the tier 2 space anymore -- application servers are simply a commodity at this point. Instead, they are focusing on the APS (application platform suite) concept that Gartner has recently been pushing. For many larger organizations ($200MM and up), paying $30k-$100k/CPU for BPM alone is worth it. If you can provide portal and other capabilities as well, it is an easy business ROI determination.

    Realistically, competition for many of these guys now lies with the ERP vendors such as SAP and PeopleSoft. Oracle is in something of a nice position since they are both an ERP and Tier 1 J2EE vendor.

    Russ

    P.S. This message is not intended to be flame bait... I'm sure many out there will not like my "tier 1" vs. "tier 2" labels. Hopefully it won't offended but be interesting for conversation. ;)
  89. Applications[ Go to top ]

    <quote>
    Realistically, competition for many of these guys now lies with the ERP vendors such as SAP and PeopleSoft. Oracle is in something of a nice position since they are both an ERP and Tier 1 J2EE vendor.
    <quote>

    Don't forget SAP also has both tiers: SAP WAS 6.2 is a full J2EE stack with 2 personalities (Java = J2EE and ABAP). IMO, in the mean time
    - SAP and Oracle have already "everything" (DBMS, J2EE App Server, Portal, Commerce, CRM, ERP).
    - IBM has DBMS, J2EE App Server, Portal, Commerce but no real ERP (But don't forget they have SanFransisco project!). IBM has also a very good eLearning platform (Lotus Learning Space) based on J2EE. Oracle as well. Only SAP does not have any J2EE eLearning platform sofar.
    - BEA is almost the same as IBM but without ERP and without eLearning.
    - PeopleSoft only has ERP and depends on other J2EE App Servers.

    The next step for IBM and BEA is maybe to buy PeopleSoft, so they can compete with SAP and Oracle in ERP area. At the moment Oracle has a very complete solution...

    Regards,
    Lofi.
    http://www.openuss.org
  90. re: How will Sun and IBM react to it...[ Go to top ]

    <quote>
    There are really 2 tiers to the J2EE servers: Tier 1) those that provide a complete middleware stack needed to build "enterprise" applications and Tier 2) those that provide enough of the middleware stack to build applications.
    ...
    I don't think the tier 1 vendors really try to compete for the tier 2 space anymore -- application servers are simply a commodity at this point.
    </quote>

    I think you are right.
    Furthermore Sun can actually benefit from the project. IMO Sun may welcome this for two reasons:
    1) A certified open source (free) J2EE server gives a good reason to go with Java instead of .NET
    2) Sun may donate the current RI to Apache and use the help of the OS community to develop RI for the rest of the J2EE stack as it is doing with Tomcat
  91. How will Sun and IBM react to it...[ Go to top ]

    I am qurious how will Sun and IBM view a certified open source J2EE server. As a good thing that promotes Java or as a bad thing that ruins their business?

    >
    > Has Apache already verified Sun's and IBM's position on this, or they are acting on their own? As far as I know they are the biggest sponsors of Apache, so this question is important.

    Correct me if I am wrong: IBM has making money by distributing Apache web server, by distributing Linux, while Apache or Linux may or may not make money at all. IBM and Sun can dump their server. It will save their money, it will help them to make more money.

    Perfecting J2EE!

    Wei
  92. I'm hoping for ...[ Go to top ]

    A solid, non-bloated implementation. I hope to see the project start with a very vanilla J2EE container, supporting BMP, Session Beans, and EJB.

    It will be interesting to see a feature schedule, and to see if those in charge of project goals are able to correctly map the order of features that should be included.

    If this thing gets too bloated, I'm gonna be pissed ;o)

    Best,

    John C. Dale
  93. I'm hoping for ...[ Go to top ]

    You want a non-bloated EJB implementation? That's an oxymoron.


    > A solid, non-bloated implementation. I hope to see the project start with a very vanilla J2EE container, supporting BMP, Session Beans, and EJB.
    >
    > It will be interesting to see a feature schedule, and to see if those in charge of project goals are able to correctly map the order of features that should be included.
    >
    > If this thing gets too bloated, I'm gonna be pissed ;o)
  94. I'm hoping for ...[ Go to top ]

    <mike> You want a non-bloated EJB implementation? That's an oxymoron.</mike>

    LOL. I take your point. But I'm coming to the opinion that it doesn't have to be that way, particularly from a usage point of view. I'm beginning to think that, with CMP2 and XDoclet, the words RAD and EJB may not be so far apart...

    WRT Geronimo, I agree with those that just want an app-server that does what is says on the tin - implements the spec efficiently (preferably with one thread per processor in the non-IO limited sections of the system, if they want performance) and no more.

    Innovation (specifically The AOP stuff being done by JBoss) is fascinating, but my initial feel will that there are as many 'bad' ways of using it as there are 'good', and it is going to take a whole new set of Patterns (and anti-patterns) to be developed before it is goinng to be genuinely useful for the developer masses. Press the fast-forward button for a couple of years, perhaps?

    /david
  95. I'm hoping for ...[ Go to top ]

    ...a world in which EJBs and their apologists are confined to the dustbin of history. You cannot make a silk purse out of sows ear. Come on Geronimo please please please please please please please please please please please please please make a J2EE App server with the EJB server as an optional plug-in type thing. Then drop support of said plug-in type thing after release 0.9 (beta).

    many thanks
  96. I'm hoping for ...[ Go to top ]

    <daniel>...a world in which EJBs and their apologists are confined to the dustbin of history. You cannot make a silk purse out of sows ear. Come on Geronimo please please please please please please please please please please please please please make a J2EE App server with the EJB server as an optional plug-in type thing. Then drop support of said plug-in type thing after release 0.9 (beta).
    </daniel>


    Right:

    1) Can you identify some concrete elements of your issues with EJB?

    2) EJB spec is far from perfect, admittedly. But do you have any concrete suggestions for improvement/replacement? (of your own - don't just blandly regurgitate someone else ideas.)

    3) How many distributed, secure, transactional servers have you written from scratch (e.g. have you the faintest idea of the complexity of the problems that EJB is trying to solve)?

    I am fed up of this argument. EJB has taken a long time to reach a usable state, but I think it has reached that point. If you wanted to debate the causes of WWI, your arguments would ultimately be as irrelevant to a world that has moved on...

    /david
  97. I'm hoping for ...[ Go to top ]

    I'm beginning to think that, with CMP2 and XDoclet, the words RAD and EJB may not be so far apart.

    Automation is a spiritual boost, not to mention a productivity boost. Apparently during a recession, spirit and productivity are especially important to surviving the threat of redundancy. Keep on kicking azz.

    WRT Geronimo, I agree with those that just want an app-server that does what is says on the tin - implements the spec efficiently ...
    Innovation (specifically The AOP stuff being done by JBoss) is fascinating, but my initial feel will that there are as many 'bad' ways of using it as there are 'good'...


    There is hinting that AOP may be important to inventing better containers.
  98. Apache the next Microsoft[ Go to top ]

    While I like a lot of what is happening at Apache, it more and more seems to move from something that encourages and new technology and competition to some kind of marketing and re-branding machine. I met quite a few managers who tend to believe that everything that comes from Apache is production quality code that was created in a well defined and controlled development effort.

    Having been working in the J2EE space for the last 5 years or so, and having looked inside the code and the development documentation of a lot of Apache (Jakarta) projects, I am quite amazed about that.
  99. As pointed out by others, I don't understand what is the real need for creating a brand new J2EE app server.

    Why not adopt JBOSS or Jonas or Enhydra into Apache?

    Is the availability of open-source skills is in excess so they can afford to develop yet another J2EE app server or is it sponsored by people who have other reasons not technical?

    Excuse me if I sounded bit cynical but I'm trying to understand why.
  100. I'm not sure how the existing projects feel about Apache's invitation to donate all their code, I assume it would only be the less successful, lower visibility ones that had anything to gain would do so. The Apache people are bunch of open source prima donnas who are fanatical about their licensing so it's not surprising that they would come late to the J2EE field and expect everybody else who's been there for a few years to drop everything and sign on with them.
  101. I'd be happy to see OpenJMS get used and thus gain some more momentum. It's been languishing in a 0.7x state for a while (last time I checked). I'm actually using it in production (for over a year now) and it's a great, simple to use JMS provider. I haven't run any tests on its performance but ease of maintenance and install were more of my focus when I picked it. If Apache picks it up, I would hope they would improve upon its admin capabilities, and maybe improve its performance and scalability (which, of course, I have yet to verify myself).

    As a side note, the project using OpenJMS was originally going to use JBoss but their JMS implementation was a mess at the time. There was extremely poor documentation, even paid docs, for JDBC persistent guaranteed messaging. That was a requirement and OpenJMS handled it quite nicely, obviating any need for JBoss in the project at all. Nothing against JBoss, which I've been trying to get to use in a production project for a while, but in that aspect it was a bit immature.
  102. 2 cents[ Go to top ]

    I think this makes sense if Sun explicitly endorses and even sponsors the development - that would mean that this would become the reference implementation of J2EE just as Tomcat is the reference implementation of the servlet API. Not likely, but it could happen.

    If Sun isn't behind this, I question how useful this is really going to be.

    I think the central issue here is the EJB spec itself. People have used it all over the place, but the reality is that EJBs are overkill in many cases. Open Source I think is a barometer for whether a technology is really needed, or not, and if you consider the current open source landscape, it tells you quite a bit. The useful technologies are servlets, jta, jdbc, rmi, etc. For these, there are free (as in beer) implementations out there already.

    Furthermore, the need for standards is just not there in OSS. Standards are needed in business because companies they keep risk under control. With a GPL'd project there is almost no risk as long as the user base is huge, as it is in many cases.

    Also, standards always have terrible compromises. With OSS you have an opportunity to use your freedom to solve well-known outstanding problems, e.g. long-running transactions (advanced concurrency control), system evolvability, etc.

    Anyhow, I hope it does get built, so people can save money on licenses.

    Guglielmo
  103. 2 cents[ Go to top ]

    I agree with Guglielmo Lichtner!

    "If Sun isn't behind this, I question how useful this is really going to be"
    "I think the central issue here is the EJB spec itself"

    So I think Sun is behind this somehow, to make EJB more important that it is.
    I wish apache did C#, like they do PHP.

    A strange play by ASF, certianly the use compunity did not ask for this.

    .V
  104. Go Apache, Go![ Go to top ]


    > A strange play by ASF, certianly the use compunity did not ask for this.
    >

    Are you speaking on behalf of the whole user community now? Somehow, I can't recall when you were granted this right.

    As for Apache doing another open source J2EE implementation ... excellent news indeed!

    --
  105. 2 cents[ Go to top ]

    "If Sun isn't behind this, I question how useful this is really going to be"

    > "I think the central issue here is the EJB spec itself"
    >
    > So I think Sun is behind this somehow, to make EJB more important that it is.
    > I wish apache did C#, like they do PHP.
    >
    > A strange play by ASF, certianly the use compunity did not ask for this.


    I used to think of ASF as a synonim for IBM. Taken this as a base, it becomes clear that this play is purely about money IBM is trying to take from its main competitor in J2EE space (BEA). How? ASF is promoted much better than JBoss, so use of AFS's "free" J2EE implementation would be wider acordingly.

    Would a production-grade OS J2EE server hurt IBM? In short term it definitely will. But IBM has a well-deversified business, so they can bear it for a while.

    Do such moves improve industry competivness? Well, you decide.
  106. Project Geronimo - This is something we were waiting for last so many years and being Strong Java follower, its really one of the best news in recent years. However, making Geronimo as another EJB container will surely be the waste of efforts, becoz as so many others pointed out, EJB (read Entity beans) is overkill for most of the projects it is getting used. Geronimo server should be the extension to Java, J2EE techonlogies and should adapt best of J2EE technolgies which makes more sesnse to Web based & integration project. It should also be providing support to AspectJ, Jess, JDO - even if that means to drop support to useless Entity Beans. I know some people will start shouting at top of their lungs in protecttion to Entity Beans, but sincerly, even after using Entity Beans in 2 projects, we could not develop liking for them. I hope, Sun & Apache guys are reading this and surely will take positive step in benifit to 90% of developer communtity.
    All the best,
    KP
  107. Time will tell the truth[ Go to top ]

    Initially I was about to think this Apache OS movement would help to improve the acceptance of J2EE in general. A strong group with a (to my understanding sometimes overestimated) good reputation in the developer community, a bunch of well known developers and a good relationship to Sun. Should be enough to make this happen, shouldn't it?

    Well, I am pretty sure we will see a product at some point, maybe a year from now. But what does the J2EE community get from such a project? Another struts, log4j, tomcat level product? A piece of freely available software which will be used by everyone just because it is used by a large number of other people, regardless of its implications of software maintainability, performance or standard conformance? I just can't hear the average developer arguments anymore. "If you do j2se/j2ee use xyz from apache/jakarta." No matter what. Do we really need another JBoss vs. Jonas vs. Application Server participant? Without being superior in its field? If it was me, I would certainly say no.

    I would love to be wrong, so Apache Geronimo, please don't repeat Apache Java history...
  108. It will be a great success[ Go to top ]

    G - Greatest Server
    E - Enterprise Server
    R - Robust Server
    O - Outstanding Server
    N - Numero Uno Server
    I - Integration Server
    M - Most Powerful, Reliable, Scalable Server
    O - Open Source Server

    This is what most of the people will say about it...
  109. With each new aplication server, does not always come more "quality" and
    "features" to the J2EE comunity.

    At this stage, after more than 7 Years of Java, and 4 of Servlets, people should be more concerned with a better, MATURE and solid platform than a bunch of "same things."

    Take Microsoft for instance. It´s main product is NOT Windows. It´s OFFICE.
    Take IBM and BEA. They have massively invested in new markets (Portal, IDE, etc..). J2EE Servers are almost a commodity, let´s move forward!!!.

    Comunity should join efforts to improve the specs, simplify and mature current solutions and most important. MAKE IT EASY. (less fingers, more brain).

    Open Source comunity was never about "Clients, Revenues, Estrategy", it was always about "Inovation, What Real People Want".

    So, think REAL. Think Inovation. Don´t reinvent the wheel.
  110. What will Rolf say about this?[ Go to top ]

    I really miss Mr Rolf Tollerud a lot and somewhat curious about about his response to such an event.

    According to my diligent, yet sometimes unreliable, memory, Rolf used to be a big fan of the Apache projects, while holding a diabolic prejudice against the EJB technologies. (and of course it's nothing surprising, considering his M$ background).

    But now the two ends of Rolf's Java world meet each other. What will our good Rolf say? Where will the Ninja sword fall?
  111. Good News ![ Go to top ]

    Makes Sense. All the Best !
  112. Clearing the air...[ Go to top ]

    There has been a lot of speculation and misinformation about the relationship between JBoss Group LLC and people who contributed to the project. As someone personally involved, I would like to clear the air.

    None of the CDN Partners were ever employees of JBoss Group LLC; we were all independent contractors with contracts that clearly stated that we were not employees. In the US, the IRS has a standard for determining an employer-employee relationship and both parties were careful to ensure the relationship did not qualify as such.

    One reason the JBoss Group could be trying to define the relationship as an employment one is that it would automatically assign copyright to JBoss Group under US "work for hire" rules. In an independent contractor relationship, such assignment would not be automatic but would be governed by the terms of the contract. I have not seen all of the Partner's contracts, but I can state that the various contracts I entered into were not for the development of any code contributed to the project and did not include a "work for hire" clause.

    Marc Fleury posted yesterday that "JBoss [Group] will AGGRESIVELY defend its copyright." He should expect no less from the actual copyright holders, the individual contributors to the project.

    Dain
  113. Clearing the air...[ Go to top ]

    Thanks for that clarification, Dain, and Good Luck for the future...

    /david
  114. Clearing the air...Copyright[ Go to top ]

    From the statements I have seen, it's the other way around. JBoss Group is talking about defending the copyright of those developers who have not chosen to join the Apache Geronimo project. Only the individual copyright holders can offer their code under an alternative license--so a JBoss fork is not possible in Apache BSD as the major JBoss contributors like Bill Burke, Sacha Labourey, Scott Stark, Juha Lindfors and Marc are not participating in Apache's project.
  115. Clearing the air...Copyright[ Go to top ]

    From the statements I have seen, it's the other way around. JBoss Group is talking about defending the copyright of those developers who have not chosen to join the Apache Geronimo project. Only the individual copyright holders can offer their code under an alternative license--so a JBoss fork is not possible in Apache BSD as the major JBoss contributors like Bill Burke, Sacha Labourey, Scott Stark, Juha Lindfors and Marc are not participating in Apache's project.


    This is technically correct. From my understanding (limited as it might be) of copyright law, everything is denied unless explicit rights to do something is granted by the copyright holder. That's the thing about "all rights reserved" and so on.

    Now, forking an LGPL project typically involves a bunch of people (could be anybody) starting off with an LGPLed project and taking it in a new direction. LGPL definitely allows this.

    However, the resultant derivative project is then also subject to LGPL terms relevant to the first project. It's unlikely a simultaneous "switching to another license and rebranding" is legal.

    Sandeep.
  116. Clearing the air...Copyright[ Go to top ]

    Given the original statements in the annoucement of:

    i) "The project (tentatively named "Apache Geronimo") builds upon the many Java projects at the Apache Software Foundation."

    ii) "The aim of the project is to produce a large and healthy community of J2EE developers tasked with the development of an open source, certified J2EE server which is ASF licensed and passes Sun's TCK reusing the best ASF/BSD licensed code available today and adding new code to complete the J2EE stack."

    iii) "This project is starting with a new code base together with reusing lots of the currently available high quality J2EE open source code out there which is ASF/BSD licensed."

    It's highly unlikely that the Apache team is leaning towards any shameful smash-and-grab fork-and-rebrand approach for this project. That said, I don't quite understand "elba".

    Sandeep.
  117. Clearing the air...Copyright[ Go to top ]

    Chip,

    Are you saying that the JBoss Group is collecting copyright assignments from contributors to the JBoss project? If not, I don't see how the JBoss Group has any legal standing to "defending the copyright of those developers".

    Further, let us clear the air some more. Cameron likes to take the subtle path, but I tend to be more blunt.

    Who are you really? Time to remove the mask.

    Dain
  118. Clearing the air...Copyright[ Go to top ]

    You're clearly thinking about the path to copyright defense.

    Why the nervous and hostile tone?

    The people are not important. In a forum, it's the dialogue that counts.

    Those who have never willfully or unintentionally represented someone else's work to be their own have nothing to be afraid of.
  119. Clearing the air...Copyright[ Go to top ]

    From the statements I have seen, it's the other way around. JBoss Group is talking about defending the copyright of those developers who have not chosen to join the Apache Geronimo project. Only the individual copyright holders can offer their code under an alternative license--so a JBoss fork is not possible in Apache BSD as the major JBoss contributors like Bill Burke, Sacha Labourey, Scott Stark, Juha Lindfors and Marc are not participating in Apache's project.


    Why is Jboss Group afraid ? I do not think Apache is going to fork JBoss, there are a lot of good BSD code and Apache projects have a lot of code too.
    Code is nothing without community in open source and I do not think forked LGPL code can be usefull for Apache, I think there are a lot of better choises to implement j2ee than JBoss fork.
  120. How does this copyright stuff works? If copyright owner is anyone how has ever contributed on line of code to a project, and that line of code remains in the source code, then everyone who has ever provided one line of code to the project has the same right over it, despite the fact that he/she belongs to the project or not anymore. As I understand, the copyright will be there, unless all code contributed by the individual is removed completely.

    Can CVS show who contributed each line of a project? I mean, if I commit one line, and later someone else changes it, will it still show both informations? And if the code was changed so much as to be completely different from the first commit? Would I lose the copyright on that code? Am I making too many questions? Does this last one count? ;-)

    Either it can realy get complicated, or I am missing something.

    Cheers.
  121. How does this copyright stuff works? If copyright owner is anyone how has ever

    > contributed on line of code to a project, and that line of code remains in the
    > source code, then everyone who has ever provided one line of code to the
    > project has the same right over it, despite the fact that he/she belongs to
    > the project or not anymore. As I understand, the copyright will be there,
    > unless all code contributed by the individual is removed completely.


    It's pretty simple. If I write code A under the LGPL license and you add some amount of code B to my code, then we both own the copyright to the combined A+B code. If someone wanted to relicense the A+B code under another license, they would have to get both our permissions because we were both involved. If you refuse to relicense but I agree, then A+B cannot be given another license. However, my orignal code A still belongs to me and since I agreed to relicense my code, you could use code A under the license of your choice.


    So basically, it comes down to this. If JBoss has 100 contributors and 40 contributors agree to relicense under the Apache license, the Apache group can take contribution from these 40 contributors. They just have to make sure that they take no code from the other 60 contributors.
  122. Clearing the air...Copyright....[ Go to top ]

    And judging from the people who formed this new project, they will not be allowed to use much of JBoss legally, as none of them did much more than refactor with the exception of David Jencks and Dain Sundstrom. The others never did much. However, it is funny though if you look through recent CVS commits to JBoss from people involved in Geronimo, all they did was go in and try to change copyright but making a small change to the code. Seems pretty professional for a group of people who stated they formed a company based on integrity. Check it our for yourselves.

    Competition is great, copying is a waste of time.
  123. From the Geronimo FAQ: ELBA[ Go to top ]

    This is an extract from the Geronimo FAQ. Makes sense. Also explains Elba. Sounds like they're a smart bunch of people. ;-)

    Q: What is Elba?

    A: Elba is basically an LGPLed snapshot of JBoss (but not called JBoss to avoid lawsuits). Its not really intended to be developed or enhanced - its a temporary code repository of increasingly shrinking code.

    The idea being for the next (say 1 year) Geronimo by itself isn't gonna be a full J2EE stack. So rather than suffering a Mozilla-style period of lack of use - Elba is a temporary LGPL add-on to Geronimo that Jboss code with Geronimo to provide a full J2EE stack. So from day 1 Geronimo can be used (if so desired) as a full J2EE stack by using the Elba code.

    Of course users are totally welcome to just use whats in Geronimo and nothing else. Or they can drop in other existing services if they wish too. So Geronimo is a clean normal Apache project. If need be you can drop the Elba stuff into Geronimo and get a full J2EE stack.

    So the Elba drop of code is totally optional for those who want to migrate from JBoss to Geronimo from day 1 and keep a full J2EE stack. Though as soon as possible all the Elba stuff can be scrapped as Geronimo by itself becomes the complete J2EE stack (along with the stuff it reuses like Tomcat / Axis / mx4j etc).

    e.g. we replace the JMS from JBoss with OpenJMS. We replace the transaction manager with Tyrex etc. Rewrite the connectors to Tomcat/Jetty/Axis and so forth. As time goes on Elba shrinks away to nothing.

    So in summary Elba is a Geronimo distribution which includes dead LGPL code that can be useful to bootstrap Geronimo. I hope it doesn't exist this time next year and its use is totally optional.
  124. Clearing the air...[ Go to top ]

    Talking about who owns copyright, what you said was what I had heard in US.

    Just for my curiosity, if a developer is in another country, what kind of law will govern the issue? Especially, if the contract is signed over internet or by email, or fax?


    > There has been a lot of speculation and misinformation about the relationship between JBoss Group LLC and people who contributed to the project. As someone personally involved, I would like to clear the air.
    >
    > None of the CDN Partners were ever employees of JBoss Group LLC; we were all independent contractors with contracts that clearly stated that we were not employees. In the US, the IRS has a standard for determining an employer-employee relationship and both parties were careful to ensure the relationship did not qualify as such.
    >
    > One reason the JBoss Group could be trying to define the relationship as an employment one is that it would automatically assign copyright to JBoss Group under US "work for hire" rules. In an independent contractor relationship, such assignment would not be automatic but would be governed by the terms of the contract. I have not seen all of the Partner's contracts, but I can state that the various contracts I entered into were not for the development of any code contributed to the project and did not include a "work for hire" clause.
    >
    > Marc Fleury posted yesterday that "JBoss [Group] will AGGRESIVELY defend its copyright." He should expect no less from the actual copyright holders, the individual contributors to the project.
    >
    > Dain
  125. About time[ Go to top ]

    This great news from Apache.org. I am big fan of Apache I was waiting some thing like this to come out from there for a while. We use TomCat on our production application. For EJBs we are using Weblogic but an alternative like Apache J2EE server would be great. Yes I know that JBOSS is out which is a great J2EE server my salute to them but some choices in open source wouldnt hurt.
  126. War, war, war ...[ Go to top ]

    Have you guys look at this :
    http://marc.theaimsgroup.com/?l=jboss-user&m=106023542516928&w=2

    Rickard, where are you ? No time to comment all this ?
  127. This thread has degenerated somewhat into discussion about JBoss commit access and the like. Here are some links to some relevant messages from the jboss-user mailing list, which will hopefully result in people forming a more informed opinion, as opposed to idle speculation:

    http://article.gmane.org/gmane.comp.java.jboss.user/19203
    http://article.gmane.org/gmane.comp.java.jboss.user/19254
    http://article.gmane.org/gmane.comp.java.jboss.user/19261
    http://article.gmane.org/gmane.comp.java.jboss.user/19277
    http://article.gmane.org/gmane.comp.java.jboss.user/19279

    Nice little soap opera... _MY_ take on this is that from now on I will stop seeing JBoss as an independent open-source project, but rather as an open source commercial venue much like MySQL. JBoss Group and JBoss the project are clearly the same thing, and I would question that ability for any other commercial (and maybe non-commercial) entity to participate in JBoss development in any constructive fashion. Having said that, it's still a great product in many respects, and the right tool for a lot of jobs. I welcome its continued existence, and I welcome the existence of a number of competitors (open-source and not).

    Regards,
    Colin
  128. JBoss & Galatians 6:7[ Go to top ]

    Galatians 6:7 is the "You reap what you sow" passage. I have always felt it was a matter of time for this to apply to Marc F......and unfortunately to some hard working JBoss folks. A company with an arrogant leader and full of family members always has a hard time succeeding....and if you sow the seed of arrogance & deception, it will come back to bite you in the butt.

    My prediction is that this new Apache J2EE project will take a huge bite of future JBoss usage......but for now, Go Resin!!

    Just my 1.5 cents (or maybe no sense :-)),
    Tom
  129. The Future of JBoss[ Go to top ]

    I think JBoss will continue to innovate and be a good open source project for a while. However, as a JBoss user who is quite fond of the software, I am deeply disappointed that all this controversy and craziness has to exist. Maybe Rickard was right. Sigh.

    Sandeep.
  130. It is very clear that...[ Go to top ]

    The JBoss group is very nervous.

    We can all see what is coming - the success of Apache WS, Tomcat...

    Geronimo will be another in a long line of great OS products.

    I can't wait to participate and use the integrated container services.

    Best,

    John C. Dale
    Down in the Desert, Inc.
  131. So is Geronimo going to have a unified class loader or not? I think that there are cases where you'd want it, and cases where you would not. I hope Geronimo does not have a unified class loader.

    More custom-app shops would end up using JBoss, and more integration-app shops would end up using Geronimo, possibly.

    We're JBoss customers, but I'm not really worried. I don't think Marc was referring to owning the software, I think he was more talking about enforcing the LGPL. Good luck to Geronimo guys, hope you create something nice.

    Obviously, I'm still biased and rooting for JBoss.

    Steve
  132. Time to get up and running[ Go to top ]

    Writing a J2EE appserver is no small undertaking. If you want to be fully spec-compliant a lot of subsystems have to be implemented. Even if you take OpenEjb, OpenJms and what else, there is still a lot of code to write.

    So I wonder how long it will take them to just *implement* the entire J2EE spec. Then add a year to achieve production quality. So my estimate is

    - 1.5 years to implement fully J2EE compliant appserver (would that be J2EE 1.5 by then :-))
    - 1 year to achieve production quality code

    2.5 years total ? Maybe I'm totally off the mark, I'm interested in what others think !

    I'm leading another open source project (JavaGroups, javagroups.com), and I know how long complex middleware systems take to achieve production quality. JavaGroups is 5 years old, but has only achieve production quality in the last 2 years or so. Even, if I had to rewrite it now (with all the knowledge that I gained over the 5 years, and all the mistakes I made), I would guess it would take me at least a year to rewrite it.

    So, while I'm affiliated with JBoss (and JBoss Group), please don't mistake this for a cheap shot at dismissing Geronimo. I think competition is healthy, but I slightly dislike the fanfare with which something that doesn't yet exist was announced. Reminds me somewhat of GNU Hurd as competition to Linux...

    Bela
  133. Time to get up and running[ Go to top ]

    Writing a J2EE appserver is no small undertaking. If you want to be fully spec-compliant a lot of subsystems have to be implemented. Even if you take OpenEjb, OpenJms and what else, there is still a lot of code to write.


    > 2.5 years total ? Maybe I'm totally off the mark, I'm interested in what others think !

    I agree. Just look at Mozilla. It took something like 4 years to get something out of that project. Linux took close to ten years to be taken seriously. Being stable is one thing, but market penetration is another.

    > I'm leading another open source project (JavaGroups, javagroups.com), and I know how long complex middleware systems take to achieve production quality. JavaGroups is 5 years old, but has only achieve production quality in the last 2 years or so. Even, if I had to rewrite it now (with all the knowledge that I gained over the 5 years, and all the mistakes I made), I would guess it would take me at least a year to rewrite it.

    I also think that JavaGroups must have inherited all the problems that come with process groups. I remember reading a paper by (your friend) Ken Birman about why process groups aren't widely used. Some of the same reasons that applied at the time still apply today.
  134. Jboss all the way[ Go to top ]

    As an ISV( a very small one at that), our reason for staying with Jboss for now as well as for the future is the constant innovations from the Jboss Group ,great community and the fact that they are on the path towards J2EE certification. Even the documentation is pretty solid at this point.
  135. The opposite of a fork...[ Go to top ]

    There is a special term for when projects split, "fork", but no term for when they merge together to create one project. If there were such a term, this would be the perfect time to use it. The OpenEJB development effort is moving directly into the genetics of the Apache Geronimo project, which will be hybrid consisting of the best all projects involved have to offer. All the active OpenEJB code committers support the Geronimo project and are very excited to add our experience and ideas to the mix.

    We will continue our commitment to users and will accept patches, fix bugs, and issue patch releases as normal. All current OpenEJB users will be undisturbed. The difference being that all major development efforts by the OpenEJB team will take place under the Geronimo project.

    We will do our absolute best to provide a clean and easy migration path from OpenEJB to Apache Geronimo. This would optimally be done by plugging in OpenEJB into Geronimo, in which case there would be no work required by users to migrate. As the Geronimo code is still incubating, it's too early to say how this would be done, but as OpenEJB can be plugged into just about anything it should not be a problem.

    Best Reagards,
    David Blevins
    OpenEJB Co-Founder & Project Leader
  136. The opposite of a fork...[ Go to top ]

    We will do our absolute best to provide a clean and easy migration path from OpenEJB to Apache Geronimo. This would optimally be done by plugging in OpenEJB into Geronimo, in which case there would be no work required by users to migrate. As the Geronimo code is still incubating, it's too early to say how this would be done, but as OpenEJB can be plugged into just about anything it should not be a problem.

    >
    > Best Reagards,
    > David Blevins
    > OpenEJB Co-Founder & Project Leader

    David, are you hinting that Geronimo would be based off of an OpenEJB kernel?

    Sandeep.
  137. I just found this thread so I'm coming on a bit late. I just want to say that I really regret that so much effort is going down the EJB road. EJBs are useful for a small minority of projects. I don't think their limited usefulness justifies all these J2EE application servers. Not only is it a duplication of effort, but wasted effort at that. As more and more people use EJB, they realize it's a great solution for a problem they don't have. Especially with books such as Bitter EJB coming out. Every java developer jumps to use EJB, and most of them (that I know) run from it as soon as they start using it.

    I really like how JBoss is going in a different direction, bring transactions and remoting to POJO. This is what we need, more innovation. Not another J2EE EJB server.

    Michael
  138. Following the letter sent by Greg Stein to the JOnAS team on August 5th, ObjectWeb's Executive Committee President christophe Ney answered and proposed to seek synergies between the two non-profit organizations, Apache and ObjectWeb.

    You'll find the whole letter in the ObjectWeb community ML archive at :
    http://www.objectweb.org/wws/arc/community/2003-09/msg00002.html
    and more info about ObjectWeb and JOnAS at :
    http://www.objectweb.org
    http://jonas.objectweb.org

    Here is the full text of this letter :
    "Dear Greg,

    Following our last phone call, I would like to confirm ObjectWeb's
    position. Apache and the ASF are recognized references in the world of
    open-source software, and we really are honored to have the opportunity
    to find synergies between your community and ours.

    The announcement of the Geronimo project came at a very special moment
    for us, right when Red Hat unveiled their strategic decision of getting
    involved into ObjectWeb and shipping JOnAS in future releases of their
    Enterprise distribution. We also were looking into getting the J2EE
    compatibility certification and just approached Sun on this matter.
    Jonathan Schwartz from Sun said, "If ObjectWeb is just Apache with a
    different face, we'd love to work with them". As for us, we strongly
    believe that Apache and ObjectWeb share the same goals and the same
    non-profit policy, and we'd love to make our two communities work
    together.

    We are delighted to see another open-source J2EE initiative start up.
    This shows that the market is now ready for open-source J2EE application
    servers. Nevertheless, ObjectWeb has a wider scope than JOnAS just like
    Apache extends well beyond Geronimo. Beside the project level, we believe
    that we now have a unique opportunity of tightening the relations between
    our two organizations through common work and common thinking.

    We won't propose a detailed work plan though since Geronimo is in an
    early phase. ObjectWeb developed fully functional components, and we
    keenly invite Geronimo core developers to undertake thorough assessments
    of these components with their respective project leaders. It will be up
    to them to decide which code to share, which interoperability to seek and
    which synergies to find - for this is the very spirit of open source.

    We also would like propose concrete initiatives for the coming months.
    We all have in mind the discrepancies that may exist between license
    models, and this point should be addressed soon to clarify everybody's
    standpoint. As for technical matters, we will strongly incite the
    contributors of our J2EE-related projects to get involved in the
    discussions about Geronimo. Apache headquarters being in America and
    ObjectWeb's in Europe, we propose to be pragmatic and to take advantage
    of some upcoming major event to schedule meetings at the organization
    level and to arrange technical gatherings for project architects so people
    come to know each other and learn to work together.

    Looking forward to exciting new developments, we hope that these proposals
    will suit you and our two communities members and that we will soon have
    the opportunity to make joint announcements of common works.

    Best regards,
    Christophe

    Christophe Ney
    President of the Executive Committee
    ObjectWeb Consortium"
  139. Competition is always a good thing. Go Apache!