On Mon, Aug 4, 2008 at 8:02 AM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > Before this turns completely into another license flame-war. Let's > step back and look at this from a more practical standpoint. I'm going > to list the set of arguments mentioned as to why we need LGPL, since > that is the point being argued, along with questions that would need > to be answered for this change to make sense.
> Argument 1. Our community has failed to grow because of our choice of license. > Question 1. What proof exists that choice of license has repelled more > people than it has attracted? > Counter 1. Most users don't weigh choice of license into their > decision to use a product. Even among open source users they are happy > if the software uses an OSI approved license. It's very common that > users don't even realize E is BSD. Users don't care about license. That's right. It only affect the community of developpers and people contributing back to the project. > Counter 2. E has attracted a large number of users over the years and > many of them have moved on to other things. Of the users that have > left the project, the choice of license is never brought up as the > reason. It is almost always around the lack of progress, the need for > better integration with their applications, or finding another > environment they prefer over E. Among our developers it's usually > because other obligations require too much time to contribute to the > project any longer, or simply a change in priorities in their lives. In the list, the lack of progress is mainly due to the difficulty we have to gain more contribution. That's in my opinion partially due to the license. > Argument 2. Attracting more companies will grow our community. > Question 1. Is expanded business use the best way to grow our community? > Counter 1. In most successful open source projects the support from > the business community comes after the user base has reached a > self-sustaining level with a reasonable growth rate. While E has > maintained a self-sustaining level over the years, we have a stagnant > growth rate. For the last few years we have a pretty consistent > incoming developer base of approximately the same size as the > developers that are leaving the project or cutting back their time > spent on it. So in your opinion the success of GNOME and KDE as nothing to do with the fact that many company are backing them since almost the beginning. And yes, in 10 years, the Enlightenment project failed to increase the size of it's developper base. Contributions are not increasing faster and faster, and the fact that the license doesn't create a contribution loop as nothing to do with this fact. > Counter 2. While businesses make valuable contributions to help polish > projects and develop key features, they are not usually the driving > force behind successful projects. In most cases, the projects that > have become too corporate have seen declining community contributions. > The extreme case of this is code which was started by a company and > that company has basically been doing all development, just in the > open. This can lead to projects that are too easily swayed by > corporate considerations or changes in strategy. MySQL is a good > example of this scenario. As you are making general statements, could you make them on GNOME and KDE as they are more in the same field as we are. > Argument 3. Companies can legally use and change our code without giving back. > Question 1. How does LGPL prevent this from happening? > Counter 1. The LGPL prevents this only if they make changes directly > within the code and distribute the end product. Since linking is > specifically allowed, a company can write a thin wrapper which extends > the lib with the functionality they want and just link in the existing > code. Yes, thin wrapper are a solution, but how much people are willing to do so for just a few line. It will be easier for them, to just put the source somewhere to follow the license than do the necessary amount of stuff needed by a wrapper. With the BSD license, they just don't care. Nothing force them to do the small effort to give back, so why did they need to care and do it ? > Counter 2. There is also the possibility of going the other direction, > as they could export the functionality that they want as a lib and > re-distribute the small changes within our code that access their lib. The same argument came here too. How many people did this for GTK ? None I know about, but they are many patch around that didn't get their way in the GTK code base. This patch could get integrated or not, but they are contributing back to the project itself and influence the futur of GTK. > Counter 3. The binary from the modified code is not directly > distributed to end users. For instance with a web service or other > client-server model, there is no requirement in most OSI approved > license that these modifications be distributed. Does it cover our EFL use case ? Perhaps LGPLv3 can solve this, if it really matter. > Question 2. How valuable are the companies changes to the community? > > Counter 1. Most of our code is commodity software, especially the > lower level libs. The advantage we bring is providing an entire stack > of software for development, which is flexible enough to use only > certain components when appropriate. There are many alternative > implementations of what we're providing, and the area we differentiate > currently is the uniformity of API's and the presence of Edje. Most > companies already have some equivalent of the functionality either > through standard libs in their language, internal or proprietary > implementations, or other open source options. I disagree. Could you perhaps point me to a replacement for eet and evas that does provide the same level of performance (memory and cpu) with the same kind of feature. > Counter 2. If the modifications are very specific to the companies > development environment, then there is little value added to the > community if they are given back. For instance, if they have custom > build environments, the modifications to work in that environment > don't benefit the community and pollute our code with dependencies > useful to a very specific use case. Sharing these modifications also > exposes proprietary information about the companies environment which > it may not want to share. The license say that you should publish the change, not that it should go inside the CVS. So if the patch are useless, we will not include them, but at least we have the possibility to choose. > Counter 3. Historically, companies have found it more valuable to > share code back with the community rather than to maintain separate > forks with their custom modifications. There are plenty of examples of > this throughout the history of the BSD systems, but two that are > commonly cited are the NFS filesystem from Sun, and Darwin from Apple. Historically GPL/LGPL project grow faster and get more and more contribution than the others. The only few case where this is not true is when a solution exist since so long that rewriting it is not a possibility for anyone. > Argument 4. Companies won't use our code because it's BSD licensed. > > Question 1. How are these companies coming to this decision? > Counter 1. If a company is not weighing all of these counter arguments > into their consideration, then they are not considering the full scope > of the issue. If we have an opportunity to discuss the license issue > with them we may be able to convince them by laying out the > differences between the licenses. How can you justify so easily that the work, the money you invest in a project will be used by your competitor without any thing back ? And as the contribution to the core EFL is small, it's easy to maintain your own fork. So the logical choice in that situation is just use them without contributing. > Counter 2. The decision may not be based on sound legal advice as much > as an individuals predisposition for the appearance of fairness. > Companies should consult their attorney's to determine the impact a > license has on their business decisions. Don't forget CYA, if you want to contribute, the need to ensure that your work will not help the competitor without something back, will lead your attorney to recommand LGPL. If you don't want/need to contribute, a project under BSD will be fine for him. > Question 2. How is LGPL more friendly to businesses? > Counter 1. License compliance is a huge industry. To avoid lawsuits > companies often take measures to ensure that they are following the > letter of the license in the software they are using, or detect the > presence of outside code in their code base. BSD-style licenses lessen > this burden considerably for companies, even the ones trying to do the > right thing by giving back. With LGPL, much more care must be taken > that their is no cross-pollination of code into other parts of the > software stack. > Counter 2. In order for the LGPL to make any difference versus the BSD > license, there must be license enforcement measures taken. This means > that either the community must take on the role of license enforcers > and thus be suspicious of all users, or the companies take on the role > of policing each other for license compliance. If the company is > playing this role, they are now diverting money and time from > furthering their products into enforcing a license with dubious > competitive gains. If the community takes on policing, we are > diverting community time from advancing our code base into performing > time consuming analysis of potential violators. It was perhaps true some years ago that you can violate license and steel code from LGPL product without much risk. But today, no company will really take the risk easily with all the lawsuit that free software did win over the year. > Counter 3. Companies make money by differentiation themselves from > their competition. If they are open sourcing their key innovations, > then there is no room for profit based on that work. The point where > they can profit is to offer expanded software or services beyond the > open source components. The expanded software would most likely be in > the form of an application or separate library which would not be > affected directly by either the LGPL or BSD. A service would be based > on top of the open source code and has little to do with the license. So optimising the EFL to make it run faster and use less ressource will not give you a competiting advantage ? If your are selling embeded device, and if you use less memory, less cpu to provide more powerfull apps than your competitor, doesn't this provide you with some benefit by reducing your cost on the hardware ? So that just a general assertion that doesn't match some use of the EFL. -- Cedric BAIL ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
