What's the best developer-friendly open-source license for Java?

Discussions

News: What's the best developer-friendly open-source license for Java?

  1. Traditionally I have been releasing libraries and frameworks under the LGPL license, because I want to have the developer protections that it offers (ie. changes have to be released as open source under the same license). Sadly, there has been much controversy about LGPL's usefulness in Java projects. There also seems to be a consensus that LGPL projects will never be used in commercial products due to the doubt and uncertainty that surrounds it. Finally, Apache seems to have major problems with LGPL and is taking a long time to make up their mind about it.

    I'm considering moving to another license which offers the same kind of developer protection but is not shunned for commercial usage. The candidates seem to be CPL, MPL or CDDL. The first one has Apache's blessing and the last two will soon be accepted for binary inclusion in Apache projects.

    I quite like the sound of CDDL, but there seems to be a lot of FUD around it. The connection with Sun doesn't seem to be liked by many, but it seems like they merely tried to improve MPL.

    What are your thoughts about CDDL, is it a good choice for an open-source Java web application framework or should I look for something else? Are other licenses with the same developer protection worth considering?

    Threaded Messages (101)

  2. I think the CDDL is a good choice.

    I was initially upset with Sun for not using the pre-exisitng MPL, but after going through the changes I understand why the MPL needed improvement.

    The company that I work for has problems with the LGPL, primarilly due to the confusion on what constitutes a derivative work. This is much clearer in the CDDL... the CDDL (in my view) actually grants the rights that we always thought the LGPL did.

    --John
  3. I was initially upset with Sun for not using the pre-exisitng MPL, but after going through the changes I understand why the MPL needed improvement.

    I have always liked the MPL the best, but have not fully read the CDDL license fully yet. Can you give us a quick run down on the differences? Thanks...
  4. Can you give us a quick run down on the differences? Thanks...

    You can find the differences here:
    http://www.sun.com/cddl/

    Both as redline diffs and descriptions.
  5. There also seems to be a consensus that LGPL projects will never be used in commercial products due to the doubt and uncertainty that surrounds it. Finally, Apache seems to have major problems with LGPL and is taking a long time to make up their mind about it.

    1) JBoss projects are LGPL based and we have a multitude of ISVs using and shipping with JBoss/Hibernate/jBPM/JGroups etc. Novell has no problem with integrating their products with JBoss's LGPL based projects. There are alot of other successful projects like JFreeCharts, JacORB, that are also very popular and are not "shunned" by commercial entities. Don't believe the propaganda Apache puts out about LGPL. FSF has done enough to clarify how LGPL and Java relate to one another.

    2) Who cares if Apache has major problems with the LGPL? That's their problem. Apache has their view of the world, FSF has theirs. LGPL projects have no problems with including apache-style projects.
    I'm considering moving to another license which offers the same kind of developer protection but is not shunned for commercial usage.

    I seriously think you've been brainwashed. The vendors that have a problem with LGPL are the same vendors that want to fork those LGPL projects into their own offerings. That's why vendors like IBM love Apache. They can take what pieces they want for their own commercial gains and have no obligation to give anything back. If anybody thinks that this is not happening, then they need to open their eyes a little bit.

    Really, Copyrights have more effect on an OSS project than anything else. If you own the copyright, you can move to any lic you want. if you don't own the copyright, you can't change the lic. For instance, take JBoss. No matter how evil the bitter blogger crowd thinks JBoss Inc. is becoming, because our contributors retain copyright, we have virtually no chance of ever bring JBoss proprietary. That, combined with LGPL, guarantees projects like JBoss AS and Hibernate will remain open source forever.

    Really, what I think FSF-based licenses do is instead of making users pay with dollar$, you are forcing them to pay with commitment. I think this is quite a reasonable price to pay.

    Bill
  6. One other thing...Although the CDDL may or may not be clearer, I like the fact that LGPL is backed up and defended by a non-profit organization like FSF. If you are looking for developer protections, CDDL may/may not be clearer, but with FSF-based licenses you have a potential champion to stand behind you if you run into problems.
  7. Thanks a lot for the detailed post Bill. I try to not get brainwashed, but it's not always easy ;-) My main question is however if there are not better licenses than LGPL that provide the same benefits and are accepted by Apache. I'm in the position that I can relicense since I have all the copyrights, so if another option makes everybody happy and doesn't cut down on my developer protection, then why not change to it? CDDL looks like it might offer that.
  8. Thanks a lot for the detailed post Bill. I try to not get brainwashed, but it's not always easy ;-) My main question is however if there are not better licenses than LGPL that provide the same benefits and are accepted by Apache. I'm in the position that I can relicense since I have all the copyrights, so if another option makes everybody happy and doesn't cut down on my developer protection, then why not change to it? CDDL looks like it might offer that.

    CDDL may/may not be cleaner, but as I said before, there is a non-profit organization behind LGPL. I know when we had problems with a specific LGPL infringement, the FSF was invaluable to us and provided information like what the best course of action to take and who were the best lawyers out there if we wanted to go that route. I'm pretty sure that they would defend FSF-based licenses legally if the plaintiff didn't have the resources to argue themselves.

    Bill
  9. ... I said before, there is a non-profit organization behind LGPL.

    It looks like FSF does not encourage LGPL at all:
    http://www.fsf.org/licensing/licenses/why-not-lgpl.html

    I recall that somewhere in FAQ they discouraged LGPL too.

    Any clarifications, Bill?
  10. I recall that somewhere in FAQ they discouraged LGPL too.

    They do not discourage usage of LGPL. They strongly advice use GPL ONLY !! :))
    And from that point of view they of course discourage use of ANY OTHER OS LICENSE, not just LGPL :))
  11. I seriously think you've been brainwashed. The vendors that have a problem with LGPL are the same vendors that want to fork those LGPL projects into their own offerings. That's why vendors like IBM love Apache. They can take what pieces they want for their own commercial gains and have no obligation to give anything back. If anybody thinks that this is not happening, then they need to open their eyes a little bit.

    Of course it's happening - and look how successful Apache is as a result. A big part of the reason Apache products are so widely adopted is because of their no-strings-attached licensing.

    Big companies shy away from that 'obligation to give back,' and who can blame them? The LGPL scares the crap out of then because they have a hard time sorting out the implications.

    This means that the LGPL tends to work against the adoption of a project. There is a difficult decision for an open source developer to make here - I hardly think the OP has been 'brainwashed.'


    Cheers,
    -p

    ---
    Patrick Calahan
    Terracotta, Inc.
    http://www.terracottatech.com
  12. I seriously think you've been brainwashed. The vendors that have a problem with LGPL are the same vendors that want to fork those LGPL projects into their own offerings. That's why vendors like IBM love Apache. They can take what pieces they want for their own commercial gains and have no obligation to give anything back. If anybody thinks that this is not happening, then they need to open their eyes a little bit.
    Of course it's happening - and look how successful Apache is as a result.

    Look how successful Linux, GNU, JBoss, Hibernate, MySQL etc... are. Apache successes have nothing to do with their license. Same with Linux, JBoss, etc...
    Big companies shy away from that 'obligation to give back,'

    Which companies? IBM, BEA, Sun?

    Your comment is in direct conflict of what I'm seeing in the adoption of Linux and our own customer base for that matter. I'm not sure what "big companies" I'm allowed, not allowed to mention specifically, but large banks, conglomerates, entertainment, online travel companies, hotel chains, cable sports networks, insurance, major defense contractors, NASA, the US Navy, all use JBoss. I'm not trying to brag, but trying to show you that "big companies" and even the government don't shy away from FSF licensed software.

    LGPL/GPL doesn't stop companies from contributing to Linux.

    LGPL/GPL doesn't stop companies from contributing to JBoss projects.
    I hardly think the OP has been 'brainwashed.'

    Not brainwashed, but definately reguritating the same crap I hear solely from Apache projects whose sole differentiator is their OSS license.

    My tone may seem like I'm picking a fight with you and OP, but, really, I'm just tired of having to re-educate people. I think people need to read less blogs and opinion pieces and see what actually others in the industry are really doing with regards to OSS licenses.

    Bill
  13. Look how successful Linux, GNU, JBoss, Hibernate, MySQL etc... are. Apache successes have nothing to do with their license. Same with Linux, JBoss, etc...

    As I mentioned in a previous post, there is a fundamental difference between the affect a license will have on a standalone product vs. a library that must be linked into or distributed with another product. Even linked into vs. distributed with are different considerations.

    In your list above, all those products except Hibernate are standalone products. Hibernate itself has an express 'clarification' on the product web site (and possibly included with it, I don't remember) that tries to clarify how they interpret one of the more ambiguous linking clauses in the LGPL.

    Even with this clarification there are still companies that will not use LGPL. And there are companies that will use it only because of the clarification. And of course there are companies that don't care at all that it's LGPL and would have used it even without the clarification.

    I don't really have a problem with what the LGPL is trying to achieve. But it was written a long time ago, before things like Java's linking model ever existed in common use, and there are better licenses for the same purpose. On that basis, it's fundamentally a crappy choice for a library. Use BSD, use Apache, use MPL, use CDDL, use whatever, but use something that's clear... This is not about whether something is viral or non-viral (that's another discussion, as to what effect that will have), but about clarity of viralness.

    Regards,
    Colin
  14. I seriously think you've been brainwashed. The vendors that have a problem with LGPL are the same vendors that want to fork those LGPL projects into their own offerings. That's why vendors like IBM love Apache. They can take what pieces they want for their own commercial gains and have no obligation to give anything back. If anybody thinks that this is not happening, then they need to open their eyes a little bit.

    Bill, any one who sells enterprise Java solutions in the real world has run into prospective CLIENTS who consider the use of LGPLd and GPLd software (other than the Gnu Linux Stack) to be a significant, often fatal, black mark. Your subsequent comments make it clear that you have encountered them too.

    What is it that "vendors like IBM" are doing with Apache licensed code that is so horrible that it justifies losing potential clients? (For the sake of argument, we can ignore IBMs contributions to Linux, Java, Eclipse and Apache, which I consider to be quite significant and beneficial.)
  15. 1) JBoss projects are LGPL based and we have a multitude of ISVs using and shipping with JBoss/Hibernate/jBPM/JGroups etc.

    Being in the IT world, I can tell you that none of the projects based on opensource I have seen have actually an ounce of legality in it.

    Vendors (IT companies - should they be a 10-person one or 10000-people one) are clueless about licensing, so are the customers, including corporate and government one.

    Nearly everything which is opensource is seen as 'hey it's free I can take it and sell it as part of the product and there will be a thousand people working for free to maintain it'

    So IMHO you are having a skewed perception of reality about the respect of licenses. It's not because it is adopted that it is understood..or even thought about.

    There's really a big dark black hole out there where the potential of legal battles is absolutely massive if one wants to throw a stone in it.

    Just look at how many projects out there don't even respect the Apache License by acknowledging its use visibly.
  16. Note about new technologies....[ Go to top ]

    in my opinion there is no place in the near future for the style of license of LGPL , CPL , MPL, CDDL in the java space as the new AOP technologies such as mixins ,introduction and dynamic weaving at runtime make them all useless....
    consider the following example:
    company X produced product A and placed it under whatever of these licenses
    company Y make some modification to the core components and so the result have to be covered bythe same licence BUT company Y separated all there changes in some files and made them available at runtime through AOP introduction or mixin or runtime bytecode transformation
    so company Y is in compliance with the license as it distribute the original library but on the other hand it produced completely another product B

    so i think that the java license may be
    1-Commercial
    2-GPL
    3-Apache

    bye
    Joseph Fouad
  17. The question of licensing is a complex one, and there are many factors to consider.

    However, if the factor being examined is how does that license affect potential adoption of the library in various environments, I think anybody is negligent/ignoring reality/ignorant of reality as the case may be if they try to state that LGPL is not poison in some environments.

    As part of my job at a VC/incubator from 99-2004 I was involved hands-on with on the order of a dozen internal companies. I was also involved in terms of performing due-diligence with hundreds of other external companies. My present position puts me in touch and onsite at a number of companies each month. The reality is that the ambiguity of the LGPL scares lawyers to no end, and because of this LGPL-licensed software is outright not allowed, or at least a big concern, at many companies. This is especially the case at companies that are building a product for sale to others, or are trying to build up to be sold, and probably less so at companies that are building software for internal use. A typical scenario is that a company will catolog every piece of open-source (and non) library they are using, along with the license of each lib, and make hard decisions about what they're willing and not willing to use, in terms of a risk-factor for that license.

    Again, this is just one factor to consider.

    The other thing I want to add is that there is a fundamental difference to the effect that a license will have on a standalone product like MySQL or JBoss Application Server, vs. the effect it will have on a library such as, to pick a product near and dear to my hear, Spring Framework. If you (as a hypothetical sotware producer of some sort) are putting out a product that is probably going to target JBoss as the deployment server, and MySQL as the deployment database, it is probably reasonable for you to expect that your customers will pull down and install those pieces. So even something like the viral GPL (as used by MySQL) is not a concern to you, as it doesn't affect your product. On the other hand, when using and linking to an ambedded library like Spring, you are distributing the two together, so the licesne of the library, including the effect or potential effect it will have on your own code, will become much more relevant.

    Regards,
    Colin
  18. The question of licensing is a complex one, and there are many factors to consider.However, if the factor being examined is how does that license affect potential adoption of the library in various environments, I think anybody is negligent/ignoring reality/ignorant of reality as the case may be if they try to state that LGPL is not poison in some environments.As part of my job at a VC/incubator from 99-2004 I was involved hands-on with on the order of a dozen internal companies. I was also involved in terms of performing due-diligence with hundreds of other external companies. My present position puts me in touch and onsite at a number of companies each month. The reality is that the ambiguity of the LGPL scares lawyers to no end, and because of this LGPL-licensed software is outright not allowed, or at least a big concern, at many companies. This is especially the case at companies that are building a product for sale to others, or are trying to build up to be sold, and probably less so at companies that are building software for internal use. A typical scenario is that a company will catolog every piece of open-source (and non) library they are using, along with the license of each lib, and make hard decisions about what they're willing and not willing to use, in terms of a risk-factor for that license.Again, this is just one factor to consider.The other thing I want to add is that there is a fundamental difference to the effect that a license will have on a standalone product like MySQL or JBoss Application Server, vs. the effect it will have on a library such as, to pick a product near and dear to my hear, Spring Framework. If you (as a hypothetical sotware producer of some sort) are putting out a product that is probably going to target JBoss as the deployment server, and MySQL as the deployment database, it is probably reasonable for you to expect that your customers will pull down and install those pieces. So even something like the viral GPL (as used by MySQL) is not a concern to you, as it doesn't affect your product. On the other hand, when using and linking to an ambedded library like Spring, you are distributing the two together, so the licesne of the library, including the effect or potential effect it will have on your own code, will become much more relevant.Regards,Colin

    Based on my experience as an LGPL vendor, the problem is an education problem more than anything based in reality. LGPL certainly hasn't curbed the adoption of Hibernate, or those ISVs porting products to Linux. The originator of this thread already linked to the FSF's position on Java.

    Bill
  19. Based on my experience as an LGPL vendor, the problem is an education problem more than anything based in reality. LGPL certainly hasn't curbed the adoption of Hibernate, or those ISVs porting products to Linux. The originator of this thread already linked to the FSF's position on Java.Bill

    W/regards to curbing adoption, that's debatable. Obviously Hibernate is very popular, but I _have_ come across companies that refuse to consider Hibernate even with the 'clarification' as a consideration, never mind how they would have treated it if it was standard LGPL.

    This may be an education thing "more than anything based in reality", but why should I have to educate my potential customers when there are other license choices which try to achieve the same things as LGPL but do it in a clearer fashion and don't require the "education", or inspire discomfort in a significant number of people.

    Regards,
    Colin
  20. LGPL certainly hasn't curbed the adoption of Hibernate...

    It has at the company I work for, we are not allowed to
    use Hibernate, because of LGPL (even though Hibernate has
    clarified its position on that regard).
  21. LGPL certainly hasn't curbed the adoption of Hibernate, or those ISVs porting products to Linux. The originator of this thread already linked to the FSF's position on Java.Bill

    Unfortunately, it did curb the adoption of Hibernate by the company that I work for (I think I mentioned this before). In my opinion the LGPL code didn't put us at risk... but my opinion did not count (sigh).

    Bill, has JBoss evaluated the CDDL and come up with reasons for not adopting it?

    Are you hostile towards the CDDL, or do you just think it's an LGPL clone that just muddies up the water?

    From reading the two licenses (CDDL and LGPL), they look like they accomplish the same goal (much more so then the Apache license). I'm not seriously suggesting that JBoss switch licenses... just wondering what your position would be towards CDDL product (kind of like the evaluation you did before embracing the Apache licensed Tomcat project).

    --John
  22. Bill, has JBoss evaluated the CDDL and come up with reasons for not adopting it? Are you hostile towards the CDDL, or do you just think it's an LGPL clone that just muddies up the water?From reading the two licenses (CDDL and LGPL), they look like they accomplish the same goal (much more so then the Apache license). I'm not seriously suggesting that JBoss switch licenses... just wondering what your position would be towards CDDL product (kind of like the evaluation you did before embracing the Apache licensed Tomcat project).--John

    JBoss can clarify this better, but my understanding is that JBoss doesn't even have the option of changing the license on most or all of the products they've released under LGPL, since they don't assume copyright of code introduced into the products, but leave it with the original author. On that basis, all the original authors (many of whome don't work for JBoss) of the JBoss code would have to agree to a re-licensing, something that is probably not achievable.

    So I can certainly understand one reason why JBoss would be very pro LGPL, in that they have no choice but to stick with it for at least some of their products that are using it. On the other hand, this is not the basis for anybody else to choose LGPL.

    Regards,
    Colin
  23. Colin, you have an excellent summary of the sitaution (here and in your other posts in this thread).

    A long time ago (from the very beginning I believe) JBoss went LGPL. Whether this was a deliberate well-reasoned decision or just going with the crowd is now irrelevant. Many people have contributed to that code over time and JBoss Inc. has no copyright assignment style clause (as the mySql folks do). As a result JBoss Inc. doesn't own the majority of the code. Instead, it's mostly a large number of individuals who own the copyrights to various pieces of the code. And some of those people are, today, not all that friendly with JBoss Inc.

    By definition, JBoss Inc. can't change the license of copyrighted works that they do not own. They do not own the copyright on most of the JBoss code base, and as such they can't do squat about the license.

    Today, I personally think the LGPL aspect of the JBoss code is hurting the company, but there's nothing they can do about it short of re-writnig all the code from scratch. As such, all the JBoss people come across as passionate advocates of LGPGL. I doubt any of the developers passion comes for the license's own merits (clearly I doubt that because most of them seem to not understand the nuances). But they are passionate about LGPL the same way a man hanging over a 2,000 foot chasm feels passionately about the rope holding him up. In other situations he probably wouldn't care about rope at all, and if he did he'd make a different choice, but when it's manilla line holding you from falling 2,000 feet you're going to become a very, very passionate advocate of manilla rope :-)

    If JBoss employees like Bill were really so zealous in their licensing claims they would at least post copyrights on the code they own. While they rant on about how fabulous the LGPL is in protecting their rights, they actually are not very diligent about truly protecting those rights in well-known ways (e.g. clearly marking your work with copyright notices identifying you as the author). At the same time, it's amusing to see other signs of consistency.

    For one, we see the JBoss portal forums source code:

    /*****************************************
     * *
     * JBoss Portal: The OpenSource Portal *
     * *
     * Forums JBoss Portlet *
     * *
     * Distributable under GPL license. *
     * See terms of license at gnu.org. *
     * *
     *****************************************/

    Two things to note: 1, it's under GPL, not LPGL. Second, as you'll note it says "See terms of license at gnu.org". So JBoss isn't just exclusively LGPL but in some situations GPL. And they are so passionate about defending their rights and license that ... they send you off to gnu.org. They don't even specify which version of the GPL.

    On JBoss AOP we see:

    /***************************************
    * *
    * JBoss: The OpenSource J2EE WebOS *
    * *
    * Distributable under LGPL license. *
    * See terms of license at gnu.org. *
    * *
    ***************************************/

    Picking a file, we'll see, say, "org.jboss.aop.advisor.Advisor.java". The file has over 64 revisions yet it has no @author tag or copyright notice. Go take a look:

      http://anoncvs.forge.jboss.com/viewrep/JBoss/jboss-aop/src/main/org/jboss/aop/Advisor.java?r=1.64

    In fact it appears that none of the code at:

      http://anoncvs.forge.jboss.com/viewrep/JBoss

    ...have any copyright notices at all. Considering that JBoss developers don't even bother to display prominent copyright notices on their own work it's hard to credit to listen to their expert advice as an LGPL vendor.

    In any case - JBoss rant aside, I completely agree with you Colin that JBoss advocacy of the LGPL isn't a very strong argument for other people to go that route. As you say, they have no choice but to stick with that route. But that doesn't mean that others should put themselves in the same boat.
  24. Considering that JBoss developers don't even bother to display prominent copyright notices on their own work it's hard to credit to listen to their expert advice as an LGPL vendor.

    IANAL, etc.

    You clearly don't understand copyright. (Kettle-Pot-Black :-)

    You don't need to explicitly copyright anything, it is assumed unless there is information to the contrary.

    And it requires an explicit "writing" to transfer it
    to somebody else (including the public domain).

    The lack of explicit copyright just reduces the remedies
    you can apply for under the law. e.g. remember the BSD/Unix trade secret case?

    Useful links:
    USC
    http://www.law.cornell.edu/uscode/html/uscode17/usc_sup_01_17.html
    Collective works
    http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_00000404----000-.html
  25. IANAL, etc.
    You don't need to explicitly copyright anything, it is assumed unless there is information to the contrary.

    This is true in a general sense. But what happens in an OpenSource project if a source file has no explicit copyright? Is it the CVS owner that has copyright? What happens if there are many "authors", and how do you define author? Is adding comments considered an act of authoring? etc. Would any arbitrary definition of authorhood have any validity in a court? After all, we could argue this and that in endless clueless variations, but I think that at the end of the day it's court applicability that wins.

    So, since it's not clearly defined who has the "implicit copyright" in this case I'd say that you don't understand copyright ;-) So there!
  26. IANAL, etc.
    You don't need to explicitly copyright anything, it is assumed unless there is information to the contrary.
    This is true in a general sense. But what happens in an OpenSource project if a source file has no explicit copyright? Is it the CVS owner that has copyright? What happens if there are many "authors", and how do you define author? Is adding comments considered an act of authoring? etc. Would any arbitrary definition of authorhood have any validity in a court? After all, we could argue this and that in endless clueless variations, but I think that at the end of the day it's court applicability that wins.So, since it's not clearly defined who has the "implicit copyright" in this case I'd say that you don't understand copyright ;-) So there!

    The work doesn't not lose it's implicit copyright status just because you don't know who the author is. And even if it explicitly has an author listed, that doesn't mean they are still the copyright owner. Through copyright assignment, corporate buyouts, mergers, etc. the actual owner of the copyright might be far removed from the people who authoried it. Now, it would be nice if it did lose it's copyright status if you can't find the owner because then groups like Project Gutenberg would be able to add all kinds of stuff which it currently can't because they can't find the owner of various works.
  27. The work doesn't not lose it's implicit copyright status just because you don't know who the author is.

    No, you don't lose your rights because you don't have an explicit notice. But you're making it harder to establish those rights definitively.

    In fact in this thread you seem to advocate obfuscating your ownership and relying on implicit copyright! That seems plain wreckless to me.
  28. IANAL, etc.
    You don't need to explicitly copyright anything, it is assumed unless there is information to the contrary.
    This is true in a general sense. But what happens in an OpenSource project if a source file has no explicit copyright? Is it the CVS owner that has copyright? What happens if there are many "authors", and how do you define author? Is adding comments considered an act of authoring? etc. Would any arbitrary definition of authorhood have any validity in a court? After all, we could argue this and that in endless clueless variations, but I think that at the end of the day it's court applicability that wins.So, since it's not clearly defined who has the "implicit copyright" in this case I'd say that you don't understand copyright ;-) So there!

    Let's have an "I know less about copyright that you competition". :-)

    Obviously, the person who owns the copyright is the
    person that can prove he made the first copy and/or
    wrote the original contribution.

    At least in the UK, people have been known to send
    themselves copies through the mail to establish
    both the author and the date.

    In JBoss's case, it is the CVS record.
    Picking one at random :-)
    http://anoncvs.forge.jboss.com:8080/viewrep/JBoss/jboss/src/main/org/jboss/ejb/Container.java#bTelkel
  29. In JBoss's case, it is the CVS record.Picking one at random :-)http://anoncvs.forge.jboss.com:8080/viewrep/JBoss/jboss/src/main/org/jboss/ejb/Container.java#bTelkel

    Thanks for pointing that out, Adrian! This is something I should have done a long time ago then:
    ----------------------------------------------------------
    I, Rickard Öberg, hereby change the license of all my copyrighted source files in JBoss CVS from LGPL to GPL. As I don't have access to the actual CVS repository I consider this statement to be a written fact of this change, including date.

    sincerely,
      Rickard Öberg
    ----------------------------------------------------------
    I will leave it to those better versed in legalese to figure out the implications of this.
  30. Rickard Öberg, hereby change the license of all my copyrighted source files in JBoss CVS from LGPL to GPL.

    While you, as the copyright holder, can license those files under GPL, to the best of my knowledge you cannot revoke the previous LGPL license.

    Nonetheless, that was funny.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  31. While you, as the copyright holder, can license those files under GPL, to the best of my knowledge you cannot revoke the previous LGPL license.
    I'm not revoking it. I'm changing it. Remember, JBoss CVS is not a copy, or a user copy, it's the original!

    For users who already have a copy of the source it will, indeed, remain LGPL. That's fine. But from now on, any copies made from the JBoss CVS shall use the new license, which is GPL. So there.
  32. quinquennial licence change[ Go to top ]

    I find this really funny: http://anoncvs.forge.jboss.com:8080/viewrep/JBoss/jboss/src/main/org/jboss/ejb/Container.java?r1=1.32&r2=1.33
  33. You clearly don't understand copyright. (Kettle-Pot-Black :-)

    You don't need to explicitly copyright anything, it is assumed unless there is information to the contrary.

    No, you are not required to do so. You are also not required to put on boots when it's 20 degrees below zero outside, but a prudent person generally does so ;-)

    People still generally do put copyright notices on their works for three excellent reasons: 1) to clearly show that the work is copyrighted, 2) to show who's claiming the copyright, and 3) to show the initial date of copyright. You are not required to do so, but doing so makes things abundantly clear. If you don't include it, you are making enforcement of your copyright harder for no good reason.

    The bottom line for me - you guys are too dumb to include copyright notices in your own source. If you're not smart enough to say "copyright (c) 2005 Adrian Brock" then I'm certainly not going to give you a lot of credit for your views on open source licenses.
  34. I remember now, why I don't normally post on TSS.
    It just dissolves in logical fallacies to try to win
    arguments. :-)
    If you're not smart enough to say "copyright (c) 2005 Adrian Brock" then I'm certainly not going to give you a lot of credit for your views on open source licenses.

    You changed the subject, an emotive statement about
    copyright becomes a conclusion about licenses?
    Something I expressed no opinion on (at least in this thread :-).

    <blockqute>I'm not revoking it. I'm changing it. Remember, JBoss CVS is not a copy, or a user copy, it's the original!
    Factually inaccurate, the original was on your hard disk
    unless you had some funky editor that updated cvs directly?
  35. Thanks for pointing that out, Adrian!

    If you would then be so kind as to help me update the copyright statements in JBoss CVS. Just change "LGPL" to "GPL" and I'm happy. If you're busy you can begin by just changing the file you just referenced. That'd be a good start.

    Thanks for helping me keeping my code Free and in the hands of the Developer! I never knew Freedom could be so much fun!
  36. I remember now, why I don't normally post on TSS.
    It just dissolves in logical fallacies to try to win
    arguments. :-)

    Hah, this from the man who lives to abuse people needing help in the JBoss forums. Based on past behavior I'd say you don't normally post on TSS because you don't own it.
    You changed the subject, an emotive statement about
    copyright becomes a conclusion about licenses?
    Something I expressed no opinion on (at least in this thread :-).

    The subject didn't change at all, copyright is deeply intertwined with software source licensing. If you consider that, then I think my reasoning makes sense. JBoss developers as a collective either know or care so little about copyrights that they aren't willing to take a simple step to make their copyrights more easily defensible. You then go on to say how a CVS record somehow indicates ownership. Sadly, Marc Fleury's little incident with log4j code is just one example that a CVS checkin with a given user name does not mean that the code is owned by said user name.

    Given a pretty poor record in copyright issues you're not the first people I would turn to on advice on open source licensing. This isn't a logical fallacy, it's common sense.
    Factually inaccurate, the original was on your hard disk
    unless you had some funky editor that updated cvs directly?

    You said that you don't need copyright notices in the code because the CVS tells you who did what. Rickard (rather cleverly I must say) turned that notion around on you.
  37. The subject didn't change at all

    You lost the argument and so tried to change it to something
    else. No amount of weasling alters that.
    Rickard (rather cleverly I must say) turned that notion around on you.

    I've given up arguing, I get more sense out of my senile grandmother. ;-)
  38. Parts of JBoss are now GPL[ Go to top ]

    I've given up arguing, I get more sense out of my senile grandmother. ;-)
    Well, I'm not arguing anymore. And I sadly have to admit to having absolutely no humor whatsoever, so I'm not joking either.

    The parts of JBoss that I have written, and therefore have copyright of, are now GPL. It's that simple.

    You can either comply with that and update the CVS to reflect this reality, or you can choose not to. Either way, distributing JBoss from this day on using the LGPL is to be considered a breach of the GPL license. Not to mention making JBoss Inc. hypocrites. Which, perhaps, could be considered funny.
  39. Parts of JBoss are now GPL[ Go to top ]

    I've given up arguing, I get more sense out of my senile grandmother. ;-)
    Well, I'm not arguing anymore. And I sadly have to admit to having absolutely no humor whatsoever, so I'm not joking either.The parts of JBoss that I have written, and therefore have copyright of, are now GPL. It's that simple.You can either comply with that and update the CVS to reflect this reality, or you can choose not to. Either way, distributing JBoss from this day on using the LGPL is to be considered a breach of the GPL license. Not to mention making JBoss Inc. hypocrites. Which, perhaps, could be considered funny.

    The GPL and LGPL don't work that way. Once you release software under the LGPL it's released under the LGPL forever. Anyone with a copy of the code when it was under the LGPL is free to continue redistributing it under that license. You can choose to do a new release under the GPL, but that doesn't affect JBoss (or their CVS server) or anyone else who has a copy already.
  40. Parts of JBoss are now GPL[ Go to top ]

    A quick read on LGPL license got me to this:
    3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.

    Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.

    As I undestand it, JBoss' CVS copies of LGPL code may indeed be changed to GPL.

    Regarding copyright notices, this is another quote I found:
    1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.

    So it seems copyright notices are actually obligatory on LGPL code.

    Regards,
    Henrique Steckelberg
  41. As I undestand it, JBoss' CVS copies of LGPL code may indeed be changed to GPL.
    Thanks for pointing this out! The devil is indeed in the details.
    Regarding copyright notices, this is another quote I found:
    1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
    So it seems copyright notices are actually obligatory on LGPL code.Regards,Henrique Steckelberg
    Let me get this straight. JBoss Inc. considers LGPL to be a "good" OpenSource License, and yet they are obviously not complying it in the first place by violating the above terms of the license? Hmmm... so if the application of the LGPL license is essentially invalid because of this, this should reasonably mean that JBoss is basically released under *NO* *valid* license whatsoever? Hmm.... very very interesting.

    I'm dying to find out how this will all end :-)
  42. Parts of JBoss are now GPL[ Go to top ]

    I personally love section 2b) of the LGPL. Let's say that a bunch of people wrote code and released it under the LGPL. Someone else comes in and changes it. Maybe it's part of the same project, maybe it's not. It doesn't matter, they're allowed to do this because the copyright holder (the author) licensed this stuff to everyone else under the LGPL.

    Now people change the code over time. The LGPL says:
    2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
    a) The modified work must itself be a software library.
    b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.

    So anyone other then the original copyright owner _must_ ensure that the file(s) in question stay as part of a "software library". And they must cause the files modified to carry prominent notices stating that you changed the files and the date of the change.

    Is the JBoss application server a "software library"? It may squeak in do the LGPL making little sense in a Java dynamic VM world (but in logical terms it is an executable and not a library and probably in violation in the spirit of the license if not the letter).

    Now - does JBoss carry prominent notices of all changes including the author of the change and date of the change? Note that the LGPL is very specific here. It doesn't allow you to use CVS history or anything like that. It says "You must cause the files modified to carry prominent notices...". The files themselves.

    In the file cited, Rickard, it appears that everyone who has modified that file since you created it has been in violation of your license since it does not contain prominent notices of everyone who's changed it and when. Given how much of your code is in JBoss you could probably stop them from distributing any JBoss code until y'all work something out :-)
  43. Parts of JBoss are now GPL[ Go to top ]

    Given how much of your code is in JBoss you could probably stop them from distributing any JBoss code until y'all work something out :-)
    I think you just found out where JBoss Inc. will spend their beloved VC money. You know where to find me.
  44. Parts of JBoss are now GPL[ Go to top ]

    A quick read on LGPL license got me to this:
    3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.
    As I undestand it, JBoss' CVS copies of LGPL code may indeed be changed to GPL.Regarding copyright notices, this is another quote I found:
    1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
    So it seems copyright notices are actually obligatory on LGPL code.Regards,Henrique Steckelberg

    The requirement for an appropriate copyright notice and disclaimer of warranty is required for "verbatim copies of the Library's complete source code", not for individual files. And last time I checked, JBoss does include the necessary documentation and files to meet that requirement.

    It would help if people at least read what they quoted; they'd be less likely to make sure obtuse mistakes.
  45. Parts of JBoss are now GPL[ Go to top ]

    The requirement for an appropriate copyright notice and disclaimer of warranty is required for "verbatim copies of the Library's complete source code", not for individual files. And last time I checked, JBoss does include the necessary documentation and files to meet that requirement.It would help if people at least read what they quoted; they'd be less likely to make sure obtuse mistakes.
    Are you a lawyer? I am not. Neither is English my mother tonge. Regardless, reading what I quoted was the very origin of the "obtuse mistake". I assume most people are not as knowledgeable in legalese as you, nor should they be, that's why "obtuse mistakes" are bound to happen.
    BTW, care to point us to the documentation you checked? If I understand it right, LGPL code distributors should provide for some kind of blanket statements of the sorts "All copyrights are held by the original creator of the materials.". But we were discussing the case where the original author wouldn't provide copyright notices, and its implication due to clause 1 of LGPL. Your argument doesn't make it any more clear whether copyright notices should be included in each file or not.
  46. Parts of JBoss are now GPL[ Go to top ]

    The GPL and LGPL don't work that way. Once you release software under the LGPL it's released under the LGPL forever. Anyone with a copy of the code when it was under the LGPL is free to continue redistributing it under that license. You can choose to do a new release under the GPL, but that doesn't affect JBoss (or their CVS server) or anyone else who has a copy already.
    As long as the copy of JBoss sources does not come from JBoss CVS you are absolutely correct, and I have no problem with that. As you said, the LGPL works this way. However, isn't it correct that any new copies from JBoss CVS of source files to which I have copyright are to be considered licensed through GPL?
  47. Parts of JBoss are now GPL[ Go to top ]

    The GPL and LGPL don't work that way. Once you release software under the LGPL it's released under the LGPL forever. Anyone with a copy of the code when it was under the LGPL is free to continue redistributing it under that license. You can choose to do a new release under the GPL, but that doesn't affect JBoss (or their CVS server) or anyone else who has a copy already.
    As long as the copy of JBoss sources does not come from JBoss CVS you are absolutely correct, and I have no problem with that. As you said, the LGPL works this way. However, isn't it correct that any new copies from JBoss CVS of source files to which I have copyright are to be considered licensed through GPL?

    No, any new copies which come from you would be under the GPL. Your original contribution to JBoss is still under the LGPL. Once you distribute the source under the LGPL to someone (in this case JBoss) they can continue to redistribute that code under the LGPL until the end of time.

    Even if you had a case here (which you don't) all they would need to do to circumvent the problem is to remove the offending files from their CVS repository and then check in a new copy (of the exact same code) from whatever their last release was. Since you can't dispute the license of the last release, that code is under the LGPL. But, like I said, there is no case here, they aren't the original author and received the code under the LGPL. So as long as they honor the license (if they didn't the license would be revoked and they'd lose all priveledges), they can continue to redistribute it under that license for as long as they want to.
  48. Parts of JBoss are now GPL[ Go to top ]

    But, like I said, there is no case here, they aren't the original author and received the code under the LGPL. So as long as they honor the license (if they didn't the license would be revoked and they'd lose all priveledges), they can continue to redistribute it under that license for as long as they want to.
    As Henrique pointed out, they are not honoring the license, specifically, the prerequisites of the license. So regardless of what I say and do, the current reference to LGPL is invalid.

    So perhaps no VC money, but still an interesting situation ;-)
  49. Parts of JBoss are now GPL[ Go to top ]

    Joke or not, this really raise some questions in my mind (IANAL, etc.):

    1) if indeed JBoss (or any other party, for that matter) is not honoring the license, who's to "sue" them? OSI? FSF? Anyone? Copyright owners? No one?

    2) Are all open source developers actually honoring their code licenses? From what I perceived in this thread, few actually know all the clauses that make up a rather common and known license (LGPL), I wonder about the thousands and thousands of developers dealing with OS projects daily, how many actually do know how they are affected by license choice (directly or indirectly), like mandatory copyright notices and such.

    3) taken the rather blurry state of affairs surrounding OS licenses, is it mere question of time until parties start fighting each other regarding license breach? I am taking this LGPL to GPL example here in this thread as one case that could evolve to court somehow (far beyound my limited law knowledge, BTW) if someone decided to go down that road, as an example.

    4) If in the end no one would ever sue anyone for license breaches, what's the reason for their very existence in the first place? Ok, I've seen cases of companies sueing others for open-source license breaches, but mainly for copyright issues or copying OS code into closed-source software. What about parties not following these rather "secondary" clauses, like mandatory copyright notices, would it ever reach the court for some party not honoring it? If not, what's the reason for them?

    Let me make this clear here: I am not pro/against anyone or any company, these are just genuine doubts I have about these issues.

    Regards,
    Henrique Steckelberg
  50. Parts of JBoss are now GPL[ Go to top ]

    1) if indeed JBoss (or any other party, for that matter) is not honoring the license, who's to "sue" them? OSI? FSF? Anyone? Copyright owners? No one?

    Generally the copyright holders I believe. But since it's a zero cost license all you can do is revoke the license and attempt to block them from distributing. If they don't stop then I don't know what the actual penalties would or could be.
    2) Are all open source developers actually honoring their code licenses? From what I perceived in this thread, few actually know all the clauses that make up a rather common and known license (LGPL), I wonder about the thousands and thousands of developers dealing with OS projects daily, how many actually do know how they are affected by license choice (directly or indirectly), like mandatory copyright notices and such.

    Most developers I've talked to do not really understand the LGPL or GPL. Most developers who release under the (L)GPL have never even read it in detail, only skimmed it at best.
    3) taken the rather blurry state of affairs surrounding OS licenses, is it mere question of time until parties start fighting each other regarding license breach? I am taking this LGPL to GPL example here in this thread as one case that could evolve to court somehow (far beyound my limited law knowledge, BTW) if someone decided to go down that road, as an example.

    A corporation always seems to be involved from what I've seen. I don't know of any cases of individual open sourcer on open sourcer (legal) action.
    4) If in the end no one would ever sue anyone for license breaches, what's the reason for their very existence in the first place?

    Good question. I'm not sure what teeth the GPL or LGPL actually have. Traditionally money or "other considerations" are involved in copyright disputes. But there's no money here.

    This case at hand is rather interesting. Rickard owns the copyrights for many files in JBoss. He used to be part of the project and many of the initial revisions are his. Now he's not part of the project, and meanwhile JBoss contributors have definitely changed his files. And they have definitely not lived up to the LGPL terms. The LGPL pretty clearly states that you must reveal the identity of anyone changing an LGPL work and the date of the change and that you must do so inside of the modified files. If you don't the license can be revoked.

    It seems to me that Rickard could revoke his license on those files if he'd like. But I don't know where that would leave the JBoss CVS tree or the nineteen bazillion downloaded copies of JBoss that Marc Fleury has claimed. I think it's clear in many cases there's tons of derived work and lots and lots of distributing has gone on. But I don't know what it means precisely to revoke a free license (or what you can do if they ignore your assertion that their license is revoked).
  51. Parts of JBoss are now GPL[ Go to top ]

    Ok, the picture I have right now is that OS developers don't really know how big a bomb they've got in their hands. Maybe there are some lawyers who can get a grasp on all this, but the large majority of OS people are dealing with it purely on good will, or so it seems. We all expect others to honor licenses, we all thrust everything will work simply because, well, it has worked until now, so it must be ok, right? (if you think about it, it's amazing how well it ended up working, given all the "blind" faith involved in the process! No wonder some people treat this subject almost like a religion! ;)
    The problem is when some big corporates start taking advantage of this (SCO anyone?), the rest of OS community will always live under this shadow if open source licensing doesn't get one clear and definitive treatment regarding what can be done, what can't, what are the actual consequences of breaches and so on. Anyway, given that open source is about lots of people contributing to a project, it gets hard to point fingers when things go wrong. Who'd you take to court in case Spring breaches a license? Rod himself? What about the thusands of developers who contributed to the project, wouldn't they be liable too?
    Right now things are too messy, my fear is that we would only learn how far we've gone until there's no way back. I just hope there won't be a precipice at the end of the road... ;)

    Enough philosophy for today! :)

    Regards,
    Henrique Steckelberg
  52. Parts of JBoss are now GPL[ Go to top ]

    But, like I said, there is no case here, they aren't the original author and received the code under the LGPL. So as long as they honor the license (if they didn't the license would be revoked and they'd lose all priveledges), they can continue to redistribute it under that license for as long as they want to.
    As Henrique pointed out, they are not honoring the license, specifically, the prerequisites of the license. So regardless of what I say and do, the current reference to LGPL is invalid.So perhaps no VC money, but still an interesting situation ;-)

    As I replied to Henrique, what he wrote is contradicted by the license terms themselves. As long as JBoss includes the license and warranty information for the entire product and they don't remove any copyright statements you put in then they're completely in the good. Even if they did remove the copyright statements no court would enjoin them from redistributing your code, they would merely require them to put the statements back in.

    This situation isn't interesting, it's dull. It's a group of people who don't like JBoss and don't understand copyright law trying to find some "trick" to make their lives difficult. That isn't the way the law works and these tricks would get you laughed out of court. But if you want to waste your money having a lawsuit thrown out, go ahead. I'm done correcting people gross ignorance of these matters.
  53. So what, is the LGPL toothless then?[ Go to top ]

    As I replied to Henrique, what he wrote is contradicted by the license terms themselves. As long as JBoss includes the license and warranty information for the entire product and they don't remove any copyright statements you put in then they're completely in the good.

    And how about the section I quoted, Chris? To refresh your memory:
    2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
    a) The modified work must itself be a software library.
    b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.

    JBoss clearly did not comply with this clause (nor do many open source projects). This isn't an interpretation, it's what the license says.
     Even if they did remove the copyright statements no court would enjoin them from redistributing your code, they would merely require them to put the statements back in.

    Are you saying that the LGPL actually has no teeth then? See section 8 of the LGPL:
    8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License.

    This is very plain language. If you do not follow the termins expressly provided under the license, your rights under the license are terminated. If this isn't true then it would seem to me that there was little point in specifyin g it in the license in the first place.

    As for me, I'm surprised anyone would use a license like this. It's vague and confusing and has, IMHO, inappropriate references. For example, section 14:
    14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

    In licensing your own work, who gives a flying fart what the FSF will make exceptions for in their own work? The idea is that it's not about the FSF's work - it's about yours.

    Likewise:
    13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

    Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.

    JBoss and many other projects don't bother to specify a version number. This means that they're relying a) the FSF's good will, and b) the FSF's competence. If the FSF intentionally or through a mistake releases a new version of the LPGL, then in cases like JBoss' people can ignore the current LGPL terms and take on the new ones as well. Bill Burke seems to think this is fabulous. But in fact the FSF could theoretically have a major leadership change and publish something called LGPL version 10.0 which reads like a BSD license. This is unlikely in the extreme - but not impossible. And yet the advice here from many is to license your code in such a way that another organization can change the licensing terms (and in fact this is what JBoss and many others do).
  54. One more thing..[ Go to top ]

    One more thing..
    Factually inaccurate, the original was on your hard diskunless you had some funky editor that updated cvs directly?
    That is both correct and irrelevant. I had an "original" on my hard disk. And another "original" scribbled on paper next to my computer. Parts of it was in a separate notebook. But the "original" of relevance, which I created (which is what defines "originality" in this context), and therefore have copyright of, is the source file checked into JBoss CVS. In terms of copyright all of the above mentioned "originals" are Copyright (C) Rickard Öberg.
  55. Are you hostile towards the CDDL, or do you just think it's an LGPL clone that just muddies up the water?From reading the two licenses (CDDL and LGPL), they look like they accomplish the same goal (much more so then the Apache license).

    The LGPL has one large advantage, that you can use it with GPLd code *and sell/distribute the result to your clients*. Otoh, CDDL and GPL don't mix, so you're stuck not being able to reuse GPLd libraries or to use CDDL licensed code in GPLd apps.

    There are two reasons for CDDL, afaict: Sun needed a way to let people use OpenSolaris code under a weak copyleft license that explicitly deals with patents, by granting a strictly limited patent use license with a retaliation clause. Other licenses do that, too, among others the Apache License 2.0. But that one's not copyleft, so it would have allowed closed source forks of Solaris. So Sun took the MPL and fixed the more obvious mistakes.

    As a more pressing reason for coming up with its own license, Sun probably didn't want to have other people with different goals (ASF, FSF) interpret their crown jewel's (i.e. Solaris) license for them, I guess. By having its own license, Sun can authoritatively say 'we mean this to be like that', and that's all the opinion that matters. Netscape, after all, is dead, and therefore unlikely to interfere with Sun's interpretation of the CDDL.

    If you are not Sun, i.e. don't have a portfolio of software patents around your neck, then the CDDL, just like the original MPL and its other derivatives, is probably overkill, if you just need a copyleft license.

    In essence, if you are trying to profit from software, you in general try to leave some opportunities to earn your income by combining your work with the works of others. If you chose a too strong copyleft, like the GPL, unless you can relicense, you can't profit from opportunities to combine that work with people stuck with proprietary software. If you chose a weak copyleft with restrictive patent licenses (which does not make sense if you don't have patents, anyway), like CDDL, MPL etc., you can't profit from opportunities to combine that work with people stuck with GPLd software.
    So if you want to keep all your opportunities to profit from combining your work with others open, you can chose the LGPL, if you want a copyleft license. If you don't want a copyleft license, then the plain two clause BSD license or MIT are good enough for most purposes.
    cheers,
    dalibor topic
  56. The LGPL has one large advantage, that you can use it with GPLd code *and sell/distribute the result to your clients*.

    this is not true

    you can distribute a component licenced under LGPL (or any other OSS licence for that matter) as part of a larger GPL-ed work, but you cannot do the reverse.

    So, LGPL has no special advantage w.r.t. GPL
  57. Potential problem with the CPL[ Go to top ]

    From the CPL:
    This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America.
    Believe it or not, this can be a sticking point. The company that I work for has actually rejected agrteements that are governed by the laws of another state (or country).

    --John
  58. Choice of Venue[ Go to top ]

    Well, that's understandable. If you are not in the US, then your company's lawyers probably don't know the US IP laws by heart, and shouldn't have to.

    cheers,
    dalibor topic
  59. ...from folks who said that the only reason they felt comfortable contributing was that PMD was under a BSD license. I can see why, too - I kind of hesitate to poke around someone else's GPL'd static analysis code, since if the techniques used there show up in PMD it might, well, raise questions.

    And sure, Compuware is using PMD in OptimalAdvisor. But hey, that's cool - they've chosen to contribute some code back, and one of their guys has been posting to the PMD forums. And even if they explicitly contributed nothing at all, it'd still be another group out there growing the PMD mindshare. Good times!
  60. Why would you want to do that? Because your lawyers don't understand the LGPL.

    See, Sun's JRE and JDK both include LGPL licensed software. Read this:

    http://java.sun.com/j2se/1.5.0/J2SEv5.0.THIRDPARTYLICENSEREADME.R2.txt

    "%% The following software may be included in this product: Common Unix Printing System API Libraries (CUPS API library); Use of any of this software is governed by the terms of the license below:

    GNU LIBRARY GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION ..."

    [snip]

    So if your lawyers insist that the LGPL in case of Java has some magical effect that makes it totally different and infect every source code it touches, and turn it into (OMG!) Free Software, contrary to the way the LGPL works for C, or C++, well, cool, be my guest.

    Let me profit from your bad legal advice. Please have your proprietary Java software making company pay me 1 million US dollars and I won't go looking at the source code of LGPLd libraries included in the JRE, to see if I can sue your company for what according to *your* lawyers is copyright infringement. Copyright infringement for commercial gain in the US can lead to spending some time in jail, too. Fun.

    While I, Sun Microsystems and FSF (and anyone else who publishes or uses software under the LGPL, afaik) would obviously disagree with such a broad interpretation of the LGPL, hey, wtf, why should your lawyers be distracted by reason.

    If your company's lawyers think that using LGPL'd software in proprietary Java applications results in infringing of the LGPL, that's great news: They are using LGPL code right now to build proprietary software by using the JRE & the JDK.

    Here is how your company can deal with it:

    a) stop using Java to write proprietary software (yay!), or
    b) publish all your software under the LGPL (yay!), or
    c) pay me a million dollars because your lawyers don't understand the LGPL works (triple yay!), or
    d) get yourself some lawyers that don't suck.

    If your lawyers want to make your company pay me a million bucks for no good reason, great! I have a nice tower in Paris to sell to your company, too.

    cheers,
    dalibor topic

    p.s. LEGAL NOTICE: This is a cynical joke on trusting bad legal advice, and not a demand for anything. If you have a problem understanding that, please try to get out more.
  61. Why would you want to do that? Because your lawyers don't understand the LGPL.See, Sun's JRE and JDK both include LGPL licensed software. Read this:http://java.sun.com/j2se/1.5.0/J2SEv5.0.THIRDPARTYLICENSEREADME.R2.txt"%% The following software may be included in this product: Common Unix Printing System API Libraries (CUPS API library);

    :)

    Phew, all us Windows users are probably safe!

    Anyway, this isn't even referring to Java code - it's native code in the JVM. Just using the JVM can't infect your license - as I'm sure you're well aware :)

    This would just fall under the same arguments as the use of MySQL, etc above.
  62. Why would you want to do that? Because your lawyers don't understand the LGPL.See, Sun's JRE and JDK both include LGPL licensed software. Read this:http://java.sun.com/j2se/1.5.0/J2SEv5.0.THIRDPARTYLICENSEREADME.R2.txt"%% The following software may be included in this product: Common Unix Printing System API Libraries (CUPS API library);
    :) Phew, all us Windows users are probably safe!

    Depends on your lawyers interpretation of how 'viral' the LGPL really is :)

    After all, if the 'evil' LGPL infected the Unixy bits of J2SE, then the infection must have spread to the Windows bits as well. Every *bad* lawyer knows that LGPL and GPL are the same thing, and automatically convert all the sources that use other code licensed under the LGPL, into Free Software. It can not be stopped, so we are all doomed to write Free Software alone, forever. :)

    Or so the myth would go according to the bad lawyers. :)

    Anyway, this isn't even referring to Java code - it's native code in the JVM.

    I believe that people who are scared of the LGPL in general wrongly assume that (LGPL && Java).equals(GPL). Since most of that discussion is about libraries, let me try to refine my little construst:


    So ... what if by a wicked constellation of stars, Sun's javax.print implementation wrapped that LGPLd CUPS code? Then the JDK, (OMG!OMG!OMG!), provides access to LGPLd code using an OO language and allows other code to extend those classes wrapping the 'dangerous','viral' LGPLd code. And as Sun's own JDK code is in the *same* (OMG! OMFG! We are all soo doomed!) rt.jar as those 'contaminated classes', it's all one big 'LGPL contaminated' mess. Right ?:)

    In other words, I think I've figured out step 2) PROFIT! :)

    More seriously, though: either a company's lawyers understand that the LGPL works for Java just the same way as it does for other programming languages, and how everyone writing LGPLd code says that it works, or ... that company seriously needs better legal advice. As my little satirical scam attempt above tries to show, bad legal advice on software licenses can turn out to be expensive, if your lawyers don't understand the licenses.

    Just ask SCO about the GPL. :)


    cheers,
    dalibor topic
  63. Depends on your lawyers interpretation of how 'viral' the LGPL really is :)

    Actually, as far as I know with contracts in most sane legal systems, this depends on what the two parties involved agree on. The granter and the beneficiary are both in agreement over the given terms of a distribution license. The interpretation of some random lawyer is quite irrelevant if two parties have a binding contract - the interpretation they have is important.

    I think there is way too much layman guessing in typical developer discussions about licenses and I'm also very sure that some of the people saying "LGPL is not allowed in our company" would have problems citing the exact reasons their legal department gave them. If you have some, bring them to public attention so they can be resolved by legal experts (in a given system) outside of a developer forum. Don't spread FUD.
  64. Actually, as far as I know with contracts in most sane legal systems, this depends on what the two parties involved agree on.

    Open source licensing 101, Christian: the (L)GPL is not a contract. This makes you, as some random poster, quite irrelevant to the discussion at hand :-)

    As a not-so-random employee of JBoss Inc. I find it appalling. Do any developers who work for JBoss actually know anything about the license that covers their work?
    I think there is way too much layman guessing in typical developer discussions about licenses and I'm also very sure that some of the people saying "LGPL is not allowed in our company" would have problems citing the exact reasons their legal department gave them. If you have some, bring them to public attention so they can be resolved by legal experts (in a given system) outside of a developer forum. Don't spread FUD.

    They've actually been cited right here. The primary problem is the definition of "derivative work". A secondary problem is what "distribute" means. Yes, I know it sounds like arguing what "is" means, but it's different. The LGPL wording very vague on what distribution means and what derivative work means, and that makes lawyers (especially corportate ones) nervous.

    This doesn't mean that a majority of corporations will automatically ban GPL or LPGL software. It does mean that a small number will outright ban it. And a larger number will draw very careful boundaries on use of such software. In particular, if their business really relies critically on some in-house developed software they _may_ be very leery of incorporating some (L)GPL code into said custom software.
  65. Open source licensing 101, Christian: the (L)GPL is not a contract. This makes you, as some random poster, quite irrelevant to the discussion at hand :-)

    No, but the agreement between two parties to grant and accept a license is certainly a contract. At least that's what my few years of legal education tell me.
  66. Actually, as far as I know with contracts in most sane legal systems, this depends on what the two parties involved agree on.
    Open source licensing 101, Christian: the (L)GPL is not a contract. This makes you, as some random poster, quite irrelevant to the discussion at hand :-)As a not-so-random employee of JBoss Inc. I find it appalling. Do any developers who work for JBoss actually know anything about the license that covers their work?
    I think there is way too much layman guessing in typical developer discussions about licenses and I'm also very sure that some of the people saying "LGPL is not allowed in our company" would have problems citing the exact reasons their legal department gave them. If you have some, bring them to public attention so they can be resolved by legal experts (in a given system) outside of a developer forum. Don't spread FUD.
    They've actually been cited right here. The primary problem is the definition of "derivative work". A secondary problem is what "distribute" means. Yes, I know it sounds like arguing what "is" means, but it's different. The LGPL wording very vague on what distribution means and what derivative work means, and that makes lawyers (especially corportate ones) nervous. This doesn't mean that a majority of corporations will automatically ban GPL or LPGL software. It does mean that a small number will outright ban it. And a larger number will draw very careful boundaries on use of such software. In particular, if their business really relies critically on some in-house developed software they _may_ be very leery of incorporating some (L)GPL code into said custom software.

    Mike, you've come on here before saying this same stuff and it's still wrong. What "distribute" and "derivative work" mean is well defined in the legal world. There are tests you can do to decide if something is a derivative work or not. There is no need to define these terms because they already have a definition. If you don't know or don't understand that definition you can feel free to ask a lawyer to help you out. If you don't have access to a lawyer then you're stupid for using, deriving from or incorporating any third party software into your own.
  67. Mike, you've come on here before saying this same stuff and it's still wrong. What "distribute" and "derivative work" mean is well defined in the legal world. There are tests you can do to decide if something is a derivative work or not. There is no need to define these terms because they already have a definition. If you don't know or don't understand that definition you can feel free to ask a lawyer to help you out. If you don't have access to a lawyer then you're stupid for using, deriving from or incorporating any third party software into your own.

    Sorry Chris, but you're just plain wrong.

    Quick - at a high level, what is the primary difference between the GPL and LGPL?

    Answer: the difference is in what is considered a derivative work. The GPL has one view and the LGPL a narrower view.

    In other words, those licenses are not relying on established copyright definitions of what "derivative work" is. In fact, and in particular, the LGPL tries to define what derivative means on its own.

    This is why many people hate the LGPL - because it does a vague and crappy job of trying to define "library" and "linking". And because, along with the GPL, it does an equally crappy job of defining distribution.
  68. Because each and every copyleft license is more restrictive than the Apache license: a copyleft license requires that the freedoms on the copyleft code remain intact, are passed on to recepients and that the source code for the copyleft work is made available, in one way or another.
    As far as I can see from the Apache legal-discuss mailing list, the Apache Software foundation's board may, eventually come to the decision to *tolerate* copyleft dependencies in some of apache code, under specific, still to be penned down, license-specific circumstances.
    That's a long shot from blessing a license.
    The ASF won't 'bless' or 'accept' other licenses beside the ASL2.0 any more than the FSF will recommend use of other licenses beside the GPL. Both organisations have a policy of not distributing software with licenses that are more restrictive than their own, afaik.
    cheers,
    dalibor topic
  69. I think you're wrong. I don't think its the copyleftness that is a problem. The MPL is already approved.

    Some links you might be interested in:
    http://wiki.apache.org/jakarta/LicenceIssues
    Re: CCDL versus ASF
    RE: Apache's LGPL Policy
    Re: Apache's LGPL Policy

    Also, please don't rant about particular parts of these emails until you've read the entire thread from the archive.
  70. Thanks for the links! I've been following the legal-discuss list through archives, and it's been a pretty interesting one. The legal-discuss list apparently benefits a lot in signal-to-noise ratio from excluding the general public's rants :)

    My outsider (not a member of either ASF or FSF) impression has been that the MPL has so far only been approved for executables, alone, under specific circumstances, rather then the ASF saying 'oh, yeah, MPL & copyleft are cool, let's merge in MPL licensed source code into our subversion repos and hack away on it!' ...

    That's what I meant by 'tolerate dependencies' vs. approving a license. I am sorry if I was not being really clear, there.

    My outsider impression is that the ASF may eventually decide to, on a case by case basis, tolerate (but not encourage) weak dependencies on copyleft code if there is a very good reason for it, and the license does not impose a too heavy burdens on ASF's respective project's downstream. In the MPL case it was Rhino, I believe. In the CDDL case it may be Glassfish. In the LGPL case, that may be Hibernate.

    It appears to me to be reasonably simple to fullfill the obligation on source code distribution for copyleft code in Java in general ... one just needs to put the respective source code tarball right into the distributed artifact. While that would be a pain to do in C++ dynamic shared objects, it's trivial enough for Java JAR archives, afaict. Then actively not complying with the copyleft takes more work in subsequent downstreams, then simply passing on the resulting artifact on redistribution unmodified, and complying with the copyleft license.

    But then, I don't work for IBM or BEA, so I have really no idea how that would work for them. That's part of why it's interesting for me to see that dicussion on legal-discuss, as their problems with licenses are different from, say, Debian's.

    all the best,
    dalibor topic
  71. Dual license[ Go to top ]

    Thanks a lot for all the very interesting replies. I'm starting to think that dual licensing is a good option, like that people that problems with LGPL can use CDDL and GPL projects can use the LGPL license.
  72. JBoss Open Source Licensing[ Go to top ]

    We have put out quite a few communications on the JBoss view and strategy on open soruce licenses. You can see a number of documents here - http://www.jboss.com/opensource/index.

    There are answers to most all of the questions I saw as I scanned this thread. The one question asked is whether the LGPL limits our business. The answer is clearly no. There is that some ISV/OEM's have concerns and questions which can cause delays in receiving an order. I can state that we have gotten over this issue in every case that I have been involved in. I can also state that there are now over several hundred software companies that embed JBoss. I can also state that I know of at least 8 multi-billion dollar Telecommunication Equipment manufacturers that embed JBoss in their products.

    Bob Bickel
    JBoss
  73. There are answers to most all of the questions I saw as I scanned this thread. The one question asked is whether the LGPL limits our business. The answer is clearly no.

    Give people credit for having brains, Bob. You are stuck with the LGPL, you have no choice at this point in time but to use it. So what are you going to say? The honest truth would be to say "Yes, some people don't use JBoss because it's LGPL". Instead you give everyone the JBoss shuffle.

    Why don't you guys try out honesty for a change instead of endless spin?
  74. Why don't you guys try out honesty for a change instead of endless spin?

    Please do not question my honesty.

    I wrote the FAQ, and it is how I feel. We have also proven that we like the LGPL with our newer projects like JBoss Portal 2.0 (except the parts that are covered because they were based on GPL code), and JBoss jBPM. We had our choice, and chose LGPL for the reasons we have stated many times.

    One other note, we are open to other licenses as can be seen by our use and participation across a variety of open source projects including Apache and Eclipse. We do agree with Martin Fink's opinion expressed at LinuxWorld that there are too many open source licenses. And we are supporters of finding ways to make sure the licenses interoperate.

    Thanks,
    Bob Bickel
    JBoss
  75. Bob :
    We have also proven that we like the LGPL with our newer projects like JBoss Portal 2.0 (except the parts that are covered because they were based on GPL code), and JBoss jBPM.

    I'm honestly curious - how do you combine GPL-ed code and LGPL-ed code and distribute under anything but GPL?

    geir
  76. How about a poll[ Go to top ]

    I think TheServerSide or Javalobby should make a poll which of the weak copyleft licenses is preferred. This will be of help to projects deciding on a copyleft license.

    My personal oppinion is that all projects that can use CDDL should use it just because it creates less problems than LGPL. It doesn't matter whether LGPL is interpreted right or wrong it is already a problem that you have to interpret it.
  77. I cannot fathom for the life of me why anyone would fail to understand why some companies have issues with the LGPL. Just reading http://www.fsf.org/licensing/licenses/lgpl-java.html points out what the issue is.

    The issue is not that the LGPL is "viral" in the sense of the GPL. It is "If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications."


    This is not a problem for JBoss or Linux as the products using these are generally using interfaces that are free of any of these licensing restrictions. However, use of a library creates many headaches for companies that don't want to allow their customers to hack their code.

    If Hibernate, or other LGPL'd projects, delivered their publicly callable interfaces under an Apache compatible license then, at least in my view, it would be much less of an issue in using it in Apache projects since the restriction noted above would no longer apply.

    However IMO, claiming that the LGPL shouldn't be a problem for anyone and that Apache is over-reacting is just pretending you're an ostrich.

    And finally, the claim that IBM and other companies are just incorporating Apache code into their products and are not giving anything is just simply not true. Frankly, that wouldn't be very cost effective as they'd have to maintain their own fork of the code.
  78. Really. And there is almost nothing a company can do about it in real life.

    See http://www.chillingeffects.org/reverse/faq.cgi#QID195 for the current status of reverse engeneering in the USA.

    Reverse engineering software has been confirmed in case law in the USA. See http://digital-law-online.info/lpdi1.0/treatise25.html
    for an overview of Federal Circuit's and Ninth Circuit's decisions upholding the right to reverse engineer software despite much crying by poor companies.

    Quting from the federal court's decision:

    "The author does not acquire exclusive rights to a literary work in its entirety. Under the Act, society is free to exploit facts, ideas, processes, or methods of operation in a copyrighted work. To protect processes or methods of operation, a creator must look to patent laws. An author cannot acquire patent-like protection by putting an idea, process, or method of operation in an unintelligible format and asserting copyright infringement against those who try to understand that idea, process, or method of operation."

    Sarcastically put, anti-reverse-engineering clauses are lawyerish wet dreams cast into legalese for hope that they might be believed by those that accept the license.

    The LGPL can not magically take away rights you don't have in the first place. You can not prohibit reverse engineering in a software license, any more than you can claim the head of the firstborn son of your customers. It may sound like a fun and useful thing to have in a proprietary software license, but it won't survive in court, as the precedence cases cited above show.

    And before you go start thinking about the DMCA, please note the DMCA explicitely allows reverse engineering for the purpose of interoperabilty, which is precisely what the LGPL demands and that section is designed for: *allowing* the interoperability with other versions of the LGPL covered library. See 17 USC §1201 (f) for details.

    And get yourself a better lawyer, if you can. ;)

    cheers,
    dalibor topic
  79. Which is why non-lawyers end up having this sort of funny little handwaving contests.

    It's briliantly similar to Amiga vs Atari, or vi vs. Emacs or similarly childish urinathons.

    I am sure any lawyer watching non-lawyers banter about law is cringing inside similarly to how I'd go if lawyers started explaining garbage collection algorithms to me ...

    Sigh. Most software licenses are suboptimal, for various reasons. There are always scenarios where any license that's more complex than the two clause BSD license will prove to be extremely limiting. Patent retaliation, unclear derivative work definitions, forced choice of venue, etc. all those can be, and have been blockers to adoption of a source code base in the past.

    For example, OpenBSD has forked the Apache Web Server, since they consider the ASL 2 to be too restrictive. Was their decision based on hard legal facts? Hardly. But it's Theo's project, and it's Theo's policy.

    The FSF regards the ASL2 as GPL2-incompatible, because of a nice, complicated chain of reaction that takes several steps under the assumption of someone having patents to figure out, and where the ASL2 turns out to be more limiting than the GPL, in that particular scenario. Does that mean the ASL2 is more restrictive than the GPL2? Hardly. In practice, most ASL2 licensed code is not explicitely covered by patents, so there is nothing for the ASF to legally retaliate with. But it is FSF's policy that a license is only then GPL2-compatible when in all situations is does not impose even stricter restrictions than the GPL2 does. So most (if not all) patent retaliation clauses in other open source licenses make then GPL2 incompatible. Even if the authors have no patents on the code in question. That's pretty frustrating.

    The ASF regards many copyleft licenses as being more restrictive than the ASL2. In practice, those restrictions can be easily enough fulfilled in the Java case by stuffing the source code along with the artifacts, not shipping the artifacts, or using tools like Maven. Remember: shipping the work that merely uses the library in isolation, only triggers section 5 of the LGPL, and not section 6 (the one with source code shipping requirements, and limiting reverse engineering). See http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200508.mbox/%3c96D75844-B15A-45E3-BF8D-5CF4517A09E2 at apache dot org%3e for details of the legalese. But as a policy, the ASF appears *in general* to prefer not to distribute artifacts with more restrictive licenses than ASL2, and that's unlikely to change *in general*.

    Debian considers the (OSI-certified as open source) MPL license family to be non-free, because it violates the Debian Free Software Guidelines (the basis of OSI's open source definition, btw) and additional "sanity" tests from Debian legal. See http://lists.debian.org/debian-legal/2004/06/msg00221.html for details.

    There is nothing wrong with any of these cases: ASL2, LGPL 2.1, MPL and GPL2 are all pretty complex software licenses. Because they are so complex, they are pretty hard to understand for your average normal non-native-speaker non-lawyer, and they have implications that their designers could not have carefully considered at the time of their writing. Therefore, organisations will usually act as conservatively as they have to in order to protect the interests of their members & contributors and promote their goals.

    Deal with it. No license is good enough for all possible purposes, in all possible jurisdictions, for all groups of people. If a license is written by top notch lawyers in lawyerese, chances are normal developers won't understand it. If a license is written by developers, chances are it will be pretty bad in legal terms.

    And now, please continue the annual, poor TSS imitation of a debian-legal licensing flame fest. You TSS folks should have seen the hot-babe flamewars on debian-* to see a really good heated exchange of opinions.

    cheers,
    dalibor topic
  80. Thanks for the very interesting and thought provoking post. I only have one minor quibble.
    In practice, those restrictions can be easily enough fulfilled in the Java case by stuffing the source code along with the artifacts, not shipping the artifacts, or using tools like Maven. Remember: shipping the work that merely uses the library in isolation, only triggers section 5 of the LGPL, and not section 6 (the one with source code shipping requirements, and limiting reverse engineering).

    This is actually not so easy to do. If the java has an import statement for the LGPLd library the LGPL considers it a derivative work (see http://www.gnu.org/licenses/lgpl-java.html which says "Applications use Java's "import" functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is a then generally a derivative work of the library." Dynamically linking to the library won't cut it either, "It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code." I believe the interpretation you are using may be JBoss' which states "Merely linking to a library does not create a derivative work,", which is exactly the opposite of what the FSF says about its own license.

    Now if you're a paying customer of the JBoss products I guess this is OK as they will accept the risks of any lawsuits that (however unlikely) occur.
  81. Unfortunately, the quotes you made are about the _GPL_, not the LGPL, and hence you just contribute to the general FUD spreading.
  82. Hey I don't know License stuuf; I have a Question Though.

    Can I use any of the Open Source products out there (Ex Jfreechart Jboss etc. ) and make a new XJFreeChart or XJboss just by adding a new class in my package and using JBoss or Jfreechart. After doin this can I sell my version of XJFreechart as a super graphics Library and XJboss as a super App Server and I will also provide Technical support.
    Will this work.
    ??
    TIA
    Moin
  83. Unfortunately, the quotes you made are about the _GPL_, not the LGPL, and hence you just contribute to the general FUD spreading.

    You are incorrect. The whole page refers to the LGPL except for the second and third sentences. Those two sentences simply explains how the GPL treats a derivative work. The rest of the page is explicitly applicable to the LGPL.

    1. "It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code."

    This would be a pretty strance statement to make to only apply to the GPL. My reading is that this is the FSF's position on any of their licenses.

    2. "Applications use Java's "import" functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is a then generally a derivative work of the library."

    The quote continues on with "So, the copyright holder for the library must authorize distribution of the work. The LGPL permits this distribution." Clearly the quote applies to the LGPL.

    Did you even read the page?
  84. Oh yes, I know the page. And to avoid you quoting some more stuff out of context, here is the full paragraph you keep picking things out that fit your world view:

    "It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as "hereditary." So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL. By contrast, libraries licensed under the GNU Lesser General Public License (LGPL) may be linked to proprietary applications."

    Note the last sentence.
  85. Oh yes, I know the page. And to avoid you quoting some more stuff out of context, here is the full paragraph you keep picking things out that fit your world view:"It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as "hereditary." So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL. By contrast, libraries licensed under the GNU Lesser General Public License (LGPL) may be linked to proprietary applications."Note the last sentence.

    So what? "By contrast" applies to the prior sentence.
    This simply means that the LGPL is not "viral" as the GPL is. It means that the "derivative work" does not have to also be licensed under the LGPL. It doesn't mean it is not a derivative work or that it doesn't have to adhere to the conditions of the LGPL.

    It seems like you simply want this to read in a way that makes the LGPL provide the freedom you want. Frankly, I'd like to read it that way to. And that is the problem. If you follow all the discussions on the LGPL that have been on Slashdot or other forums over the years you will find plenty of people who cannot agree on what it says.
  86. LGPL & You[ Go to top ]

    Thanks for the very interesting and thought provoking post.

    Thanks! I hope this one will be somewhat helpful.
    I only have one minor quibble.
    In practice, those restrictions can be easily enough fulfilled in the Java case by stuffing the source code along with the artifacts, not shipping the artifacts, or using tools like Maven. Remember: shipping the work that merely uses the library in isolation, only triggers section 5 of the LGPL, and not section 6 (the one with source code shipping requirements, and limiting reverse engineering).
    This is actually not so easy to do. If the java has an import statement for the LGPLd library the LGPL considers it a derivative work (see http://www.gnu.org/licenses/lgpl-java.html which says "Applications use Java's "import" functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is a then generally a derivative work of the library." Dynamically linking to the library won't cut it either, "It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code." I believe the interpretation you are using may be JBoss' which states "Merely linking to a library does not create a derivative work,", which is exactly the opposite of what the FSF says about its own license.

    Ok. Let me preface this with a little story:

    Back in the day, the ASF and the FSF went into a bit of interesting miscommunication about their respective licenses. A lot of fun was had by bloggers, the slashdot crowd and so on. Those were the days!

    Alas, since I'm one of those ambitious people writing their own J2SE implementation from scratch, I got a bit frustrated about ASF and FSF not being able to figure out that they are both similar and different at the same time, and that there nevertheless exist very bright people on both sides of the fence. I helped along to get people from both ASF and FSF pick up the phones and start talking again about their licenses. We ended up having a set of discussions that has largely worked to help a) figure out that yes, there was a prior massive problem with miscommunication, b) how the special chain of events can cause the ASL2 patent-retaliation to become a problem, and c) how the LGPL works in specific cases of interest to the ASF.

    Cliff Schmidt, the legal VP of ASF did some excellent work on c) in conjuction with David Turner from the FSF. I have met both in person, and I think they both know what they are doing.

    Now, I hope that all I have to say regarding the upcoming decision of the ASF board on a policy regarding the LGPL is this:

    If members of the ASF board do not feel that they understand well enough how the LGPL works, for example wrt to the way it treats derivative works, then the ASF board should, as during the discussion before, have Cliff ask David a concrete question about it, and then the ASF can make the decision with a better understanding of the license in question. The "let's ask the FSF" process *works*, and it works better than the alternative, as has been already shown with the progress made in a) & b), and the FSF has made clear that they want to help ASF understand the LGPL. Please use the offered resources, and please help us all avoid the miscommunication mistakes of the past.

    Thank you.

    Now, instead of giving you some misdirected rants about LGPL and trying to play the 'let's pretend we all know copyright law by heart' game, I'll tell you the story of a company that blew millions of dollars on bad legal advice, and why that was not really the fault of the lawyers. I'll tell you the story of SCO, of course.

    Back in the day, SCO apparently thought that what they had at their hands and some source code in Linux were the same thing, so they just had to show up in the court and collect royalties till the end of days. You can read it in some of their filings, and one could see it in a famous presentation that showed the same code, down to the comments in SCO's proprietary Unix and the Linux kernel. They believed they had a slam dunk case.

    Now, if you show two almost identical lengthy pieces of code to a lawyer, he'll probably tell you that you have a case of a derivative work, and a possible copyright infringement on your hands. If you tell the lawyer that you own your copyrights, and you didn't give the other guy a license, then it's clear as a summer sky that the other guy is infringing on your copyrights, and you need to make sure he pays up for that.

    That was SCO's plan. In essence, a simple, and not too stupid plan. As SCO's Chris Sonntag said in Computerworld:

    "It's very extensive. It is many different sections of code ranging from five to 10 to 15 lines of code in multiple places that are of issue, up to large blocks of code that have been inappropriately copied into Linux in violation of our source-code licensing contract. That's in the kernel itself, so it is significant. It is not a line or two here or there. It was quite a surprise for us."

    They were in for a much larger suprise.

    Unfortunately for SCO, their lawyers a) did not know almost anything about Unix, C or the history of it all, b) SCO assumed that they had the copyrights, when in fact someone else had them, c) all the matching or similar code they found later showed to either not pass the filtration abstraction comparison test (see DigitalLaw site I referenced before and the declaration of one (or the, if you TSS folks know who he is ;) Brian W Kernighan on behalf od IBM via http://www.groklaw.net/article.php?story=20050627213616674 ), or to be from the same upstream or to implement same APIs (see http://www.perens.com/SCO/SCOSlideShow.html ), and d) the SCO execs were too stupid to stop after they realized it's all going to tank big time.

    In other words, SCO's execs had no real clue about copyright law, or how it applies to computer programs, and when they received an analysis showing similar code in Linux and their code base, and when they fed their lawyers garbage in, well, garbage out is what they got.

    Based on that (OK in general, but totally off base in the relevamt context) legal analysis, SCO proceeded to spend quite a few millions of dollars, and essentially become the first company to commit slow public suicide due to not understanding the GPL, the AT&T vs BSDi lawsuit, and their own contracts with Novell. You can watch them die slowly on groklaw.net, where you can also casually pick up knowledge of copyright law, GPL, and all that. Highly recommendable on lazy Sundays, IBM lawyers on the case have some really nice writing skills.

    There is a major lesson to learn from SCO's agony: don't expect your lawyers to magically know everything about everything. Lawyers are not little oracles of truth, they are only as good as the facts they have access to, and they, too, can make mistakes.

    And, as the SCO vs. IBM and Novell vs. SCO cases show, if you want to know what people mean with their licenses, it may make more sense to just ask them. When SCO made funny claims based on their assumptions regarding the AT&T derived works clause in the AT&T licensing contracts, IBM had the AT&T head of licensing at the time, Otis Willson testifying on their side and debunking SCO's claims. Reasoning based on half-baked assumptions how licensing works can cost you a few millions of dollars, so don't do it. ;)

    See http://en.wikipedia.org/wiki/SCO_v._IBM_Linux_lawsuit for an overview, of how embarassing it all got today for SCO.

    So, to sum it up: legalese is tricky. Not understanding copyright law in detail makes it even trickier for most of us. Not having written compilers themselves makes it pretty hard for lawyers to fight their way through technobabble. And if you really want (or need) to understand what a license means, just ask the author.

    So much for the general attempts at thought provoking story telling. I'll close by reframing your question a bit, if you don't mind:

    Your question is a good one, and the one about which the LGPL explicitely says

    "Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run."

    If the distinction was as unclear as you seem to believe, I don't think you'd see Sun (and presumably IBM, BEA and Apple and anyone else who licensed J2SE) shipping *proprietary, closed source* code in the JDK and JRE using the LGPL licensed library, as I explained before. While the LGPL goes into detail to explain how it all works with C, the rationale exposed in the underlying examples (headers, and all that, static & dyamic linking) is based on copyright law, scenes a faire, copyrightability, and case law. The DigitalLaw site has references for all (without going into the GPL or LGPL, but if you know what you are looking for Sega vs. Accolade and the other explained cases should provide some appetizers) that that I don't feel like parrotting here, read it all and you'll have a much better understanding how copyright works wrt to computer programs.

    So, to close on a more humorous note, when you see Sun, IBM, BEA, Apple and others release their VMs and the whole J2SE shebang under the LGPL because their lawyers think there is something unclear about the difference between a "work based on the library" and a "work that uses the library", give me a call. I'm always looking for some ice GPL-compatible code to merge in ;)

    cheers,
    dalibor topic
  87. Copyrightabilty and Interfaces[ Go to top ]

    There has been numerous case law by now on this topic, and in general it very much favours the notion that interfaces are *not* copyrightable.

    For a history of the topic, you may want to check out "Interfaces on Trial", and wade through it. Judging by the reviews like http://www.unt.edu/lpbr/subpages/reviews/band.htm it's a fun, no-nosense book about the law in this area. See also the various cases cited in the review in the DigitalLaw site for a bit of background on the cited court decisions.

    Note that neither the FSF nor any other serious organisation claims that interfaces are copyrightable. While SCO made some claims that they essentially own the POSIX interfaces, they also decided that law is not on their side, and there are bigger straws to try to catch.

    cheers,
    dalibor topic
  88. GPL[ Go to top ]

    GPL is the best, in my opinion, in terms of developer protection and long term life of an OSS project. The majority of OSS projects are licensed under GPL, if I remember the statistics correctly.

    You need to be careful though when you set up your project, so the copyright is properly assigned by your contributors, etc., so later you could license your code under a different license (and for a fair fee), if necessary, if there is someone who wants to distribute your software AND does not want to contribute back the changes.

    --
    Igor Zavialov
    Factoreal Financial Data and Technical Analysis solutions.
  89. Open Software License (OSL)[ Go to top ]

    I think the best reciprocal (a.k.a. copyleft) license is Open Software License (OSL) version 2.1 written by Lawrence Rosen, who are the general counsel and secretary of the Open Source Initiative (OSI). The second best, IMHO, is GPL or CPL.

    If you want to limit the reciprocity to the library itself, i.e. similar to LGPL, you can still use OSL or GPL with an exception similar to what is described at http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface.

    For a detailed discussion about LGPL, GPL, MPL, CPL, OSL and other licenses I highly recommend Rosen's book Open Source Licensing - Software Freedom and Intellectual Property Law which is available free on-line at http://www.rosenlaw.com/oslbook.htm.
  90. This has been fun, but....[ Go to top ]

    I'm considering moving to another license which offers the same kind of developer protection but is not shunned for commercial usage. ...Are other licenses with the same developer protection worth considering?

    I would like to go back to the original question and offer a solution not yet proposed on this thread.

    If you're looking for a license which (a) has broad usage within the Java community, (b) protects the contribution of the developer and (c) is embraced for commercial usage, could I humbly suggest that the Eclipse Public License (EPL) meets all of those constraints?

    The EPL is a commercial-friendly, symmetrical copyleft license which has been embraced by many commercial vendors, including most of the key players in the Java space (IBM, BEA, Borland, Oracle, ....).
  91. This has been fun, but....[ Go to top ]

    I'm considering moving to another license which offers the same kind of developer protection but is not shunned for commercial usage. ...Are other licenses with the same developer protection worth considering?
    I would like to go back to the original question and offer a solution not yet proposed on this thread.If you're looking for a license which (a) has broad usage within the Java community, (b) protects the contribution of the developer and (c) is embraced for commercial usage, could I humbly suggest that the Eclipse Public License (EPL) meets all of those constraints?The EPL is a commercial-friendly, symmetrical copyleft license which has been embraced by many commercial vendors, including most of the key players in the Java space (IBM, BEA, Borland, Oracle, ....).

    The EPL is not GPL-compatible, unfortunately.

    It comes with a significant penalty for businesses trying to make money by combining EPL licensed code with GPL licensed code for their customers. See all the extra effort Red Hat had to put into separating GPLd from EPLd code at an arms length to make their OProfile Eclipse plugin distributable.

    That puts it in the same bin as CDDL, MPL, SISSL, SPL, IPL, OSL, NPL, ASPL, CPL and friends: it has some domain-specific legal ideas, that matter to its creators, but they make one lose GPL-compatibility, and make the codelicensed under them harder to reuse in various scenarios.

    If an author has nothing to do with the legal domains the license experiments with (these days it usually is software patent retaliation), and is not a business associate of the creator of the license, such a license not of much use over the established alternative.

    The LGPL has been embraced by almost everyone writing proprietary software, including big bad Microsoft (see SFU), Oracle, BEA, IBM, Sun, Apple, and, unsurprisingly, the Eclipse Consortium (see Eclipse, which uses LGPLd libraries, and is used as a foundation for proprietary software solutions).

    It's really hard for a new weak copyleft license to compete for mindshare with the LGPL, in particular if the new license comes with the penalty of not being GPL-compatible. That is a significant barrier to widespread adoption outside the license steward's sphere of influence, although people usually don't realize that in the beginning. See Mozilla, Trolltech & others.

    See the OSI for a wide selection of company-specific GPL-incompatble weak copyleft licenses that have not managed to 'succeed wildly' beyound their creator's immediate sphere of influence for a lot of good reasons.

    cheers,
    dalibor topic
  92. This has been fun, but....[ Go to top ]

    The EPL is not GPL-compatible, unfortunately.

    Hmm, license A is not GPL-compatible, license B is not GPL-compatible, ... license Z is not GPL-compatible, therefore there must be something wrong with licenses A-Z!
    It comes with a significant penalty for businesses trying to make money by combining EPL licensed code with GPL licensed code for their customers.

    I agree, but the same could be said about almost any license except GPL. Why does GPL have to be so narrow minded? If freedom is so important, how about the developer's freedom to mix and match code from various places, respect the licenses of that code, and not have those licenses dictate the licenses of the other code that can be used with it?

    EPL, CPL, and MPL are very good licenses you should consider. They allow mixing code from other licenses (as long as the other license allows it too), they require bug fixes and enhancements to be given back, and they can be used inside open- or closed-source programs whether the the software is free-of-charge or not.
  93. This has been fun, but....[ Go to top ]

    The EPL is not GPL-compatible, unfortunately.
    Hmm, license A is not GPL-compatible, license B is not GPL-compatible, ... license Z is not GPL-compatible, therefore there must be something wrong with licenses A-Z!

    Well, yes, if they are more restrictive than the GPL, then they are GPL-incompatible. The GPL does not allow further restrictions to be imposed. It's already a very restrictive software license, to put it mildly, so to stop people piling further restrictions on top of a very restrictive license, it prohibts adding further restrictions.

    In practice that means, that patent-retaliation clauses, like EPL's, are often worded in such a way that they add additional burdens on the recepients on top of those already existing in the GPL.
    It comes with a significant penalty for businesses trying to make money by combining EPL licensed code with GPL licensed code for their customers.
    I agree, but the same could be said about almost any license except GPL.

    Nah, not really. In practice, many open source licenses are nicely mixable with the GPL. See the license list at the FSF web site.

    And in practice, the incompatibility usually comes from side-effects with the wording of respective clauses in the incompatible licenses, rather than as explicit wish of a license steward to have their license be GPL-incompatible. So it is, in practice, usually fixed when it becomes a real problem. See Mozilla, Trolltech, BSD-Advertising clause, and other examples.
     Why does GPL have to be so narrow minded?

    I guess the authors believed that the GPL was restrictive enough, and further restrictions would only make it harder for users and developers to use, modify and distribute the software freely.
    If freedom is so important, how about the developer's freedom to mix and match code from various places, respect the licenses of that code, and not have those licenses dictate the licenses of the other code that can be used with it?

    We're in violent agreement there, really.

    I've grown to be a fan of the MIT/Expat license. The MIT license in particular, since I have not heard anyone ever bitch about the MIT license (and I heard heaps of licensing debates involving all the others), so licensing code under the MIT license sounds like a great way to not spend your time handwaying with other non-lawyers, if you *don't* want copyleft.

    I've yet to hear about an organisation not liking that license.

    cheers,
    dalibor topic
  94. "Compatible" means "fork"[ Go to top ]

    <bockquote>Nah, not really. In practice, many open source licenses are nicely mixable with the GPL. See the license list at the FSF web site.

    And in practice, the incompatibility usually comes from side-effects with the wording of respective clauses in the incompatible licenses, rather than as explicit wish of a license steward to have their license be GPL-incompatible. So it is, in practice, usually fixed when it becomes a real problem. See Mozilla, Trolltech, BSD-Advertising clause, and other examples.
    You're a smart guy, Dalibor, and you make that all sound so cuddly. But the spin-talk is getting out of control here. The phrase "GPL Compatible" is a nice spin but it hides the real, deep, philosophical incompatibility between the GPL and pretty much all other software licenses.

    Most licenses are <em>file based</em>. That means the licensing terms apply to the file containing the source code being licensed. This is very handy as it means, as long as there are no other license clauses causing a problem, that I can assemble a project using files drawn from all sorts of different places. Some of those file-based licenses are also <em>copyleft</em>, meaning they require changes just to that file to be re-licensed under the original license, but that does not need to affect the overall project.

    The GPL is not file-based. It is a <em>project-based</em> license. That means its terms extend to the project you end up building not just the file you are using. The GPL insists that <em>all</em> files that go to make up that project are licensed under the GPL. It won't tolerate any other license.

    The term "GPL Compatible" thus does not reflect some minor nicety of license choice by the license author. It means that the originator of a file of source code, licensed under some license under other than the GPL, must be willing for the code to be <em>relicensed</em> under the GPL, for the original license to be discarded, for all changes made to the file to be licensed in a way that makes it impossible for them to be merged back into the original code. It means the guaranteed forking of the code way from its original commons.

    We might perhaps debate the pros and cons of the social intent behind this, but please, let's not pretend that being "GPL Compatible" is just a matter of twiddling a few lines of a license. It's not.
  95. This has been fun, but....[ Go to top ]

    The original poster did not ask for a GPL-compatible license. They asked for a good license. Which the EPL is. As are many other non-GPL-compatible licenses.

    I really do not want to start the inevitable licensing debate, but saying that a license is not good because it's not GPL compatible is kinda like saying you're not a good American if you don't vote Republican. (E.g. If you're not part of the majority, there's something wrong with you.) I thought monolithic thinking was something we open source folks were supposed to avoid.

    [Disclosure: I am not American, nor do I live in the U.S.]

    GPL is a great license that has spurred a large following. But it is not the right license for all situations.

    As a factual statement, it is incorrect to say that the Eclipse community makes general use of LGPL code. I am not sure where you came to that conclusion.
  96. This has been fun, but....[ Go to top ]

    The original poster did not ask for a GPL-compatible license. They asked for a good license. Which the EPL is.

    Sure. It's a free software license and meets the OSI definition, so it's certainly a fine software license.
    As are many other non-GPL-compatible licenses.I really do not want to start the inevitable licensing debate, but saying that a license is not good because it's not GPL compatible is kinda like saying you're not a good American if you don't vote Republican. (E.g. If you're not part of the majority, there's something wrong with you.)

    Given that there are many GPL-compatible licenses as well, I think it's pointless to try to use a majority argument either way. Note that all I am saying is simply that due to EPL not being GPL compatible, it means that a developer and/or company to spend resources working around that problem, when they try to combine EPL licensed works with GPL licensed works.

    The EPL is a license that the Eclipse Foundation has chosen according to its goals, and there is nothing wrong with that. Given that Eclipse Foundation's goals probably do not include development of GPLd applications for its clients, it's also OK for the Eclipse Foundation not to care about GPL-compatiblity in their license.

    For an independant third party developer, the situation is very different, though, as their goals are not necessarily the same as the goals of the Eclipse Foundation. If, say, a client of mine wanted to have SWT implemented on top of Qt4, the GPL-incompatibility of EPL could make the project much more expensive than necessary.

    Or, as IBM's problems with releasing OTI's SWT/Qt bindings show, the result may end up being almost impossible to distribute: According to the CVS logs at http://dev.eclipse.org/viewcvs/index.cgi/platform-swt-home/dev.html

    IBM has been working since Wed Sep 18 00:35:48 2002 UTC on "
     SWT for Qt/E will be included in the next release of the IBM WebSphere Micro Environment and WebSphere Customer Environment products. We are currently working on determining the feasibility of releasing SWT for Qt/E to the Eclipse project."

    Three years and nothing happened, afaict, and afaik IBM ended up giving up and just licensing Qtopia from Trolltech for their embedded product. So I think it is correct to say, that the lack of GPL-incompatiblity of EPL can, actually, be a problem in practice for a companies and can mean that the Eclipse Foundation does not get contributions it could get otherwise, like in the above case.

    You'll notice that the CVS directory http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt/Eclipse%20SWT/qt/ is woefully empty, and always has been empty. I'd be surprised if that ever changes, as long as the EPL is GPL-incompatible.
    I thought monolithic thinking was something we open source folks were supposed to avoid.

    Definitely.

    <blockqute>
    GPL is a great license that has spurred a large following. But it is not the right license for all situations.
    We are in violent agreement, there.
    As a factual statement, it is incorrect to say that the Eclipse community makes general use of LGPL code. I am not sure where you came to that conclusion.

    I am running Eclipse 3.1 right now. SWT, which as you know, is a core part of the RCP, which in turn is the core component of Eclipse, uses GTK+, which, funny enough, is licensed under the LGPL.

    Given that the core toolkit of the core project of the Eclipse community makes use of LGPLd code, I came to the conclusion that the Eclipse community, well, ... uses LGPLd code.

    Maybe I am wrong, of course, and it's not really using libgtk. Hmm.

    Let's see ...

    [topic@clerks projects]$ find ~/.eclipse/ -name "*.so" /home/topic/.eclipse/org.eclipse.platform_3.1.0/configuration/org.eclipse.osgi/bundles/59/1/.cp/os/linux/x86/libswt-pi-gtk-3128.so

    [topic@clerks projects]$ ldd /home/topic/.eclipse/org.eclipse.platform_3.1.0/configuration/org.eclipse.osgi/bundles/59/1/.cp/os/linux/x86/libswt-pi-gtk-3128.so | grep gtk
            libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00111000)

    No, seems like I am right. Eclipse Foundation's Eclipse 3.1 uses LGPLd libraries just fine for core tasks, like drawing of the GUI. I can't be bothered to look at the package dependencies right now to see which other LGPLd libraries it uses, too, but I am sure the Eclipse Foundation is fine with that.

    Let me throw the question back at you: What makes you think that the Eclipse community does not use LGPL code?

    I mean, if you take some time to use a search engine, you'll see that in general, there are quite a few LGPL licensed plugins for Eclipse. Unless neither the plugin community nor the Eclipse Foundation are part of the Eclipse community you had in mind, I think that's a strong indicator that, in general, the Eclipse community both uses and creates LGPLd code.

    cheers,
    dalibor topic
  97. How should we interpret this part of the CDDL distribution clause:

    "You distribute or otherwise make available"

    Suppose you are integrating the Glassfish application server, which is CDDL licensed, into your product.

    Suppose this product is used to process purchase orders online.

    The "You distribute or otherwise make available" language seems to indicate that every single person who wants this product to process their purchase order has to be made aware of their CDDL license rights.

    So if your Grandma logs in to the store using this product, she must be made aware. She can't just proceed to fill out the purchase order form and get a confirmation.

    In other words, the language seems to indicate that anyone interacting throught a browser with a CDDL executable or library, must be made aware of their CDDL license rights.

    I've tried to confirm this with Jim Driscoll and Simon Phipps, through their blogs and have not gotten any response, which seems to be a good indication that what I'm saying above is true.
  98. No Concern.[ Go to top ]

    There is no concern. The license is a source license. Providing a service with executing code is not "making the code available" and thus there is no issue. Really, this seems so obvious I wonder where your concern can possibly have arisen.
  99. Wow![ Go to top ]

    I hereby crown this, officially...

    The Stupidest TSS Thread Ever!

    Look at all the amateur lawyers go! ROFL.

    Seriously, I have never before in my life seen such a bunch of utterly untrue, absurd things posted by supposedly intelligent people. Took my breath away.
  100. I hereby crown this, officially...The Stupidest TSS Thread Ever!Look at all the amateur lawyers go! ROFL.Seriously, I have never before in my life seen such a bunch of utterly untrue, absurd things posted by supposedly intelligent people. Took my breath away.

    Thanks Gavin, for having the courage to step forward and to tell the truth. Many people have long suspected these things of JBoss employees like Adrian and Bill Burke, but without more evidence many people were on the fence. But thanks to your insider perspective, it's now confirmed that what Bill and Adrian post on TSS are "a bunch of utterly untrue, absurd things posted by supposedly intelligent people".
    Took my breath away.

    No Gavin, your honesty and integrity to criticize two members of your own company is the real hero here. It is you sir who have taken _our_ breath away! Keep on keepin' it real.
  101. Thanks for your integrity and courage, Gavin[ Go to top ]

    Spille u just wanting the fame but talent u having, .. too bad so sad, .. maybe you want play genital tug with ic24 and whatever new company owning the spring, this way you can having credibility, ... now please going away and playing with your self .. bye byes ...
  102. Thanks. I agree. Love to hear more... iPod Transfer