I want to point out that as the person asking for the change, the burden of proof is on you. Therefore, look at your statements below and show us solid proof behind any of them.
For every example you give of an open source project that supposedly succeeded because of it's license being GPL/LGPL, you can find others that have comparable success with a different license. You also treat this discussion with the founding principle that license is the only variable in project success, which is neither true or a reasonable basis to start from. On Mon, Aug 4, 2008 at 8:32 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > > Users don't care about license. That's right. It only affect the > community of developpers and people contributing back to the project. You say that developers make the difference and users don't care, but where do you think your developers come from in an open source community? Most of the active developers in the history of E have come from people that started as users. There are a few exceptions of people that were paid explicitly to do some work and had not previously used E. If you attract a growing user base you attract more potential developers. Where are our users coming from these days? Every time E makes some headlines, we see a sudden influx of users and usually get a few patches from them. Regular attention to a project is what drives a steady influx of users and developers. > 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. Ok, so you've stated an opinion with no backing evidence... > 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. KDE and GNOME are not the same thing, they were desktop environments with supporting libs long before E went that direction. In fact, I already mentioned this history in an earlier thread and pointed out that people in E helped develop the base of GNOME. E is the relative new comer in the desktop area where there are already two major established players. We have not even made a release in that area while they're well-established with many past releases and regular media attention. Their success was helped by companies contributing to them, but companies contribute to them because they have an active user base and community. Also, E had companies paying for work on it from some of it's earlier days as well, but it was done as part of GNOME originally. Later it had paid development work done on the basis of a desktop shell, but there are very little remnants of that work remaining in the code base. Lastly, you're right and wrong about failing to increase the size of the developer base. We've had peaks and valleys throughout the last 10 years. There are times when we've had a steadily growing number of developers, and then a sudden increase in attrition. The influx occurred when E had some media exposure such as a magazine article or when yellow dog started shipping with it. Usually we lose developers around these types of discussions, and not the people actually making the arguments, but bystanders that feel the project has become too political. >> 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. Sure, both GNOME and KDE have contributions from a variety of companies and have a healthy eco-system of non-paid contributors too. You can't rely companies to be your benefactor to reach your goals, but they can be strong community members. >> 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 ? It's very little work to setup a wrapper, and if they consider it to be code that is valuable and don't want to share, then why not? Do you have any evidence that your example of not giving back is happening in any way that adds value to our 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. > > 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. Thank you for making my point. No one bothers to do this because it's far more costly to maintain the patches separately going forward than any loss of value contributing them back. Anyone that is going to make valuable contributions will work with the community to make their patches meet the communities standard, if they don't, the patches are just a drain on community time. >> 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. Usually not, but we do provide IPC and network wrappers along with a variety of data abstractions, so it's not completely impossible. Also, some of our image manipulation libraries have had php wrappers around them previously, and I know of a few users that used them server side. > 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. Eet is basically a file with serialized data structures. You should be able to find a number of alternatives on Google quickly. As for Evas, it is a very fast canvas, but there are plenty of other canvases out there. I have not done a performance comparison to say which ones are equivalent. That being said, as this is open source code, there is nothing stopping anyone from looking at Evas to determine how it's performance is accomplished and replicating it in another library. >> 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. And what did the company or the community gain from this exchange? The company had to go through the appropriate legal steps to clear the code, and if it is a proprietary build environment may have exposed some key pieces of information that they believe give them a competitive advantage in their development cycle. >> 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. Another statement without facts to back it up. Projects succeed when they fill a niche where there is demand. This has nothing to do with license as long as it's sufficiently open source. > 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. Did you forget all of the previous points before you got to this one? The license has nothing to do with your competitors using your code without giving back. If they don't want to give back, they can easily avoid it one way or another regardless of license. We need to work with our users to encourage an environment that encourages good citizenship and makes the benefits of contribution clear. What proof do you have that maintaining a fork is such a trivial task? I would feel sorry for any company that has tried to maintain a fork of their work for E over the years. They would have invested a lot of money into keeping up with a constantly shifting code base even if the changes were small. > 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. No, they don't need to ensure against helping the competition, there are examples all over the business world of companies that do things that potentially can help their competition without direct justification. Besides, based on what I mentioned previously there is no guarantee under the LGPL that the competition has to give anything back. >> 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. My compliance statement before this was intended to point out that companies are not always intentionally "stealing" code. Remember companies are not omnipotent entities, they are composed of many individuals. What about situations where the company is legitimately using LGPL code as a library, and one employee decides to copy and paste a set of routines into another non-LGPL piece of code? That company has just unknowingly committed an LGPL violation and has taken on that risk you mention. Under our BSD license, this would be acceptable as long as they advertised the original use of their code (which under this scenario they would be since the company was trying to do the right thing). If your statement of risk is true, this makes the use of LGPL code even less business friendly. > 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. Not much of one. Speed is important, especially in embedded devices, but I would not stake my business on being able to maintain a custom fork of open source code with speed enhancements. If someone in the community comes up with a comparable speed boost, your competitive advantage is gone and unless you're well diversified, so is your business. That's an extremely high risk business plan. ------------------------------------------------------------------------- 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
