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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Please speak up if I missed any of the primary arguments, or you feel I mis-characterized one of the primary arguments. Nathan ------------------------------------------------------------------------- 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
