Page 6 of 8 FirstFirst ... 45678 LastLast
Results 51 to 60 of 77

Thread: wow... very impress

  1. #51
    Ext Premium Member
    Join Date
    Mar 2007
    Posts
    60
    Vote Rating
    0
      0  

    Default Since when did BSD/ASF become a bad word?

    Quote Originally Posted by JeffHowden
    Quote Originally Posted by frando
    [...]In the case of Ext, I think that a BSD license + support contracts would also work...
    Unfortunately, BSD isn't doable because it permits forking.
    I don't mind the LGPL license (I don't like forking unless the project isn't maintain), but I think it's important on how you go about making MONEY with it. Just saying you want commercial software to pay for it IS NOT LGPL. Period. stop trying to "bait and switch", come up with your own COMMERCIAL LICENSE, but don't give EXT a black eye by saying its LGPL and interperting it loosely or incorrectly.

    Take a look at JBOSS (a small company) uses the LGPL properly to make money. Jack, I really hope that you have some solid advice from people you trust before you pull the trigger one way or the other.

    Here are some of the most frequently asked questions that we receive at JBoss regarding licensing. If your question is not answered here, please contact us via email.
    Frequently Asked Questions

    What open source license does JBoss use?

    I'm an end-user, what does the LGPL mean to me?

    Could JBoss, Inc. ever create a closed source fork of JBoss?

    Why is JBoss so popular with Software Vendors?

    We want to bundle JBoss in our software application and distribute it. Can we do that under LGPL without any compromise of our commercial licenses?

    If we make changes to a JBoss LGPL product, what changes do we have to contribute back to the community?

    What open source license does JBoss use?

    Most of the JBoss projects, like the JBoss Application Server, Hibernate and JBoss Cache are licensed under the LGPL (GNU Lesser General Public License). This license assures users of a free, open source implementation of JBoss. It allows software, hardware and telecommunications vendors to bundle JBoss in their applications and systems without the reciprocal open source requirement. And it provides all JBoss users the assurance that enhancements to the JBoss source code will continue to remain free and openly available. See the Licensing page for more details.
    I'm an end-user, what does the LGPL mean to me?

    It means that the source code is always freely available. And it means that the people that make changes and enhancements to this source code for the core JBoss container have the obligation to LGPL their changes back when they redistribute our code.

    There are a number of benefits to users. First, users know that the project is stable, will maintain its focus and not split into a variety of different projects, since any "forks" will have to contribute their code back to the original project. Second, users can always find a means to support the software in "worst-case" scenarios since they have access to the source code. There is no need for source code escrow accounts and costs. Plus, with a large project like JBoss, there is a huge community of developers familiar with the code.

    Finally, source code is very helpful to the large community of developers using JBoss, allowing for tighter integration of their applications running on top of JBoss. While they do not necessarily want to change the code, the ability to find out what the software is really doing in the source code is a powerful asset.
    Could JBoss Inc. ever create a closed source fork of JBoss?

    No. The LGPL prohibits closed source additions to JBoss. The LGPL is very logical and explicit about this and states:
    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.
    c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.

    JBoss, Inc. fully intends to abide by the license, and our business model is, in fact, built on this foundation.

    Note that this is in stark contrast to a BSD or Apache-style license that allows for forking and creation of commercial projects. The latter allows for a "bait and switch" to users where the major sponsor withdrawals support from the open source project and forks a commercial version.
    Why is JBoss so popular with Software Vendors?

    JBoss has been identified by independent authorities as the leading Java-based Application Server in use by Independent Software Vendors. While the developers love the functionality, the key reasons so many bundle JBoss are the fact it is free and the LGPL protects them from the potential of being forced to make their own code open source.

    The LGPL allows software vendors to bundle JBoss with their software without the reciprocal requirement of the GPL. The LGPL preamble states: "The GNU Lesser General Public License (LGPL), applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs." For more information, please see the Licensing page.

    The LGPL has a major advantage in that developers who change or enhance the JBoss source code contribute their changes back. This makes the whole project better. Nearly 1,000 developers have contributed code to JBoss, including companies like Apple, WebMethods, Unisys, HP and Iona who all bundle JBoss with their products.
    We want to bundle JBoss in our software application and distribute it. Can we do that under LGPL without any compromise of our commercial licenses?

    Yes, you may bundle JBoss with your software and hardware applications without compromising your commercial licenses. JBoss, Inc. wants to promote the adoption of JBoss, and this is precisely why we chose the LGPL.

    We want to encourage software and hardware vendors to bundle JBoss. From a business perspective, we are looking to supply services to those companies that need to give their end users full professional support.

    From an open source project perspective, we are looking for users of the software to contribute back to the project. LGPL requires you to contribute changes that you make to the JBoss source code back to the community. This is a basic premise of open source, and makes the whole greater than the sum of the parts.

    The LGPL license clearly states that you may bundle JBoss code with your project. Specifically:

    "Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.

    In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License."

    Additionally, the LGPL clarifies this:

    "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

    Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with."

    JBoss provides very clean interfaces for deploying J2EE applications that are in adherence with the above statements." In addition, the SAR format to plug your libraries and code directly into the JBoss Microkernel also reinforces the above statements - meaning that you can integrate your code very tightly with JBoss without incurring arisk of a reciprocal open source license.

    Many software, hardware and telecommunications companies bundle JBoss in their products. Please review the rest of this FAQ, particularly the Trademark Section, and contact us if you have interest in using the JBoss brand name or in our training, documentation or support services. We have specific offerings for ISV's and OEM's who embed JBoss in their products that allow you to offer your end users a complete support offering, as well as licensing trademark usage rights.
    If we make changes to a JBoss LGPL product, what changes do we have to contribute back to the community?

    We only view modification of the bytecode either directly or by modification of the source and rebuilding as having created a derivative work. Simply rebuilding to create new jars is also not a derivative work. Examples of not triggering the LGPL are:

    * Removing the hsqldb-ds.xml and replace it with another datasource configuration
    * Change the port in the tomcat configuration
    * Change the version of the xml parser by dropping in a different version on the top of the existing jboss-x.y.x/lib/endorsed version

  2. #52
    Sencha User JeffHowden's Avatar
    Join Date
    Mar 2007
    Location
    Forest Grove, OR
    Posts
    1,038
    Vote Rating
    1
      0  

    Default Re: Since when did BSD/ASF become a bad word?

    Quote Originally Posted by justheatingup
    Quote Originally Posted by JeffHowden
    Quote Originally Posted by frando
    [...]In the case of Ext, I think that a BSD license + support contracts would also work...
    Unfortunately, BSD isn't doable because it permits forking.
    I don't mind the LGPL license (I don't like forking unless the project isn't maintain), but I think it's important on how you go about making MONEY with it. Just saying you want commercial software to pay for it IS NOT LGPL. Period. stop trying to "bait and switch", come up with your own COMMERCIAL LICENSE, but don't give EXT a black eye by saying its LGPL and interperting it loosely or incorrectly.
    I think you're attributing something to me that isn't there. I'm in agreement that Ext should be dual-licensed.
    Jeff Howden
    Ext JS - Support Team Volunteer
    [email protected]

  3. #53
    Ext Premium Member
    Join Date
    Mar 2007
    Posts
    60
    Vote Rating
    0
      0  

    Default Re: Since when did BSD/ASF become a bad word?

    Quote Originally Posted by JeffHowden
    Quote Originally Posted by justheatingup
    Quote Originally Posted by JeffHowden
    Quote Originally Posted by frando
    [...]In the case of Ext, I think that a BSD license + support contracts would also work...
    Unfortunately, BSD isn't doable because it permits forking.
    I don't mind the LGPL license (I don't like forking unless the project isn't maintain), but I think it's important on how you go about making MONEY with it. Just saying you want commercial software to pay for it IS NOT LGPL. Period. stop trying to "bait and switch", come up with your own COMMERCIAL LICENSE, but don't give EXT a black eye by saying its LGPL and interperting it loosely or incorrectly.
    I think you're attributing something to me that isn't there. I'm in agreement that Ext should be dual-licensed.
    I may be and may not be... Answer this question:

    If it's EXTis LGPL why would anyone want another license unless they want to MODIFY EXT itself (not just use it to build a site)?

    The USE ALONE does not warrant a commercial license under LGPL.

    ~A

  4. #54
    Ext GWT Premium Member
    Join Date
    Mar 2007
    Location
    Sweden
    Posts
    45
    Vote Rating
    0
      0  

    Default

    A very interesting thread since the outcome of the license model dictates the future of the library. The term commercial product is difficult for me. An off the shelf product for me is a product that is sold as a bundle and then installed on a local machine somewhere, howevere on the web a commercial product could also be a single instance selling services to clients. Is this also a commercial product in the sense described here?

    Another concern whith adding a commercial license is that it makes it more difficult to get "free" developer help. If someone else is going to get the money for my work I would be much more reluctant to aid in the develpment (I might be alone her?). I realize that this is a work done completely (?) by Jack for now (well done Jack) but how long will he be able to do all the job? Lets face it, as the api grows (and this api has great potential to be the next swing for JS) it takes more time to maintain and bug fix. This extra job could in the end result in Ext not being developed for the future, which I think is very important if it is to be the "next" api for the web.

    I don't know if there is any good licensing model for keeping the owneship of the code (for selling it later) and still letting other developers help in the development without getting them hurt in the end?

    I am looking forward to the 1t to see what the outcome of will be.

    Cheers
    Fredrik

  5. #55
    Ext User MrKurt's Avatar
    Join Date
    Mar 2007
    Posts
    86
    Vote Rating
    0
      0  

    Default

    There's quite a bit of misunderstanding about the LGPL, it seems. The GPL (and LGPL) doesn't make any sort of "commercial use" distinction. It's all based on distribution, regardless of money involved. The LGPL isn't restricting Ext in the way you think it is.

    The LGPL first gives a broad set of restrictions that apply to derivative works. It then removes some of those restrictions for certain types of derivative works. If we assume that a web application that makes use of Ext is a derivative work, then section 6 is what applies:

    As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
    So, I can create a derivative work and distribute however I'd like, provided that I don't restrict peoples' ability to alter the library and use the altered version in my application. It goes on the specify what type of mechanism is suitable for doing the actual linking.

    b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
    This:
    Code:
    <script src="my-special-ext.js"></script>
    is all that's required for Javascript. A user of my derived application would really only have to replace that one javascript file with their own version of Ext to meet the requirements.

    The end result is that the LGPL isn't restricting distribution the way you seem to want Ext distribution to be restricted. It seems like you want something that applies sorta like this:
    • Ext may be distributed as part of or alongside an open source application, regardless of the license
    • For the purposes of Ext, hosting an application is not considered distribution, so the license does not apply
    • In order to distribute a closed source application that makes use of Ext, a paid for license is required
    Is that about accurate?

    It's important to note that in the absence of section 6 in the LGPL, it becomes incompatible with a huge number of open source licenses. I wouldn't be able to integrate Ext into a BSD licensed application, for instance, since the BSD license doesn't restrict distribution as much as the LGPL. As a matter of fact, section 6 is really what makes it the *L*GPL.

  6. #56
    Ext User
    Join Date
    Mar 2007
    Posts
    39
    Vote Rating
    0
      0  

    Default

    One thing is for sure, Jack and the Ext team need money to keep a roof over their heads and food on the table. There has to be some commercial element to Ext - whether that's in terms of a commercial license for commercial use (and something like LGPL for non-profit use) or a free license but commercial support contracts, either way should succeed. I would think that any commercial use (eg. even on an ASP style website) should require a license or something similar. The commercial license, if that's the way things go, needs to be a proper commercial license though - it simply cannot be a bodged LGPL. I also hope that no matter which way Ext goes, it doesn't prevent small projects from using it commercially.

  7. #57
    Ext User
    Join Date
    Mar 2007
    Posts
    8
    Vote Rating
    0
      0  

    Default

    In my opinion a "premium support" model for getting the income seems like a good way to go, while keeping the library OS. Companies will gladly pay for it.

    JBoss and MySQL pop up in my mind, which are both succesful.

  8. #58
    Ext JS Premium Member mapo's Avatar
    Join Date
    Mar 2007
    Location
    Switzerland
    Posts
    75
    Vote Rating
    0
      0  

    Default

    My thoughts in this already crowded thread:

    1) to keep the quality of Ext high, the Ext team needs money
    2) this is a commercial quality library for commercial projects (can't imagine it used by open sourced/non commercial projects only), but by using a too restrictive license small commercial projects or ventures would think twice before buying a license
    3) by making Ext a fee based library, it would be put on the same shelf as other powerful AJAX enabled Javascript component libraries -> it would open up for competition. Im' not saying that Ext is not ready for such a competition, but it would be less attractive
    4) what the Ext team created in such a small amount of time shows what kind of talented people are working behind it

    All in all, I'm convinced, that Ext has the prerequisites and the "momentum" to make it a successful LGPL-based w/ fee based support/consulting project, la JBoss.

    Massimo

  9. #59
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    New York, NY
    Posts
    6,956
    Vote Rating
    20
      0  

    Default

    Hi Everyone,

    Sorry for my delayed response, I had important out-of-town meetings this weekend.

    I think this thread somehow went in the wrong direction. It started out discussing interpretation and then went to "definition" discussions, what things mean, what is covered by the license, etc.

    My initial post solely intended to state my interpretation of the LGPL. If your lawyers interpret it otherwise, or you do not feel Ext is worth buying a license for your commercial product, then that is your decision. Trying to force people to buy licenses is not what we want to do.

    We have decided other than the prohibited uses clause, we won't tweak the LGPL with definitions or otherwise. If you read the prohibited uses clause in the license, it is only covering usage by other (possibly competitive) software development libraries. As a business, we definitely want to prevent other companies from reselling Ext under their own brand. However, for projects on CodePlex (like Rodrigo) or jMaki or others, it is simple to grant them permission. The prohibited uses clause does not in any way affect redistribution of commercial apps.

    justheatingup - I take serious offense to your suggestion that we are trying to do a bait-and-switch.

    For people mentioning a dual license model, that is exactly what we are doing. There will be the LGPL license and another standard commercial license for Ext. Who needs a commercial license? As proven by this thread, that is up for debate. Rather than trying to force people into buying a license by using a hacked up LGPL, we will leave that part up to you.

    For people mentioning "just do support", we will have support subscriptions. However, I don't think you realize what with only a support model there are other things that suffer. For example, with JBoss, in early versions there was no documentation other than a getting started guide. In fact, it makes perfect sense because having great documentation is counter-productive in a support based revenue model. Imagine we take revenue earned and reinvest that to improve documentation (which is high priority). The result would be reduced need for support and decreased revenue. In general when investing time and money into something it isn't to decrease revenue. However, if improved documentation ups the usage in commercial products (and they buy licenses) then it improves revenue and everyone benefits.

    Our intention is to create a great commercial quality library, with commercial quality documentation and top-notch support. All these things take time, effort and money. In an ideal world, we could structure it how MrKurt described:

    * Ext may be distributed as part of or alongside an open source application, regardless of the license
    * For the purposes of Ext, hosting an application is not considered distribution, so the license does not apply
    * In order to distribute a closed source application that makes use of Ext, a paid for license is required
    However, there is no existing license that fits that model and too many Ext users would be affected by a change like this (yes, I do consider your interests when making decisions, not just mine).

    In the end, it all boils down to one thing. We want Ext to grow and continue to improve. The current model can't even support me, and definitely can't support me plus other people. We don't want to go the JBoss and Dojo route of earning revenue on consulting. We don't want to go the Bindows route of going fully commercial. So we needed to find a middle ground. I think the dual licensing will provide that middle ground and allow the project to realize it's full potential.
    Jack Slocum
    Sencha Co-Founder, Ext JS Founder
    Original author of Ext JS 1, 2 & 3.
    Twitter: @jackslocum

  10. #60
    Sencha User Saeven's Avatar
    Join Date
    Mar 2007
    Location
    Ottawa, Canada
    Posts
    419
    Vote Rating
    1
      0  

    Default

    I think the dual licensing will provide that middle ground and allow the project to realize it's full potential.
    Definitely applaud this decision.

    Good luck, and I look forward to the pricing structure.

    Cordially.
    Alexandre

Page 6 of 8 FirstFirst ... 45678 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •