Discussions

News: Apache and ObjectWeb encourage developers to find synergies

  1. Brian Behlendorf and Jean-Bernard Stefani, Board Officers from Apache and ObjectWeb, express a common recommandation to Geronimo and ObjectWeb communities to "see if there are any places where collaboration would be preferable to reimplementation".

    JB. Stefani writes :
    "I am happy to report that both the ObjectWeb Board and the ObjectWeb College of Architects have agreed that, for ObjectWeb components that are to be developed collaboratively with the Apache Software Foundation, a change of license from LGPL to BSD is encouraged.

    Ultimately, of course, the final responsibility for effecting such a change lies with the copyright holders of the source code under consideration."

    B. Behlendorf answers :
    "That's terrific news, Jean-Bernard. Thanks!

    Geronimo developers: this should encourage you to look at the code ObjectWeb has implemented for its J2EE server, to see if there are any places where collaboration would be preferable to reimplementation."

    This discussion is the followup of ObjectWeb's last Architecture Meeting. The JOnAS team announced a couple of days ago the availability of JOnAS 3.3 "the last version on the way to J2EE 1.4"

    Read the online conversations between the two communities

    Threaded Messages (51)

  2. Even more offered[ Go to top ]

    Based on the later discussion to better define what the synergies could be there was even suggestion to establish "informal" standard which could allow interoperability/interchangebility of implementation of services in J2EE stack.

    J.B. Stefani:
    - The general policy wrt ObjectWeb license holds for Jonas as well, i.e. if
    Geronimo requests a change of licence in order to package Jonas in an ASF
    software, we will definitely consider it.

    - In general coopetition is good, even among the open source community. I
    think it is of the best interest of ASF and ObjectWeb to cooperate as much
    as possible because deep expertise is not necessarily that common.

    - The 'glue' aspects you mention, which have to do with what I would call
    'componentization aspects' of the software (e.g. plug-ins, services,
    deployment and installation, management, etc) are indeed not covered by the
    J2EE specs and it could prove beneficial to informally standardize at that
    level.

    - BTW, that's part of the reason behind the push in ObjectWeb towards the
    creation of component-based middleware (the idea that you can assemble your
    favorite middleware, including a J2EE middleware out of lower-level
    software components). This is definitely an area where it would be
    interesting to see ASF and ObjectWeb cooperate. It is interesting to note
    that we have two different efforts which are directly relevant here: the
    Avalon project in ASF and the Fractal project in ObjectWeb. Their scope is
    not necessarily identical but there are obvious common threads between the
    two.

    Best regards,

    Jean-Bernard
  3. Here's hoping they make good use of OpenJMS. I'm actually using it in a production system and it's proven to be quite reliable. It's free, it's easy to install, it's easy to administer. It also has a lot of features, including great persistent messaging. When I made the decision to go with OpenJMS, my other option was JBoss's JMS provider. But the docs were extremely poor, even the purchased ones. If it was possible to do persistent messaging (with persistent messages and queues), I couldn't figure it out. Of course, this was a year or so ago, so things may have changed since then.
  4. Change to ASL a bad idea[ Go to top ]

    A change to the ASL license is a bad idea for ObjectWeb to endorse. The ASL is just not a good idea for large projects such as Jonas as it does not protect the IP of its open source contributors. LGPL guarantees that your code remains open source if you want it to remain open source, yet is flexible enough not to hurt adoption. It has not hurt JBoss adoption one bit. I hope the ObjectWeb projects and contributors rebel against this mandate.

    If anything it should be the other way around. LGPL projects like Jonas and JBoss have no problem working withshipping with Apache licensed projects. It is Apache.org that needs to change its policy.

    Bill
  5. Change to ASL a bad idea[ Go to top ]

    Bill,

    <quote>
    A change to the ASL license is a bad idea for ObjectWeb to endorse. The ASL is just not a good idea for large projects such as Jonas as it does not protect the IP of its open source contributors. LGPL guarantees that your code remains open source
    </quote>

    I agree with your view above. On the other side..., one positive thing if JOnAS becomes ASL is that they will get more support from industrial partners. We know that Tomcat is de-facto standard web container in many J2EE servers (also commercial J2EE servers) available on the market. If JOnAS

    1)becomes ASL and
    2)gets J2EE certified

    this could mean that JOnAS will become de-facto standard J2EE server. I could imagine that many other commercial J2EE vendors will just take JOnAS and makes some added value on it just as they use Tomcat. I know that Weblogic will say "no way, man! We build everything from scratch!" ;-)

    I think, this is quite interesting to discuss (or to imagine: what if...) ;-)

    Regards,
    Lofi.
    http://www.openuss.org
  6. Change to ASL a bad idea[ Go to top ]

    Bill,

    >
    > <quote>
    > A change to the ASL license is a bad idea for ObjectWeb to endorse. The ASL is just not a good idea for large projects such as Jonas as it does not protect the IP of its open source contributors. LGPL guarantees that your code remains open source
    > </quote>
    >
    > I agree with your view above. On the other side..., one positive thing if JOnAS becomes ASL is that they will get more support from industrial partners.

    Lofi, this is a myth and Apache.org propaganda. ASL does not mean better adoption. If this were true, JBoss wouldn't have the market position it has now. LGPL also has not hurt our ability to sign partnerships one bit. Linux has been under GPL for years and years, and it hasn't hurt them either. Same for MySql.

    If you're talking about industrial partners that fund Jonas development, then this may be another story. These type of partners like the ASL license because they can exploit the code to go under their own proprietary products. Some open-sourcers think this is fine, and that's their perogative, by I strongly disagree and favor the LGPL approach.

    Again, I hope the ObjectWeb community rejects this proposal. LGPL is a much better license for the type of software they are writing.

    > We know that Tomcat is de-facto standard web container in many J2EE servers (also commercial J2EE servers) available on the market. If JOnAS
    >
    > 1)becomes ASL and
    > 2)gets J2EE certified
    >

    Yes, it would be nice for Sun to recognize that we are willing to pay for certification and just let us take the damn thing.

    Bill
  7. Change to ASL a bad idea[ Go to top ]

    Geronimo clearly would like to be The Next Big Thing. They would like to supplant JBoss in the marketplace.

    I don't know if that is the goal of the ObjectWeb developers. However, the fact that some ObjectWeb members have been pleading to be part of the Geronimo codebase tells me that they are very concerned about being consigned to irrelevant niches by JBoss and Geronimo.

    If you're talking about industrial partners that fund Jonas development, then this may be another story. These type of partners like the ASL license because they can exploit the code to go under their own proprietary products.

    IF being The Next Big Thing is a goal for the ObjectWeb developers, they may want to strike a devil's bargain. ObjectWeb and Geronimo have a lot of catchup to do to compete with JBoss. They may decide they need that industrial partner funding, and are willing to sacrifice some IP rights to do it.
  8. No catch up[ Go to top ]

    I don't think Objectweb has any catch up to play. Just look at the diversity of their project which goes way beyond what JBoss is even trying to encompass. As far as J2EE goes, Redhat joining Objectweb and planning to ship Jonas with it's enterprise server is a clear sign that there is no fear of being a niche ;-).
  9. No catch up[ Go to top ]

    <quote>
    I don't think Objectweb has any catch up to play.
    </quote>

    Agree with you. From the functionality point of view, JOnAS is a complete J2EE server and it has proven itself in production environment.

    Lofi.
  10. Sigh...[ Go to top ]

    LGPL doesn't protect YOUR code any better than the ASL, because YOUR code cannot be taken away once released as open source. The difference between the two licenses is how they treat derived works (OTHER PEOPLE's code).
  11. Sigh...[ Go to top ]

    LGPL doesn't protect YOUR code any better than the ASL, because YOUR code cannot be taken away once released as open source. The difference between the two licenses is how they treat derived works (OTHER PEOPLE's code).


    LGPL defines a contract on how YOUR code can be distributed, used, and derived from. ASL is very weak in this regard as it only states that your distributed derived software must ship with the Apache.org copyright notice and that the documentation of the distributed software must say that it contains Apache code. Most java projects use apache.org code in some form or another (xerces, log4j)

    LGPL guarantees that your IP and any derivation thereof remains public domain. ASL does not. This is how LGPL/GPL protects your IP. You have licensed your IP with the intent for it to remain public domain. This is not the case with ASL.

    I wonder if anybody can answer me this. If you put your code under ASL, are you assigning copyright over to Apache.org?

    /* ====================================================================
     * The Apache Software License, Version 1.1
     *
     * Copyright (c) 2003 The Apache Software Foundation. All rights
     * reserved.
     *

    Does the copyright above pertain to the license (version 1.1), or for the software code itself?

    Personally, as an open source developer, I choose that the software I write for JBoss remains public domain. I want any innovations on my software to remain public domain as well. Big difference here.

    Bill
  12. Sigh...[ Go to top ]

    LGPL guarantees that your IP and any derivation thereof remains public domain.


    Public domain usually means that the creator disclaims copyright to his work.
    Obviously that's not what the LGPL (or the ASL for that matter) is about.
    You shouldn't mix up these concepts.

    > Does the copyright above pertain to the license (version 1.1), or for the software code itself?

    To the license, if I'm not mistaken.

    > Personally, as an open source developer, I choose that the software I write for JBoss remains public domain. I want any innovations on my software to remain public domain as well. Big difference here.

    That is of course your personal choice. Can't argue with that.
  13. Sigh...[ Go to top ]

    Bill, you have alot of studying to do. Your statements are (almost) completely inaccurate on this subject.

    \Bill Burke\
    LGPL defines a contract on how YOUR code can be distributed, used, and derived from. ASL is very weak in this regard as it only states that your distributed derived software must ship with the Apache.org copyright notice and that the documentation of the distributed software must say that it contains Apache code. Most java projects use apache.org code in some form or another (xerces, log4j)
    \Bill Burke\

    You're incorrect. The LGPL only defines how code may be distributed. I can use and derive to my hearts content and do anything I damn please with LGPL code _so long as I don't distribute it_.

    And ASL isn't "weak". It's written intentionally to retain copyright for the authors, but let users distribute (or not) in any manner they choose without restriction. This is not a weakness, it's the explicit intent of the license.

    \Bill Burke\
    LGPL guarantees that your IP and any derivation thereof remains public domain. ASL does not. This is how LGPL/GPL protects your IP. You have licensed your IP with the intent for it to remain public domain. This is not the case with ASL.
    \Bill Burke\

    Many, many misstatements here.

    First, LGPL code is not public domain. Public domain means you retain no rights whatsoever. Neither LGPL, GPL, ASL, BSD, or any of the other open source licenses are public domain.

    Second - you're implying that under the ASL someone can somehow take your own IP out of what you (erroneously) call the public domain. This is pure fiction. If I take the entire JBoss code base, I can't magically remove JBoss.org and sourceforge.net from the Internet. I can't magically hide your code anywhere. I can't force the authors to do anything with it. What someone _can_ do under ASL is make changes/enhancements to your code, and not publish the source. Under either license - ASL or LGPL - those changes are the property of the author. _They are not the property of the original authors_. If I add 2 new classes to JBoss and distribute it, you don't own those classes, Bela doesn't own them, Marc Fleury doesn't own them - _I do_. The only difference is that LGPL compels me to publish those changes, ASL does not. However, in either case you must distinguish between _my_ IP and _your_ IP. You seem to think that changes to an LGPL code base belong to the original authors of the baseline code - they do not.

    \Bill Burke\
    I wonder if anybody can answer me this. If you put your code under ASL, are you assigning copyright over to Apache.org?
    \Bill Burke\

    No, of course not. The copyright you're showing is a copyright on the text of the license.

    \Bill Burke\
    Personally, as an open source developer, I choose that the software I write for JBoss remains public domain. I want any innovations on my software to remain public domain as well. Big difference here.
    \Bill Burke\

    Beyond the obvious mistakes on public domain, I find this attitude puzzling (valid, but puzzling). I'll give you an example from my own work. I started out a while back using OpenJMS for a corporate client. Over time, changes were required - big, big changes. Tons of new functionality was added on top of OpenJMS, and over time the code base began morphing more and more from the original. Flash forward to now, and there's actually slightly more of my own code in my code base than OpenJMS code. The code is just barely recognizable as OpenJMS. Leaving modesty aside for a moment, I think the changes I made were overall more signifcant than the original code base's functionality was (full clustering support, load balancing, robust XA transactions, etc). This stuff was much harder to do then the original OpenJMS basics.

    But - under your philosophy the original authors should have precedence over myself. Even though my own work is greater in size and complexity then the original, the original takes precedence. Using the GPL philosophy, if I drop 50 class files that are GPL into code base of 5,000, those 50 class files "dominate" my own (if I choose to distribute it). This is a valid approach to take, but to me it smacks of extreme hubris. I prefer the ASL/BSD style - you choose how to license _your_ work, I choose how to license _mine_.

         -Mike
  14. So...[ Go to top ]

    Mike,

    How much of all of that work you've done on OpenJMS to turn it into a true enteprise JMS system for your corporate client do the rest of us get to enjoy...?
  15. So...[ Go to top ]

    \C R\
    How much of all of that work you've done on OpenJMS to turn it into a true enteprise JMS system for your corporate client do the rest of us get to enjoy...?
    \C R\

    Good question. Here's a few points to ponder:

      - If I had built the whole thing from scratch for a corporte client (feasible, in retrospect), how much of that do think the rest of you would get to enjoy?

      - The company will not even consider using a large LGPL/GPL code base where they may need to modify bits for their needs. The reason why is simple: they do not wish to be compelled to distribute source for _everything_. Some bits they will consider, other bits highly proprietary and/or a senior manager just says "no". With an LGPL/GPL code base the company has no options.

      - I try on a regular basis to get some of the code released back to OpenJMS. I haven't succeeded yet, but I also haven't been told no. Much of this is overcoming corporate inertia and, yes, fear. I hope to eventually get truly generic bits released. Under the license we don't have to, but it makes good sense for the company to do so for a number of reasons. They just aren't yet 100% convinced.

      - My work on OpenJMS on an internal project hasn't damaged OpenJMS one wit, or cost the original developers anything. To the contrary, the reputation of those original developers has increased, not just within my large organization but on the web as well.

      - If any of this stuff ever does get released publically, it will _because_ of the BSD-style license of OpenJMS. With any other license, we wouldn't touch the code base. With our own work, we'd feel no compulsion to release it. A BSD-style license has given us _choice_ to do what we will with our own IP. And there are many, many organizations in this same sort of boat. Some new code trickles out of these orgs back into open source code bases precisely because the corporate developers can choose what to release, and what needs to stay in house. That choice does not generally exist if you're talking about LGPL/GPL.

        -Mike
  16. So...[ Go to top ]

    - If any of this stuff ever does get released publically, it will _because_ of the BSD-style license of OpenJMS. With any other license, we wouldn't touch the code base. With our own work, we'd feel no compulsion to release it. A BSD-style license has given us _choice_ to do what we will with our own IP. And there are many, many organizations in this same sort of boat. Some new code trickles out of these orgs back into open source code bases precisely because the corporate developers can choose what to release, and what needs to stay in house. That choice does not generally exist if you're talking about LGPL/GPL.

    >
    > -Mike

    Are you sure that this "no-touch" policy isn't just misinformed? I'm asking an honest question here as different organizations interpret LGPL/GPL differently.

    I'm really not sure that LGPL/GPL applies to IT organizations such as the financial institutions you are working for. You are not distributing the software, so it really doesn't matter if you are deriving from LGPL or GPL code as you are not distributing the software. LGPL doesn't mean if you modify it you MUST distribute. But that if you distribute you must distribute the source as well.

    Bill
  17. So...[ Go to top ]

    \Bill Burke\
    Are you sure that this "no-touch" policy isn't just misinformed? I'm asking an honest question here as different organizations interpret LGPL/GPL differently.
    \Bill Burke\

    It's a combination of factors, to be sure. Some is plain fear of the unknown, or of something new. That part is mostly do to being misinformed. However, there are also real concerns that apply.

    \Bill Burke\
    I'm really not sure that LGPL/GPL applies to IT organizations such as the financial institutions you are working for. You are not distributing the software, so it really doesn't matter if you are deriving from LGPL or GPL code as you are not distributing the software. LGPL doesn't mean if you modify it you MUST distribute. But that if you distribute you must distribute the source as well.
    \Bill Burke\

    There are few questions up in the air on this, from my company's perspective:

      - What does "distribute" mean? I'm not joking here - when are you distributing and when are you not? Consider big companies, subsidiaries, corporate partners. Where exactly is the line between internal/no distribution, and external/distribution?

      - My company has many, many clients, and we provide a number of services. Primarily these are financial in nature, but we have software that facilitates these financial services. If we sell services, hosted on our own network, to external clients, which includes modified LGPL/GPL software, is this "distribution"?

      - My company is considering selling some pieces of our software. We're in a tight community of financial companies, with many web-like relationships back and forth between us and each other, and it may be feasible to sell software which does, um, financial stuff, which is written and vetted by us. We're not selling software in that manner now (hmm, I'm not sure, maybe we do sell something, but nothing I'm involved in), but they're keeping that option open. If any modified LGPL/GPL software was in any of this software, they'd be deep legal doggy doo unless they released copious amounts of source that they're not really sure they want released.

    This same sort of issue was just becoming an interesting topic when I worked at a brokerage 8 or so years ago, for similar reasons. Financial companies don't have just internal IT depts that do internal things - they cooperate on committees of financial companies, they provide services to many clients, they trade data on common networks, and occasionally they provide software to hook into their systems as well. And all of this is often highly, highly customized. Canned third party software is commonly used, of course (although there are internally written things like full-blown languages and RDBMS's floating around in the financial world), but financial shops customize the hell out of anything they can get their hands on. So they're going to tread very, very carefully with LGPL/GPL code, because often internal projects are commercialized after they've been internal for a long time.

        -Mike
  18. So...[ Go to top ]

    \Bill Burke\

    > Are you sure that this "no-touch" policy isn't just misinformed? I'm asking an honest question here as different organizations interpret LGPL/GPL differently.
    > \Bill Burke\
    >
    > It's a combination of factors, to be sure. Some is plain fear of the unknown, or of something new. That part is mostly do to being misinformed. However, there are also real concerns that apply.
    >
    > \Bill Burke\
    > I'm really not sure that LGPL/GPL applies to IT organizations such as the financial institutions you are working for. You are not distributing the software, so it really doesn't matter if you are deriving from LGPL or GPL code as you are not distributing the software. LGPL doesn't mean if you modify it you MUST distribute. But that if you distribute you must distribute the source as well.
    > \Bill Burke\
    >
    > There are few questions up in the air on this, from my company's perspective:
    >
    > - What does "distribute" mean? I'm not joking here - when are you distributing and when are you not? Consider big companies, subsidiaries, corporate partners. Where exactly is the line between internal/no distribution, and external/distribution?
    >
    > - My company has many, many clients, and we provide a number of services. Primarily these are financial in nature, but we have software that facilitates these financial services. If we sell services, hosted on our own network, to external clients, which includes modified LGPL/GPL software, is this "distribution"?
    >
    > - My company is considering selling some pieces of our software. We're in a tight community of financial companies, with many web-like relationships back and forth between us and each other, and it may be feasible to sell software which does, um, financial stuff, which is written and vetted by us. We're not selling software in that manner now (hmm, I'm not sure, maybe we do sell something, but nothing I'm involved in), but they're keeping that option open. If any modified LGPL/GPL software was in any of this software, they'd be deep legal doggy doo unless they released copious amounts of source that they're not really sure they want released.
    >
    > This same sort of issue was just becoming an interesting topic when I worked at a brokerage 8 or so years ago, for similar reasons. Financial companies don't have just internal IT depts that do internal things - they cooperate on committees of financial companies, they provide services to many clients, they trade data on common networks, and occasionally they provide software to hook into their systems as well. And all of this is often highly, highly customized. Canned third party software is commonly used, of course (although there are internally written things like full-blown languages and RDBMS's floating around in the financial world), but financial shops customize the hell out of anything they can get their hands on. So they're going to tread very, very carefully with LGPL/GPL code, because often internal projects are commercialized after they've been internal for a long time.
    >
    > -Mike

    You're right. I wonder if FSF has answered any of these questions on the definition of "distribute". Thanks for your perspective.

    Bill
  19. So...[ Go to top ]


    >   - What does "distribute" mean? I'm not joking here - when are you distributing and when are you not? Consider big companies, subsidiaries, corporate partners. Where exactly is the line between internal/no distribution, and external/distribution?

    Excellent questions.

    My own discussions with legal help in this regard resulted in dead ends.

    Well, mostly. The response was that until precedent is set, there is no way to be *a 100% certain* that these terms precisely mean 'X' and not 'Y.

    However, the general consensus was to look at it from the 'strictest' point of view, which is that any transfer of source code or binaries that involves one party making these available to another could be considered a distribution.

    If that is indeed the case, then all of the above cases that you mentioned would automatically be termed "distributions".

    Sandeep.

    PS: I make no pretensions or allusions to competency in the legal realm.
  20. So...[ Go to top ]

      - If I had built the whole thing from scratch for a corporte client

    > (feasible, in retrospect), how much of that do think the rest of you
    > would get to enjoy?

    Apparently about as much as we get to enjoy it today: zero.

    LGPL is starting to make a lot more sense to me. Thanks.
  21. So...[ Go to top ]

    \C R\
    Apparently about as much as we get to enjoy it today: zero.

    LGPL is starting to make a lot more sense to me. Thanks.
    \C R\

    Your tone seems to imply that you're somehow entitled to my work, or my company's work. Why is that? My company paid me to write several tens of thousands of lines of code - code which they own, which is unique, and which adds very significant value. Why should _this_ particular work be compelled to have its source released publically?

    It may be released anyway, as I've indicated, but there's an attitude of a free lunch lingering in the air here. Is my stuff embedded inside of OpenJMS? Yep. Could it exist without OpenJMS? Again - yep. Does my own work diminish OpenJMS, or does OpenJMS diminish my own? I think not. My own code is not built on-top of or exploit OpenJMS - it's a whole pile of brand new, seperate code which does things that OpenJMS does not. And that code would have been written whether it was incorporated with OpenJMS, with another open source product, or incorporated into a home-grown complete JMS implementation written in house. Either way you choose, the OpenJMS guys own their OpenJMS bits, and my company owns the bits I wrote. Why is this a problem? OpenJMS was released as it was precisely so people could do this sort of thing with it. If you have a problem with this, then complain to Exolab, not to me.

       -Mike
  22. So...[ Go to top ]

    Mike,

    I'm not complaining, not at all. You can keep your several tens of thousands of lines of code, I do not care. The world is full of proprietary code, I'm not complaining about yours or any of the other billions of lines of code that people decide to keep for themselves.

    On the contrary, I'd like to thank you for pointing out why LGPL license makes so much sense and Apache license does not.

    Thanks.
  23. So...[ Go to top ]

    Again, nice subtle implications and word twisting. I confess I'm an evil closed source developer!! Burn me for my sins, and those gullible fools who use BSD-style licenses!!

        -Mike
  24. So...[ Go to top ]

    Mike,

    In that case _you_ had a free lunch, since you started ahead with someone else's work, and gave nothing back. So, just to be kind and say thanks for that head start, why not contribute back to the project? That's just what open source is made of, that's how it works indeed. Ok, you have the right to take that code and do whatever you want, but then, by not giving something back, you are going against the open source ideals. You are using someone elses work for your own good and giving nothing back... If everybody did that, OS would surely stale and die.

    Ok, it is not mandatory to give something back, but people should show some gratefulness and give something back to the people who kindly chose to share their efforts with the community. I know you are planning to do so, but until then, some people will just think you "(ab)used" OS for your own good...

    Regards,
    Henrique Steckelberg
  25. So...[ Go to top ]

    Mike,

    >
    > In that case _you_ had a free lunch, since you started ahead with someone else's work, and gave nothing back. So, just to be kind and say thanks for that head start, why not contribute back to the project? That's just what open source is made of, that's how it works indeed. Ok, you have the right to take that code and do whatever you want, but then, by not giving something back, you are going against the open source ideals. You are using someone elses work for your own good and giving nothing back... If everybody did that, OS would surely stale and die.
    >
    > Ok, it is not mandatory to give something back, but people should show some gratefulness and give something back to the people who kindly chose to share their efforts with the community. I know you are planning to do so, but until then, some people will just think you "(ab)used" OS for your own good...
    >
    > Regards,
    > Henrique Steckelberg


    Oh, puh-leeeze. How thick can you get? Haven't you read any of his posts. Or perhaps you have no ideas about how corporate culture and dogma work, and don't take anything he says seriously.

    Sheesh.

    Sandeep.
  26. So...[ Go to top ]

    Henrique: In that case _you_ had a free lunch, since you started ahead with someone else's work, and gave nothing back.

    Most people that use open source treat it as a free lunch. I would suggest that fewer than one in ten thousand contribute anything back. How many computers run Linux today? Probably tens of millions. How many people contribute to Linux? Hmm ....

    Contributing to open source is a choice. The open source model allows people to make that choice, it doesn't force them to. (GPL/LPGL do force it in the case of distribution of modifications, but that's a special case.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  27. So...[ Go to top ]

    Henrique: In that case _you_ had a free lunch, since you started ahead with someone else's work, and gave nothing back.

    >
    > Most people that use open source treat it as a free lunch. I would suggest that fewer than one in ten thousand contribute anything back. How many computers run Linux today? Probably tens of millions. How many people contribute to Linux? Hmm ....
    >

    To _use_ open source, as it comes, is one thing. To take the source code, change it, improve it, is another... Millions use linux, few have the guts to work with the source code and improve it.

    >
    > Cameron Purdy

    Contributing to open source is a choice, you are right. Some people think this contribution should be mandatory, others don't, that's the problem...

    Regards,
    Henrique Steckelberg
  28. So...[ Go to top ]

    \Henrique Steckelberg\
    In that case _you_ had a free lunch, since you started ahead with someone else's work, and gave nothing back. So, just to be kind and say thanks for that head start, why not contribute back to the project? That's just what open source is made of, that's how it works indeed. Ok, you have the right to take that code and do whatever you want, but then, by not giving something back, you are going against the open source ideals. You are using someone elses work for your own good and giving nothing back... If everybody did that, OS would surely stale and die.
    \Henrique Steckelberg\

    You do have a point there - certainly myself and my company benefited from the open source we used as a base. But I also believe that not everything can be looked at from a short-term perspective. I believe eventually my company will allow some code (not just my own) to be cycled out to open source, but this sort sea-change doesn't happen over night. BSD-style licenses allows a company like mine own to get immersed into open source to a degree without risk. And I firmly believe to some extent it will reciprocate. GPL-style licenses imply jumping off a cliff without looking to many companies - they're committing themselves whole hog, and this is a difficult thing to for large, established companies to do.

        -Mike
  29. So...[ Go to top ]

    Ok, you have the right to take that code and do whatever you want, but then, by not giving something back, you are going against the open source ideals. You are using someone elses work for your own good and giving nothing back... If everybody did that, OS would surely stale and die.

    >

    Have your ever tried to submit patch with new features for open source project ?
    Trust me, It is not easy to "sell" code for open source too.
    Sometimes it is better to keep crap on your disk than to break open source code :) I have forked a lot of apache code and modified it for my use cases (I strip features in the most of cases). I contribute for open source projects too, but I am not going to publish everythig I modified, nobody needs it.
    Open Source is not the code, Open Source is the community.
  30. So...[ Go to top ]

    Have your ever tried to submit patch with new features for open source project ?

    > Trust me, It is not easy to "sell" code for open source too.
    > Sometimes it is better to keep crap on your disk than to break open source code :) I have forked a lot of apache code and modified it for my use cases (I strip features in the most of cases). I contribute for open source projects too, but I am not going to publish everythig I modified, nobody needs it.
    > Open Source is not the code, Open Source is the community.

    I igree with you, you can't just throw back any and all code you added to a OS project for your own use case. Just send back the most general part of it, and keep the specifics. The general part tends to be the most stable, so it shouldn't hurt your project so much to make it back to the original OS project.

    Now, whether the original OS project "owners" will accept your code or not, is another matter... :)

    Henrique
  31. So...[ Go to top ]

    \Henrique Steckelberg\
    I agree with you, you can't just throw back any and all code you added to a OS project for your own use case. Just send back the most general part of it, and keep the specifics. The general part tends to be the most stable, so it shouldn't hurt your project so much to make it back to the original OS project.
    \Henrique Steckelberg\

    Well, this is where you can get into trouble with GPL/LGPL. If you happen to "distribute" a product based on your changes (with whatever form of distribute happens to win out in the end), then you can't pick and choose what source you publish - you have to publish everything that meets the derived-product clauses in the license. Even if the code is highly specific only to your situation and couldn't possibly be of use to anyone else, you're required to publicize it.

    I realize this is a bit different from the angle you were approaching things (more along the lines of generally contributing), but again the GPL can make your life difficult here.

         -Mike
  32. Company owns it...[ Go to top ]

    How much of all of that work you've done on OpenJMS to turn it into a true enteprise JMS system for your corporate client do the rest of us get to enjoy...?

    If Mike did these changes as an employee, then they constitute a work made for hire, and the company has the copyright.
  33. Company owns it...[ Go to top ]

    Yes, precisely right. As I mentioned I'm trying to get certain parts released, but it's ultimately the company's call (my main job is to push them as hard as I can without pushing my own self out of a job).

        -Mike
  34. Sigh...Mike question[ Go to top ]

    How much of your code did you give back to the community? Any? All of these enterprise changes are part of openJMS now?
  35. Sigh...[ Go to top ]

    Bill, you have alot of studying to do. Your statements are (almost) completely inaccurate on this subject.

    >
    > \Bill Burke\
    > LGPL defines a contract on how YOUR code can be distributed, used, and derived from. ASL is very weak in this regard as it only states that your distributed derived software must ship with the Apache.org copyright notice and that the documentation of the distributed software must say that it contains Apache code. Most java projects use apache.org code in some form or another (xerces, log4j)
    > \Bill Burke\
    >
    > You're incorrect. The LGPL only defines how code may be distributed. I can use and derive to my hearts content and do anything I damn please with LGPL code _so long as I don't distribute it_.
    >
    > And ASL isn't "weak". It's written intentionally to retain copyright for the authors, but let users distribute (or not) in any manner they choose without restriction. This is not a weakness, it's the explicit intent of the license.
    >
    > \Bill Burke\
    > LGPL guarantees that your IP and any derivation thereof remains public domain. ASL does not. This is how LGPL/GPL protects your IP. You have licensed your IP with the intent for it to remain public domain. This is not the case with ASL.
    > \Bill Burke\
    >
    > Many, many misstatements here.
    >
    > First, LGPL code is not public domain. Public domain means you retain no rights whatsoever. Neither LGPL, GPL, ASL, BSD, or any of the other open source licenses are public domain.
    >
    > Second - you're implying that under the ASL someone can somehow take your own IP out of what you (erroneously) call the public domain. This is pure fiction. If I take the entire JBoss code base, I can't magically remove JBoss.org and sourceforge.net from the Internet. I can't magically hide your code anywhere. I can't force the authors to do anything with it. What someone _can_ do under ASL is make changes/enhancements to your code, and not publish the source. Under either license - ASL or LGPL - those changes are the property of the author. _They are not the property of the original authors_. If I add 2 new classes to JBoss and distribute it, you don't own those classes, Bela doesn't own them, Marc Fleury doesn't own them - _I do_. The only difference is that LGPL compels me to publish those changes, ASL does not. However, in either case you must distinguish between _my_ IP and _your_ IP. You seem to think that changes to an LGPL code base belong to the original authors of the baseline code - they do not.
    >
    > \Bill Burke\
    > I wonder if anybody can answer me this. If you put your code under ASL, are you assigning copyright over to Apache.org?
    > \Bill Burke\
    >
    > No, of course not. The copyright you're showing is a copyright on the text of the license.
    >

    Just wanted to know. I wasn't sure if the copyright was for the license or not. Apologies, it was an honest question.

    > \Bill Burke\
    > Personally, as an open source developer, I choose that the software I write for JBoss remains public domain. I want any innovations on my software to remain public domain as well. Big difference here.
    > \Bill Burke\
    >
    > Beyond the obvious mistakes on public domain, I find this attitude puzzling (valid, but puzzling). I'll give you an example from my own work. I started out a while back using OpenJMS for a corporate client. Over time, changes were required - big, big changes. Tons of new functionality was added on top of OpenJMS, and over time the code base began morphing more and more from the original. Flash forward to now, and there's actually slightly more of my own code in my code base than OpenJMS code. The code is just barely recognizable as OpenJMS. Leaving modesty aside for a moment, I think the changes I made were overall more signifcant than the original code base's functionality was (full clustering support, load balancing, robust XA transactions, etc). This stuff was much harder to do then the original OpenJMS basics.
    >
    > But - under your philosophy the original authors should have precedence over myself. Even though my own work is greater in size and complexity then the original, the original takes precedence. Using the GPL philosophy, if I drop 50 class files that are GPL into code base of 5,000, those 50 class files "dominate" my own (if I choose to distribute it). This is a valid approach to take, but to me it smacks of extreme hubris. I prefer the ASL/BSD style - you choose how to license _your_ work, I choose how to license _mine_.
    >
    > -Mike

    I don't think it is so puzzling as your work is still a derivative of OpenJMS. OpenJMS started you off, probably provided a lot of the structure for your code for a long time, if not still. Your work would not have been possible without OpenJMS unless you had put a lot more time and effort into it. The fact remains that OpenJMS was the foundation of your new project.

    I respect that you prefer ASL/BSD and your reasons for it. I hope that you can respect that I prefer LGPL and my reasons for preferring it.

    I again apologize for any mistakes I made in my statements. They were not intentional and sprouted solely from my passion of support for LGPL.

    Bill
  36. Public Domain?[ Go to top ]

    Bill: Personally, as an open source developer, I choose that the software I write for JBoss remains public domain. I want any innovations on my software to remain public domain as well.

    Bill, the term "public domain" has a well defined meaning already. You should not misappropriate it for your own personal use. I think you have every right to demand through a license that your work and derivatives of it be available via LGPL; after all, it's your work, right? However, LGPL and public domain have basically nothing in common, and you have a responsibility (for example as an intelligent native speaker of the English language) to avoid implying that they do.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  37. Public Domain?[ Go to top ]

    Bill: Personally, as an open source developer, I choose that the software I write for JBoss remains public domain. I want any innovations on my software to remain public domain as well.

    >
    > Bill, the term "public domain" has a well defined meaning already. You should not misappropriate it for your own personal use. I think you have every right to demand through a license that your work and derivatives of it be available via LGPL; after all, it's your work, right? However, LGPL and public domain have basically nothing in common, and you have a responsibility (for example as an intelligent native speaker of the English language) to avoid implying that they do.
    >
    > Peace,
    >
    > Cameron Purdy
    > Tangosol, Inc.
    > Coherence: Clustered JCache for Grid Computing!

    If I am confusing anything here, it is by accident.

    I was equating "public domain" with "remaining open-source". If this is wrong I apologize and please replace "public domain" with "remaining open-source" within my post. I believe in LGPL and hope that the ObjectWeb developers will continue to as well. There is no agenda or hidden twist beyond this. I respect anybody wishing to release code under the BSD or ASL license, but I myself prefer LGPL and gave my reasons. I hope you can respect that....

    Bill
  38. Public Domain?[ Go to top ]

    Bill: I was equating "public domain" with "remaining open-source". If this is wrong I apologize and please replace "public domain" with "remaining open-source" within my post. I believe in LGPL and hope that the ObjectWeb developers will continue to as well. There is no agenda or hidden twist beyond this. I respect anybody wishing to release code under the BSD or ASL license, but I myself prefer LGPL and gave my reasons. I hope you can respect that....

    I was quite clear that I respect your choice.

    I just don't like making a confusing topic (licensing) more confusing that it already is. In this case, the term "public domain" has an existing meaning: the realm embracing property rights that belong to the community at large, are unprotected by copyright or patent, and are subject to appropriation by anyone. So none of the licenses are, by definition, public domain. It is only when the copyright is released (given up by the holder, or when it expires) that a work enters public domain. In comparison, the ASF and BSD licenses are similar to public domain in their permissiveness, but even they are certainly *not* public domain because the copyright is still held. The GPL and LGPL licenses are not public domain, and are purposefully designed to prevent those types of "IP abuses" (e.g. "subject to appropriation"). I think what they do, they do well, but that is because they are explicitly designed to prevent their covered works from being "subject to appropriation" (in the IP sense).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  39. Cameron..[ Go to top ]

    Hey mon,

    you've changed your slogan! I liked the previous one better..

    //ras
  40. Public Domain?[ Go to top ]

    Bill: Personally, as an open source developer, I choose that the software I write for JBoss remains public domain. I want any innovations on my software to remain public domain as well.

    > >
    > > Bill, the term "public domain" has a well defined meaning already. You should not misappropriate it for your own personal use. I think you have every right to demand through a license that your work and derivatives of it be available via LGPL; after all, it's your work, right? However, LGPL and public domain have basically nothing in common, and you have a responsibility (for example as an intelligent native speaker of the English language) to avoid implying that they do.
    > >
    > > Peace,
    > >
    > > Cameron Purdy
    > > Tangosol, Inc.
    > > Coherence: Clustered JCache for Grid Computing!
    >
    > If I am confusing anything here, it is by accident.
    >
    > I was equating "public domain" with "remaining open-source". If this is wrong I apologize and please replace "public domain" with "remaining open-source" within my post. I believe in LGPL and hope that the ObjectWeb developers will continue to as well. There is no agenda or hidden twist beyond this. I respect anybody wishing to release code under the BSD or ASL license, but I myself prefer LGPL and gave my reasons. I hope you can respect that....
    >
    > Bill

    Bill, perhaps you should use the old fashioned term "Free Software".

    The main purpose of the LGPL/GPL is to make sure software remains Free.

    If I buy a product that uses LGPL/GPL software,
    I can ask for the source and fix it myself.
    Somebody who is not a programmer can hire who they like to fix it.
    The important thing is they have the source.

    Look at JBoss. You can get JBoss from a third party,
    but JBoss Group is still an option to solve your problem.

    There is no risk using Free software,
    I can always get the source and resolve my problems.

    This is not true with BSD/ASL style software,
    I might know a product contains Tomcat, but I've got no idea what
    changes have been made.
    I'm forced to go back to the supplier to get a problem fixed.
    I can't decide that a Tomcat developer can better fix my problem.

    If the supplier has gone west, tough!

    Additionally, once somebody closes a BSD/ASL source tree, you lose the
    one of the benefits of open source - lots of eyes.

    I heard a story (probably an urban myth) that the idea for the FSF
    came to Richard Stallman when he couldn't get a simple fix for his
    printer software and wanted to fix it himself.

    Regards,
    Adrian
  41. Free Software[ Go to top ]

    I heard a story (probably an urban myth) that the idea for the FSF
    came to Richard Stallman when he couldn't get a simple fix for his
    printer software and wanted to fix it himself.


    Adrian, thanks for your contrast between ASF/LGPL, two totally different models really. I also read about Stallman's printer problem on the gnu website.

    tim
  42. Public Domain?[ Go to top ]

    I heard a story (probably an urban myth) that the idea for the FSF

    > came to Richard Stallman when he couldn't get a simple fix for his
    > printer software and wanted to fix it himself.
    >
    > Regards,
    > Adrian

    Not quite the inspiration for FSF, but not an urban myth at all. In the book Open Sources: Voices from the Open Source Revolution, RMS details this story (among others) in an essay describing the start of the GNU environment, entitled "The GNU Operating System and the Free Software Movement". The book also contains many other essays from Open Source leaders. Highly recommended.

    Cheers,

    Kinsley
  43. Public Domain?[ Go to top ]

    Adrian Brock wrote:

    > I heard a story (probably an urban myth) that the idea for the FSF
    > came to Richard Stallman when he couldn't get a simple fix for his
    > printer software and wanted to fix it himself.
    >
    > Regards,
    > Adrian

    I read the same exact story. Stallmans manifesto is embedded in the emacs browser someplace. I found it one day when I hit a mistaken key stroke.

    Bill
  44. J2EE Services compatiblity[ Go to top ]

    Bill,

    what do you think about the idea about establishing the interaoperability platform between free J2EE implementations (in the spirit of freedesktop.org) so that individual services implementations (from J2EE stack) can be exchanged to build the best/custom servers. E.g informal "standard" how the services should be build so that I can take EJB container from Jonas, Joram JMS server, and Conector and Pool implementation from JBoss and Jetty servlet container from Geronimo and run them using any "glue" (Jonas/JBoss/Geronimo).

    This way also any other service provider (Resin, SwiftMQ, Tomcat, etc.) could be build to one spec and would work with any J2EE server out there. Would JBoss be open to cooperation like that?

    Miro Halas
  45. Change to ASL a bad idea[ Go to top ]

    \Bill Burke\
    A change to the ASL license is a bad idea for ObjectWeb to endorse. The ASL is just not a good idea for large projects such as Jonas as it does not protect the IP of its open source contributors. LGPL guarantees that your code remains open source if you want it to remain open source, yet is flexible enough not to hurt adoption. It has not hurt JBoss adoption one bit. I hope the ObjectWeb projects and contributors rebel against this mandate.
    \Bill Burke\

    This is pure FUD. In either license, you own the copyright to your own code, and can do what you wish with your own code. The only difference is that an ASL or other BSD-ish license doesn't restrict what other people do with your code. Yes, someone else can take it, use it, change it, incorporate it into other things, even charge for it - _but the code is still yours_. If IBM or a Children's Hospital or a massive financial conglomerate use your code and alter it, this doesn't have any negative impact on the original authors. They still own the copyright.

    The only difference under LGPL is that if someone does any of the above things, they are required to release the source to those changes. And by "release" I mean release in general - they do not have to contribute back to the original authors, they just have to ensure that the source is available publically.

    Either license isn't a "bad idea" for the authors, and doesn't hurt the original developers in any way. The worst case for an ASL code base is that - gasp! - someone may use your code and alter it and even sell it. So what? You made it open source! The only difference, again, is that you're not trying to assert rights on other people's code. If I take an ASL (or BSD) code base, and add 20,000 lines of my own stuff, I own that 20,000 extra lines, and the original ASL author doesn't try to tell me what to do with my own stuff. Under an LGPL code base, the original authors are asserting rights on code they don't own.

    In either situation, the code bases can be commercially exploited. In either situation, someone can come in and use your code, sell it, and change it. The only difference is that under LGPL you have to publish any changes or additions.

    Back to the content of the original announcement - I believe it's an excellent idea. To many open source projects have a "not invented here" syndrome, and end up duplicating other people's efforts - when it would have better for everyone concerned to integrate and enhance rather than duplicate. JBoss itself could learn from this approach - rather than trying to create everything on your own, concentrate on the core app server engine and enhance compatability with other open source code bases. Oh, I know you can plug alot into JBoss, but at the same time alot of effort seems to be wasted doing a JBoss-integrated solution which no one seems to really want. Bill, you yourself said somewhere in your JMS forums that you were mortified to have to suggest a commercial JMS provider over JBoss JMS. I say "so what"? The Java world is moving more and more into interchangable components running on lean engines. I think you guys are going to lose a lot with the tight-integration approach you're taking.

        -Mike
  46. Not Invented Here[ Go to top ]

    <quote>
    Back to the content of the original announcement - I believe it's an excellent idea. To many open source projects have a "not invented here" syndrome, and end up duplicating other people's efforts - when it would have better for everyone concerned to integrate and enhance rather than duplicate.
    </quote>

    Yes this is true. It's not only in app server area. You can see this everywhere on every domain ;-) I think, many of them are, "hey I've written something and I cannot sell it. Let's make it Open Source."

    Anyway I find it a lot more harder to reuse instead of writting from scratch. You need to analyze the to be reused code first, look how to write the wrapper, etc. But if you want to become expert this is surely the way to go ;-)

    Lofi.
  47. ObjectWeb's message is clear :

    1) LGPL is prefered by ObjectWeb to any licencing mode because it enables to share code and to make this process sustainable.
    2) BSD is compatible to GPL & LGPL (cf. http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses).

    In this case, BSD (ASF minus copyright left to Apache Foundation) is envisioned as a way (among others) to facilitate exchange of code between ObjectWeb & Apache for components which offer a strong potential of reusability in projects such as J2EE platforms.

    The purpose of this encouragement is all about interoperability and re-use. Not about Industrial Property, nor Business ("you can make business with my code as far as you don't kill me" to badly quote RMS).

    To summarize, as far as it is good for the Numerous without any kind of restriction PLUS it does not hurt copyright holder, it is good for ObjectWeb.

    Finally, at the end of the day, it is up to the authors of the code to take or not the decision to change their licence from LGPL to BSD.

    JPL.
    ObjectWeb, board member.
  48. Jean-Pierre: >>2) BSD is compatible to GPL & LGPL (cf. http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses).

    But ASF is not

    http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses

    Interestingly enough, the SCO/Linux case is going to set a lot of precedent regarding the validity of GPL/LGPL since this is the core argument of SCO's case:

    http://www.nwfusion.com/newsletters/linux/2003/0818linux1.html

    As a sidebar, to defend Mike Spille's argument ( if he needs it :) )regarding "distribution", I recently was involved with a financial firm that provided service bureau functions to numerous broker dealers. The edict from the well-funded legal department -- No GPL/LGPL code shall be used in any development of value-added and proprietary properties due to exposure of the corporate assets(i.e. Intellectual Property). The thrust of the argument was around the defintion of "distribution" as it pertains to a service bureau.

    Agree with that interpretation or not, this is what's going on in the board rooms and is causing CEO/CFO/CIOs to be nervous about Open Source in general.

    The fact that "viral" has been attached to GPL/LGPL isn't a good thing either. This means that all the projects that ObjectWeb stewards would have to become ASF licensed which I don't know they have the right to do.

    -Frank
  49. Excusez my French but we are speaking about BSD (NOT ASF) as licence which enables to exchange code between Apache and ObjectWeb.

    Then if you want to have proprietary software because of competitive advantage it gives to your business, please do not touch nor even use GPL software. But maybe re-use LGPL stuff (you are not forced to and you are not forced to contribute neither).

    BUT if you want to share R&D on "business neutral" components such as appserv then feel free to join us ;-)

    To finish my blabla, virus can be a good thing when it comes to vaccine (dixit Dr Pasteur).

    Au revoir,
    JPL.
  50. But maybe re-use LGPL stuff (you are not forced to and you are not forced to contribute neither).

    IANAL/FWIW - I have read some disturbing comments coming out of the FSF (where the LGPL comes from), about using Java LGPL libraries and having the same implications as using GPL, because of the wording regarding "linking" to their APIs. Make sure to get your corporate lawyers to review the use of LGPL libraries. What the FSF lawyer said, if I understand correctly, is to get the assurance from the copyright holders that they will interpret it the way you do. Here's one link on it (you can find other stuff in gmane):

    http://weblogs.java.net/pub/wlg/258

    Again, this only matters for software distribution not internal use, but IANAL ;-).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  51. Cameron,

    Your comment is very interesting because it shows the obvious differences between "legal" & "technical" (and the article from Larry Rosen is quite eloquent on this).

    "linking" or "library" or "api" or etc. are technical words that lawyers do not have in their legal vocabulary. They just know "original work" or "derived work" or "derivative work".

    So any lawyer (from FSF or from IBM) would recommend that when you work with a LGPL code, be sure that your work is not just an extension of this existing work. If that's the case then your work will have to be distributed under the same conditions that the original work i.e. under LGPL licence.

    But on the contrary if your work is an original work .i.e. providing different results from the LGPL code you are re-using (by exemple Knowledge Management using JOnAS), then you i.e. the author of the new code, have the right to choose the licence you want to distribute your original work. And that's where LGPL fits better for industrial needs: "the code is mine because everybody owns it"

    In any case you can stop any "viral" effect: just distribute the 2 codes (LGPL and non-LGPL) on different medias (CD, web sites, etc.) and mix them at the installation time. That is one of the main reasons why Open Source is good business for System Integrators or more generally for "end users" (IS) who mix "Open Source" code just for their own usage without distributing it. But it has to be studied carefully case by case. That's why Open Source is also a good business for lawyers :-)))

    I hope I am as clear as my broken english enables it ;-)

    JPL.
  52. JPL: Excusez my French but we are speaking about BSD (NOT ASF) as licence which enables to exchange code between Apache and ObjectWeb.


    The only reason I brought up ASF is because of Apache's response to the ObjectWeb Group.

    Behlendorf:
    "To be
    clear, BSD-licensed code from any party may be incorporated into Apache
    releases licensed under the Apache license. I would encourage such
    collaboration work to take place wherever the "home" is for such code,"


    Just to clarify, I'm a consultant who has been trying to champion Open Source Initiatives in corporations -- with a lot of pushback. I was just trying to relay to the community that this is what is going on in the Board Rooms with these discussions from my experience. Your mileage may vary. These guys write the checks and my family and I have become accustomed to eating.

    The fact of the matter is that GPL/LGPL, although noble in its cause, is also causing the delay of Open Source adoption in a lot of corporations. Agree or disagree with interpretations, when corporate lawyers say "I can argue that..." you're pretty much screwed on winning any argument with management unless the CEO vetoes.

    To finish my blabla, virus can be a good thing when it comes to vaccine (dixit Dr Pasteur).


    Unfortunately, GPL/LGPL is more like herpes. ;)

    - Frank