David's Computer Stuff Journal

People license code GPL because they want a larger ecosystem.

Writing code MIT/BSD/LGPL doesn't make that a requirement.

It's requiring fair play - if you use free software, then you should be releasing free software.

The problem is that the smaller, and more libraryish something is, the less likely it is that GPLing the code will actually have an influence. The proprietary code will march on as before, and the GPL'ed code will have fewer users, thus decreasing its overall quality.

Like I said, I'm not an anti-GPL guy, but I think that license is a net loss for smaller, library-oriented code bases.

That's the reason, after all, why the LGPL exists - by increasing the total number of users, the utility of the code in question increases for everyone.

I think the size matters less then the uniqueness of a library: if it's a unique solution to a problem, then going with the GPL means letting people chose if the want to solve the same problem again, or if they want to reuse the solution and open up their own code according to the GPL.

That can lead to more free software iff the trade-offs are right for the users.

If it's not a unique solution to a problem, then it doesn't matter if it's GPL licensed: users will just use whichever other solution fits their (licensing) constraints better. ;)

And if the trade-offs are not right, then the users will prefer solving the problem on their own, anyway.

I should also add that I've seen some libraries start under GPL, and move to LGPL over time, as the trade-offs evolve.

In general I agree with Greg Stein, though. ;)

Ok lets think the other way around, why don't proprietary vendors don't publish their code?

I suppose in this case, someone might still write proprietary code if their goal is solely to keep it out of the hands of public and commonality, even at the cost of having less utilized and contributed to their code, but it's not an optimal strategy otherwise.

I guess you see some similarities with your post ;)

Rubygems isn't in any an official repository that's been "blessed" by anybody. It's a convenient way to get all of the code that people have developed on rubyforge.org

Now, if you'd like to add a feature for selecting licenses based on the license selected on the Rubyforge project page, then all this awaits is a patch from you.

If you'd like to have an official repository that's been "blessed" by somebody, it needs a curator. Do I hear you volunteering?

tos - the proprietary developer is pursuing a strategy that looks like this, generally:

code quality - probably a bit less than opening it would produce.

money - far more than is likely if it's open, if the code is a strategic asset.

So they are definitely pursuing the optimal strategy as far as they're concerned (although if the code isn't critical to them in terms of providing scarcity that they make money from, they may be mistaken to hold on to it so tightly). Their goal clearly isn't simply to maximize code quality, but to balance that with revenue, which is clearly not, or less of a direct goal for most people releasing free software.

Dalibor - you're right that the situation becomes cloudier if the library is a big, unique piece of work, which is why I used the example of a small library that doesn't do anything earth shattering.

Ken - my mistake, I thought there were minimal standards in place for the gem system. Of course, the fact that anyone can upload any old thing is perhaps a more worrying problem than any licensing issues.

http://www.gnu.org/licenses/why-not-lgpl.html

I've released one library on Rubyforge under the GPL simply because I agree with that article. Not that my library is in any way world-changing, but I do believe in free software, and those are my terms for using my code.

If someone was to make a proprietary application with my library, it's likely only that someone would benefit, while if someone makes a free application with it, everyone would. That it may be less likely that the free app is developed doesn't bother me, as I have no interest in it anyway.

Also note that if you want to use my library for personal or internal use, there are no such restrictions. It's only if you want to distribute the application the GPL kicks in. At which time I think it's only fair to share right back.

Quite possibly, but you'd be downloading the same packages from rubyforge and installing them manually anyway if you wanted to use them. You can always install and then audit the code in /var/lib/gems (on Debian) to verify that it's not malicious.

Do you think that packaging GPL modules in Ruby GEMs is per se in violation of those GPL licenses? Unless people are taking snippets of GPL code and inserting them into a module that is licensed in a way incompatible with the GPL, then a more thorough legal analysis is required. Alas, Mr. Stallman has done his community no favor by the license confusion he has carelessly perpetutated.

Stoffe - I understand the desire to see your code used under terms that are acceptable to you, but consider this:

The smaller your library is, the more likely it is the proprietary guy is just going to write his own code, find an alternative, or otherwise work around it.

Now, consider that for each user of your code, there will be some rate of contributions back to the codebase. It might even be fair to say that for proprietary users it will be 1/10, and for free software users, 2/10 (because more of them get it and are enthusiastic about helping). However, by forcing the proprietary guy into using other code, you are foregoing that rate of improvement. Think about it statistically, because it's not just one user of each type - think about foregoing 10...100...1000 people who are potential contributors.

Beyond even direct contributions, for code that has some amount of positive network externalities, you and your users are also foregoing that value by excluding a segment of potential users.

@David

some points to that. It is not the problem that they make money out of code, thats ok. But its problematic when they want to make money with work others did. Then they should pay for it. Either by contributing code, or by donating. And because the original creator often has the possibility to dual licence the code, everybody would be happy with that. Because then the original author(s) have the chance to use the money for their further development.

Another problem of proprietary software is mostly that it often tries to prevent the switch to another system, because this is part of the concept - to earn more money with it. Furthermore the creator of the software has less incitement to take care of the customer, because they have sold it once and are more interrested in selling even more. They want to work once and earn many times without doing further improvements (Of course they improve the code (with open source?) but for that they want to have again money for upgrades, new licences etc).

And in the end you can again have a monopoly like with Microsoft. Noone has really the chance to avoid their Operating System today. With OpenSource a frustrated community always has the chance to fork and free the world of that cancer (see mambo/joomla).

Additionally I want to throw a talk toward you, that shows, imho, how important open source can/will be in the future (the opportunity at least). http://www.php.no/phpvikinger#zak

tos - my point is not to debate the merits of licenses and open source in general - that's a huge topic. Suffice it to say that I'm a huge fan of free software, and have been participating in it for around 10 years.

My point is simply that for small libraries, where there is no chance of making money with them on their own, that the BSD license is better because it maximizes software quality by enlarging the potential group of users and contributors. We're not talking about large systems like Mysql where there is a market for dual licensing, but for sub 1000 line bits of code where they just aren't worth much on their own.

I had a look at that video, but I have to admit that I don't like videos much, because they are slow compared to reading, so I gave up after 15+ minutes of talk about sumerians and the like.

Further material that I would recommend includes Hal Varian and Carl Shapiro's Information Rules - it goes into detail about the concept of lock-in, that you correctly point out as a problem with certain proprietary systems.

In terms of free software and economics, that's another terribly complex subject, that I find fascinating. I've written a thing or two on it myself, including this one that I think sums up some of the problems, from the point of view of someone attempting to implement a business based purely on free software:

In Thrall to Scarcity

GPL its good for couse scripts are faste developed.... but im makieng own cms.. and i think that not will be on GPL ..

@David: Ok maybe I got you a bit wrong first, I didnt wanted to appear offensive or start a flamewar :).

But still, for use in a commercial tool I think its suitable when the vendor donates to the project and then use a dual license (which the copyright holder can give).

And when it is too small, then a proprietary vendor should write it on his own. He decides with his code to own it, so he can be on hits own or not?

Guys, it's just GPL, as for me that's really not good idea.

Thanks for this site! cialis online cheap cialis buy cialis online buy cialis