In all honesty, I don't think a license makes or breaks a project.. unless of course it's closed source. I don't think you're realizing how much crap has to be done to change licenses for little to no reason.
On Mon, Aug 4, 2008 at 9:59 AM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------------------------- 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
