Your preference for BSD is certainly valid, but it's valid because of your objectives.
If you want a software package that you own to be openly collaborated, but still controlled by you, the GPL is a great copyright construct to do that with.
There isn't a right answer here. I think Stallman has an ideologically pure argument that is appealing to me as a consumer, but not always ideal for my business needs.
I disagree that BSD solutions will necessarily "win" in the long run. There's no incentive to share.
> I think Stallman has an ideologically pure argument that is appealing to me as a consumer, but not always ideal for my business needs.
I, OTOH, given the conflict between Stallman's position on selling GPL exceptions vs. his position on non-copyleft licenses, and given the GPLv3's domain-based discrimination in what is required freedom, thing Stallman and the FSF have ideologically incoherent positions.
> I disagree that BSD solutions will necessarily "win" in the long run. There's no incentive to share.
There is only no incentive to share if you think that open source has no independent value to producers, that its a sacrifice they make in order to be permitted to use others work. While the GPL model and a mass of early high-quality software licensed under that model was probably essential in getting people to accept the value to producers of open source, once that value was widely accepted -- as it now is by many major software producers -- the incentive to share isn't from someone holding a gun to the producer's head, its from the value of community engagement with the code that permission to use it fosters.
There is no conflict between Stallman's position on selling GPL exceptions and his position on non-copyleft licenses. He considers neither unethical, and has considered positions on the tactical considerations. You many disagree with any of it, but it's not incoherent.
There are plenty of incentives to share. They can be summarized by this: Code that you don't share is code that you have to maintain yourself. Code that you share is code that you can offload the maintaining to someone else.
With BSD, there is no legal incentive for somebody to take their ball and go home, or take your ball and sell it. Depending on what you want, that can be a good thing.
Making commercialization difficult is not always bad -- if you own the copyrights, you can license to commercial users under terms favorable to you.
Also I don't think the BSD license makes it harder to commercialize software than the GPL does. You can't have a dual license model without the GPL, and that also requires copyright assignments. And once you do that, you are controlling not whether the software can be commercialized but merely who can commercialize it.
It stops anyone from using the code (including extensions to the code) as a unique differentiator. In no way does it prevent "everything commercial related". If there are other barriers to entry, you can still perfectly well charge for access to a service running AGPL code.
The whole business of the company I work for, and of the large network of peers around the world, is built around a piece of AGPL licensed software called OpenERP[1].
Just to poke a little fun at you, Most ERP softwares are not well-known for being exactly understandable by average developer, and is known to be consultant-based business so much that it is hardly possible to learn it without paying for consultant.
It's just another way of being proprietary by obscurity.
Wanna combine "free" with another brand or version of "free"? Avoid any "free". Avoid any GPL. Use something that is unquestionably free, with no strings attached.
What you're saying makes absolutely no sense. If combine MIT and GPL, you combine MIT and GPL whether you're using MIT or GPL because, wait for it.. you're combining MIT and GPL. You either can combine these or you cannot. You can use both or you cannot. Which is it? There are many projects that combine MIT and GPL code.
But GPL is the license that rather explicitly forbids combining with some licenses.
EDIT: If you're saying that you cannot combine free with "free" and remain free, then you're right -- you cannot combine MIT with GPL.
And you're right in that a nonfree project can incorporate free code into it. So they have more options, but the end result remains nonfree.
Only code in the public domain or under the WTFPL is categorically freer than the GPL. The MIT and BSD just impose different conditions that you have to follow.
So if I'm going to subject myself to licensing restrictions, it's silly to restrict myself to some code.
I said nothing about incompatibility with other licenses. I said that by licensing your code under MIT, you're restricted from using L/GPL code, while the opposite is not true, and if you're going to use code that imposes restrictions anyway (like MIT-licensed code), you're better off allowing yourself to use GPL-licensed code as well.
The MIT license does not prohibit using GPL, unless there is a license incompatibility (which I do not see). You can of course prohibit yourself but that has nothing to do with the license. If you release that code, other people can still combine with whatever regardless of what you restrict yourself to.
The GPL on the other hand does prohibit many licenses. Whether you want it or not. Or whether the people who use your code want it or not.
A license that you choose personally never prohibits you from doing anything, because you're the copyright holder, so you don't need a license at all. So choosing the GPL for your doesn't prohibit you from doing anything either. What it does is allow you to use someone else's GPL code, which the MIT doesn't.
Indeed. In fact since the MIT license explicitly grants sublicensing, you can take MIT-licensed software and simply offer it with no modifications under the GPL. This is not safe to do with the BSD license btw.
> If you use BSD, MIT, etc, you can't combine any GPL licensed code.
In the LedgerSMB project, I have started licensing core framework libraries under the BSD license because that should allow easier bridging to proprietary software. We started doing this with PHP libraries, but then decided that Perl shouldn't be a second-class language integration-wise.
There's no reason that GPL code can't depend on BSD code.
These licenses can co-exist and one can choose to license some parts of a project under the GPL and others under a BSD license.
If you want a software package that you own to be openly collaborated, but still controlled by you, the GPL is a great copyright construct to do that with.
There isn't a right answer here. I think Stallman has an ideologically pure argument that is appealing to me as a consumer, but not always ideal for my business needs.
I disagree that BSD solutions will necessarily "win" in the long run. There's no incentive to share.