In defense of BSD licenses (response to Zed Shaw)(pwang.wordpress.com)
pwang.wordpress.com
In defense of BSD licenses (response to Zed Shaw)
http://pwang.wordpress.com/2009/07/14/in-defense-of-bsd-licenses-response-to-zed-shaw/
41 comments
I've never been in a situation where dual licensing was applicable, but when I give away software, I usually paste in the MIT license. I figure - if it's going to be free, it should be completely free.
Free to whom? If you want developers to retain all the rights, there's already a license for that -- "all rights reserved". If you want users to have rights, then the GPL is the best choice.
Maybe if I thought the GPL license stood a chance to ever make it so that all software, or at least the majority, was free and intellectual property was dead...then I would use it - but to try and make such a giant philosophical/political change just in the software industry appears naive.
So because something wildly improbably and likely harmful won't happen, you refuse to use the GPL? Perhaps you don't recognize how bizarre your argument is, so lets apply it to a different situation: Maybe if I thought bicycling stood a chance to ever make it so that all transportation, or at least the majority, was human-powered and long-distance travel was dead...then I would use it.
If intellectual property is what we want to get rid of (the philosophical reason to go with GPL rather than BSD)
Nonsense. If somebody doesn't care about copyrights at all, they would release their software into the public domain. Obviously this is an uncommon choice.
The philosophical reason to use the GPL, rather than the BSD or MIT licenses, is to ensure that users have certain rights to the software they use.
Free to whom? If you want developers to retain all the rights, there's already a license for that -- "all rights reserved". If you want users to have rights, then the GPL is the best choice.
Maybe if I thought the GPL license stood a chance to ever make it so that all software, or at least the majority, was free and intellectual property was dead...then I would use it - but to try and make such a giant philosophical/political change just in the software industry appears naive.
So because something wildly improbably and likely harmful won't happen, you refuse to use the GPL? Perhaps you don't recognize how bizarre your argument is, so lets apply it to a different situation: Maybe if I thought bicycling stood a chance to ever make it so that all transportation, or at least the majority, was human-powered and long-distance travel was dead...then I would use it.
If intellectual property is what we want to get rid of (the philosophical reason to go with GPL rather than BSD)
Nonsense. If somebody doesn't care about copyrights at all, they would release their software into the public domain. Obviously this is an uncommon choice.
The philosophical reason to use the GPL, rather than the BSD or MIT licenses, is to ensure that users have certain rights to the software they use.
Free to whom? The freedom to use it in commercial software is restricted by the GPL. For this reason I consider the BSD/MIT licenses more free, for it says nothing except, go ahead use it, tinker with it, change it, republish it, whatever.
Maybe if I thought bicycling..., I think your analogy would work better if it was bicycling as a strategy to fight against the cars and freeways paradigm. The GPL is a legal tactic of the FSF movement, who believe that intellectual property in software is immoral - it's not just the promotion of more free software. Being that the software industry exists within a larger social framework where intellectual property is accepted, and we have many commercial entities doing it, I don't believe that producing more GPL software will result in reversing that move that Stallman was so upset about, that led to the FSF - that move from everyone freely sharing their software in the early days, to closing it up and selling it commercially. For your bicycling analogy, I think the BSD/MIT licenses work fine. Biking is fun, and so is making free software, but biking more as a tactic to end the automotive industry, once again, seems naive. I believe that if the FSF has a moral problem with intellectual property, a legitimate philosophical argument, then it should be addressed on a larger scale than simply in software.
The philosophical reason to use the GPL, rather than the BSD or MIT licenses, is to ensure that users have certain rights to the software they use. - The BSD/MIT licenses are more free for the user, for they can now use it in commercial software, a right eliminated by GPL. This protection of rights argument comes from the mentioned viral strategy of the FSF as a strategy to --combat-- proprietary software, specifically by eliminating this freedom to use it in commercial software (an immoral use).
Trying to cause such a revolution from inside the software industry out doesn't seem plausible to me. Maybe I'm wrong - and maybe they'll win, but I don't think it's doing much -- so I continue to paste in the MIT license when I want to give away software, just so they know they can do whatever they want with it, and if someone wants to paste some of that into their commercial program, wonderful -- knowledge shared - which was my goal of giving it away: to contribute to the general understandings and capacities of software.
Maybe if I thought bicycling..., I think your analogy would work better if it was bicycling as a strategy to fight against the cars and freeways paradigm. The GPL is a legal tactic of the FSF movement, who believe that intellectual property in software is immoral - it's not just the promotion of more free software. Being that the software industry exists within a larger social framework where intellectual property is accepted, and we have many commercial entities doing it, I don't believe that producing more GPL software will result in reversing that move that Stallman was so upset about, that led to the FSF - that move from everyone freely sharing their software in the early days, to closing it up and selling it commercially. For your bicycling analogy, I think the BSD/MIT licenses work fine. Biking is fun, and so is making free software, but biking more as a tactic to end the automotive industry, once again, seems naive. I believe that if the FSF has a moral problem with intellectual property, a legitimate philosophical argument, then it should be addressed on a larger scale than simply in software.
The philosophical reason to use the GPL, rather than the BSD or MIT licenses, is to ensure that users have certain rights to the software they use. - The BSD/MIT licenses are more free for the user, for they can now use it in commercial software, a right eliminated by GPL. This protection of rights argument comes from the mentioned viral strategy of the FSF as a strategy to --combat-- proprietary software, specifically by eliminating this freedom to use it in commercial software (an immoral use).
Trying to cause such a revolution from inside the software industry out doesn't seem plausible to me. Maybe I'm wrong - and maybe they'll win, but I don't think it's doing much -- so I continue to paste in the MIT license when I want to give away software, just so they know they can do whatever they want with it, and if someone wants to paste some of that into their commercial program, wonderful -- knowledge shared - which was my goal of giving it away: to contribute to the general understandings and capacities of software.
The freedom to use it in commercial software is restricted by the GPL.
Not at all. Software licensed under the GPL cannot be used in proprietary software. There is no restriction on commercial use.
For this reason I consider the BSD/MIT licenses more free, for it says nothing except, go ahead use it, tinker with it, change it, republish it, whatever.
Again: "free to whom?". From the user's perspective, the GPL provides more freedoms than the BSD and MIT license.
The GPL is a legal tactic of the FSF movement, who believe that intellectual property in software is immoral
This is not correct. The FSF is against use of the term "intellectual property", because it conflates unrelated sections of law, but they are not against copyright. The FSF site is copyrighted, their licenses are copyright licenses, and they even require assignment of copyright for any patches applied to GNU software.
I do not understand where the belief that the FSF opposes copyright springs from, but it has no basis in reality.
The BSD/MIT licenses are more free for the user, for they can now use it in commercial software, a right eliminated by GPL.
That's an odd definition of "user". What about the person sitting at the terminal, using the software? Are they guaranteed the right to inspect, modify, and distribute it? Remember that Stallman launched the FSF out of frustration with a poorly-implemented printer driver that he was not allowed to fix.
Every right granted to somebody is taken from somebody else. The emancipation proclamation stripped rights from slave-owners. Women's suffrage stripped rights from men. The GPL strips rights from distributors. Nevertheless, these things are named as increasing freedom because the rights they remove are ways to hold power over others.
Not at all. Software licensed under the GPL cannot be used in proprietary software. There is no restriction on commercial use.
For this reason I consider the BSD/MIT licenses more free, for it says nothing except, go ahead use it, tinker with it, change it, republish it, whatever.
Again: "free to whom?". From the user's perspective, the GPL provides more freedoms than the BSD and MIT license.
The GPL is a legal tactic of the FSF movement, who believe that intellectual property in software is immoral
This is not correct. The FSF is against use of the term "intellectual property", because it conflates unrelated sections of law, but they are not against copyright. The FSF site is copyrighted, their licenses are copyright licenses, and they even require assignment of copyright for any patches applied to GNU software.
I do not understand where the belief that the FSF opposes copyright springs from, but it has no basis in reality.
The BSD/MIT licenses are more free for the user, for they can now use it in commercial software, a right eliminated by GPL.
That's an odd definition of "user". What about the person sitting at the terminal, using the software? Are they guaranteed the right to inspect, modify, and distribute it? Remember that Stallman launched the FSF out of frustration with a poorly-implemented printer driver that he was not allowed to fix.
Every right granted to somebody is taken from somebody else. The emancipation proclamation stripped rights from slave-owners. Women's suffrage stripped rights from men. The GPL strips rights from distributors. Nevertheless, these things are named as increasing freedom because the rights they remove are ways to hold power over others.
>> The GPL is a legal tactic of the FSF movement, who believe that intellectual property in software is immoral
> This is not correct.
Well, it is basically correct. The core idea of the Free Software movement is that all software should be free. They believe that software not fitting their subjective definition of "free" is immoral (or evil).
This has been declared quite a few times by Richard Stallman; for example, here:
“The free software movement aims for a social change: to make all software free so that all software users are free […]. Every non-free program gives its developer unjust power over the users. Our goal is to put an end to that injustice.” -- http://www.gnu.org/philosophy/compromise.html
I admit, the word "intellectual property" was an unlucky choice by the previous poster.
> This is not correct.
Well, it is basically correct. The core idea of the Free Software movement is that all software should be free. They believe that software not fitting their subjective definition of "free" is immoral (or evil).
This has been declared quite a few times by Richard Stallman; for example, here:
“The free software movement aims for a social change: to make all software free so that all software users are free […]. Every non-free program gives its developer unjust power over the users. Our goal is to put an end to that injustice.” -- http://www.gnu.org/philosophy/compromise.html
I admit, the word "intellectual property" was an unlucky choice by the previous poster.
You must be using some definition for "correct" of which I was previously unaware. The FSF opposes the term "intellectual property" because it is vague and confuses several unrelated areas of law. However, I have never heard them argue against copyright, trademark, or patents -- only specific, poorly-considered applications of these such as patents on equations.
Furthermore, the only way to have capital-F Free software requires strong copyright protection. In a world without copyright, Free software would be impossible because there would be no laws to prevent distribution without the source code.
Furthermore, the only way to have capital-F Free software requires strong copyright protection. In a world without copyright, Free software would be impossible because there would be no laws to prevent distribution without the source code.
That's an odd definition of "user". What about the person sitting at the terminal, using the software? Are they guaranteed the right to inspect, modify, and distribute it?
That person doesn't know how to inspect or modify it, and largely doesn't pay any attention to the license before emailing it to a friend. That person at the terminal isn't using code, they're using a program. Once you start talking about the rights to inspect and modify software, you've left those people behind, so they aren't the users who are concerned with those rights.
Frankly, I hope the day comes faster -- for it is coming, make no mistake -- when people "protect" their work by contract and technological measures alone, rather than by legal threats and actions. For people sitting at computers and using programs, that day has already largely arrived, in spite of the attempts by the RIAA, et al, to roll back to a time when that wasn't so. Eventually the legal situation will catch up with the cultural one.
That person doesn't know how to inspect or modify it, and largely doesn't pay any attention to the license before emailing it to a friend. That person at the terminal isn't using code, they're using a program. Once you start talking about the rights to inspect and modify software, you've left those people behind, so they aren't the users who are concerned with those rights.
Frankly, I hope the day comes faster -- for it is coming, make no mistake -- when people "protect" their work by contract and technological measures alone, rather than by legal threats and actions. For people sitting at computers and using programs, that day has already largely arrived, in spite of the attempts by the RIAA, et al, to roll back to a time when that wasn't so. Eventually the legal situation will catch up with the cultural one.
That person doesn't know how to inspect or modify it, and largely doesn't pay any attention to the license before emailing it to a friend. That person at the terminal isn't using code, they're using a program. Once you start talking about the rights to inspect and modify software, you've left those people behind, so they aren't the users who are concerned with those rights.
This is a common refrain when criticizing the GPL -- that users are hopelessly ignorant, and incapable of even the most basic modifications to the software they use. "Why even bother giving them the source? They'll never be able to use it anyway".
There are several issues with this criticism. Ignoring for now the set of end users with the technical ability to modify and compile the source code on their own, lets assume a non-technical user wants to make a change to the software on their system. The software is licensed under the terms of the GPL, so the source is available. This user has several options:
1. Buy some books, attend classes, and learn enough about software engineering to modify it themselves. Not an attractive option, obviously, but it's available as a fundamental baseline. This is only available to users with plenty of free time.
2. Ask somebody, either in the online or local community, to make the change and provide the updated version. This is the purpose of "bug trackers", a popular fixture on most websites for free software. Unreliable for complex features or specialized use cases, but for issues common to everybody ("software crashes when this button is double-clicked") it can be effective.
3. Hire a contractor to modify the software. Possibly expensive, depending on what language the software is written in and what changes are being made, but likely within the budget of even small businesses for most reasonable cases.
Now, lets compare it with the case of a non-technical user with a BSD-licensed binary on their system. The source code might not be available, because the BSD license does not require distribution of corresponding source, and there may be legal restrictions on whether the user is allowed to inspect or modify the software.
1. The first option, "do it yourself", is made more difficult because the set of required skills will be larger. Assuming for now that the software was given to the user under the BSD license (ie, no additional restrictions), they still face the challenge of reverse-engineering and modifying the binary. This requires a more specialized skill-set than modifying (for example) Python or Java code. It can be done -- I know a dentist who hex-edited his practice management software to change some poorly-worded tooltips which were confusing his staff -- but will certainly be more difficult than modifying the source.
2. Since the source code for some version of the software is probably on the internet, somewhere, the user can attempt to find it. This source might not correspond to the version on the user's system -- perhaps there are missing features, or incompatibilities between versions. In the best case -- source is the same version, everything works -- there was no advantage to the user over GPL'd software. In the worst case, the source is useless and the user must revert to editing the binary.
3. Asking the distributor to make changes to the software is possible, but unlikely to succeed unless the change is likely to result in additional revenue to the distributor.
4. Hiring a contractor will be much the same as in the GPL'd case, assuming no additional restrictions have been applied. However, as in the first case, editing of a compiled file without the corresponding source will be difficult and time-consuming. The price of hiring a sufficiently skilled contractor will be tremendous.
This is a common refrain when criticizing the GPL -- that users are hopelessly ignorant, and incapable of even the most basic modifications to the software they use. "Why even bother giving them the source? They'll never be able to use it anyway".
There are several issues with this criticism. Ignoring for now the set of end users with the technical ability to modify and compile the source code on their own, lets assume a non-technical user wants to make a change to the software on their system. The software is licensed under the terms of the GPL, so the source is available. This user has several options:
1. Buy some books, attend classes, and learn enough about software engineering to modify it themselves. Not an attractive option, obviously, but it's available as a fundamental baseline. This is only available to users with plenty of free time.
2. Ask somebody, either in the online or local community, to make the change and provide the updated version. This is the purpose of "bug trackers", a popular fixture on most websites for free software. Unreliable for complex features or specialized use cases, but for issues common to everybody ("software crashes when this button is double-clicked") it can be effective.
3. Hire a contractor to modify the software. Possibly expensive, depending on what language the software is written in and what changes are being made, but likely within the budget of even small businesses for most reasonable cases.
Now, lets compare it with the case of a non-technical user with a BSD-licensed binary on their system. The source code might not be available, because the BSD license does not require distribution of corresponding source, and there may be legal restrictions on whether the user is allowed to inspect or modify the software.
1. The first option, "do it yourself", is made more difficult because the set of required skills will be larger. Assuming for now that the software was given to the user under the BSD license (ie, no additional restrictions), they still face the challenge of reverse-engineering and modifying the binary. This requires a more specialized skill-set than modifying (for example) Python or Java code. It can be done -- I know a dentist who hex-edited his practice management software to change some poorly-worded tooltips which were confusing his staff -- but will certainly be more difficult than modifying the source.
2. Since the source code for some version of the software is probably on the internet, somewhere, the user can attempt to find it. This source might not correspond to the version on the user's system -- perhaps there are missing features, or incompatibilities between versions. In the best case -- source is the same version, everything works -- there was no advantage to the user over GPL'd software. In the worst case, the source is useless and the user must revert to editing the binary.
3. Asking the distributor to make changes to the software is possible, but unlikely to succeed unless the change is likely to result in additional revenue to the distributor.
4. Hiring a contractor will be much the same as in the GPL'd case, assuming no additional restrictions have been applied. However, as in the first case, editing of a compiled file without the corresponding source will be difficult and time-consuming. The price of hiring a sufficiently skilled contractor will be tremendous.
First, let me point out that "hopelessly ignorant" seems pejorative, and since I'm in the category I was describing for most of the technologies of which I'm a user, I'd prefer "rationally ignorant". It's not a good use of my time to learn everything about the inner workings of a tool I'm using, if I'm not already interested, and most non-programmers are not interested. There are, as you note, exceptions, such as your dentist.
I don't even disagree with the bulk of your post, nor am I interested in discouraging use of the GPL (at least, before free software is the default, whereupon I'll encourage people to use licenses with fewer restrictions, or public domain, as I do, licenses and contracts permitting).
I also prefer for the source code to be available, but I don't think it's properly a legal matter to make sure that it is. I have a lot of sympathy for the view that the GPL's source code requirements are necessary to make enforcement of the other terms practical, thus aiding the copyleft, however, which is a good reason for me not to complain about GPL software or licensing, and I don't.
I do, though, think that it's somewhat beside the point to talk of the needs of the end user regarding the license provisions about source code, which was my original reason for replying. As a practical matter, few end users ever care about the source code, and few end users pay any attention to the licenses of software they use anyway, and that last is a behavior I'd like to encourage. If enough people ignore bad laws, they cease to be effective.
I don't even disagree with the bulk of your post, nor am I interested in discouraging use of the GPL (at least, before free software is the default, whereupon I'll encourage people to use licenses with fewer restrictions, or public domain, as I do, licenses and contracts permitting).
I also prefer for the source code to be available, but I don't think it's properly a legal matter to make sure that it is. I have a lot of sympathy for the view that the GPL's source code requirements are necessary to make enforcement of the other terms practical, thus aiding the copyleft, however, which is a good reason for me not to complain about GPL software or licensing, and I don't.
I do, though, think that it's somewhat beside the point to talk of the needs of the end user regarding the license provisions about source code, which was my original reason for replying. As a practical matter, few end users ever care about the source code, and few end users pay any attention to the licenses of software they use anyway, and that last is a behavior I'd like to encourage. If enough people ignore bad laws, they cease to be effective.
[deleted]
"If you want users to have rights"
Depends on the users you're talking about.
The GPL trades away some of your freedom right now to maximize the potential freedom of people who have not yet received the software.
The BSD license maximizes your freedom now at the potential expense of the freedom of people who have not yet received the software.
As someone who builds and uses tools for developers, BSD is thus more useful to me, because it grants the maximum freedom to the people I target -- myself, and other developers to whom I distribute BSD-licensed tools.
Depends on the users you're talking about.
The GPL trades away some of your freedom right now to maximize the potential freedom of people who have not yet received the software.
The BSD license maximizes your freedom now at the potential expense of the freedom of people who have not yet received the software.
As someone who builds and uses tools for developers, BSD is thus more useful to me, because it grants the maximum freedom to the people I target -- myself, and other developers to whom I distribute BSD-licensed tools.
The typical path for software looks like this:
Developer -> Distributor [-> Distributor ...] -> User
The BSD license grants rights from the developer to the first distributor in the chain. Other distributors, and the end user, are completely dependent on that first distributor to pass on the rights he received.
The GPL requires that certain fundamental software rights are passed down the chain. This ensures that a single ill-behaved distributor will not restrict the rights of the end user.
As someone who builds and uses tools for developers, BSD is thus more useful to me, because it grants the maximum freedom to the people I target -- myself, and other developers to whom I distribute BSD-licensed tools.
There is no need to pick a license to maximize your own rights -- by the nature of international copyright law, you already have all possible rights to your work. The difference is whether rights should be transmitted. Apparently you believe that some users do not deserve the same rights to their copies of your software as others. While this is a common belief, I feel it is unfortunate and ill-considered.
Developer -> Distributor [-> Distributor ...] -> User
The BSD license grants rights from the developer to the first distributor in the chain. Other distributors, and the end user, are completely dependent on that first distributor to pass on the rights he received.
The GPL requires that certain fundamental software rights are passed down the chain. This ensures that a single ill-behaved distributor will not restrict the rights of the end user.
As someone who builds and uses tools for developers, BSD is thus more useful to me, because it grants the maximum freedom to the people I target -- myself, and other developers to whom I distribute BSD-licensed tools.
There is no need to pick a license to maximize your own rights -- by the nature of international copyright law, you already have all possible rights to your work. The difference is whether rights should be transmitted. Apparently you believe that some users do not deserve the same rights to their copies of your software as others. While this is a common belief, I feel it is unfortunate and ill-considered.
Apparently you believe that some users do not deserve the same rights to their copies of your software as others.
Well, they can still get the software directly from me - regardless of what Company A does to it. BSD won't guarantee that Company A doesn't do anything "bad" and apply restrictions to what I've created, but it does guarantee that anyone can get -my- software from -me-.
Well, they can still get the software directly from me - regardless of what Company A does to it. BSD won't guarantee that Company A doesn't do anything "bad" and apply restrictions to what I've created, but it does guarantee that anyone can get -my- software from -me-.
Except, company A's modification is a port to a platform with secret specifications. Neither you nor I have the time to reverse engineer it.
"Apparently you believe that some users do not deserve the same rights to their copies of your software as others."
You do realize that if someone who gets a copy of my BSD-licensed software wants to lock it up and put it under horrific restrictions, people can still get a copy of it, under a permissive license, from me?
And, really, that's how I prefer to solve that problem. Sure, somebody might build a derivative piece of software and not open it up, but I don't feel like it's my place to dictate to them how they have to license their own software.
But then I don't really look at open-source license terms as a moral issue; the fact that I'm a license pragmatist should be pretty clear from my original reply.
You do realize that if someone who gets a copy of my BSD-licensed software wants to lock it up and put it under horrific restrictions, people can still get a copy of it, under a permissive license, from me?
And, really, that's how I prefer to solve that problem. Sure, somebody might build a derivative piece of software and not open it up, but I don't feel like it's my place to dictate to them how they have to license their own software.
But then I don't really look at open-source license terms as a moral issue; the fact that I'm a license pragmatist should be pretty clear from my original reply.
The philosophical reason to use the GPL, rather than the BSD or MIT licenses, is to ensure that users have certain rights to the software they use.
What rights do software users benefit from with GPL licensed software that they do not with BSD licensed software?
You seem to make the point a couple of times that the GPL is more free and gives more rights to users.. could you elaborate on that as, to how I see it currently, little is more free than the BSD license except the public domain. The GPL places all sorts of restrictions on users if they choose to modify the software.
What rights do software users benefit from with GPL licensed software that they do not with BSD licensed software?
You seem to make the point a couple of times that the GPL is more free and gives more rights to users.. could you elaborate on that as, to how I see it currently, little is more free than the BSD license except the public domain. The GPL places all sorts of restrictions on users if they choose to modify the software.
You're confused about who the user is in this discussion.
The user is the end user of software, not the developer who is using your code. GPL protects the rights of end users, no matter how many developers sit in between the original code and the end user.
In other words, as an end user, if I'm using a GPL program, I know that I can access the source code and fix anything I need to or change anything that needs changing.
To be as specific as possible, in what I described, you don't count as a developer until you actually take your changes and give them to someone else, so distributor may be a more accurate term.
The user is the end user of software, not the developer who is using your code. GPL protects the rights of end users, no matter how many developers sit in between the original code and the end user.
In other words, as an end user, if I'm using a GPL program, I know that I can access the source code and fix anything I need to or change anything that needs changing.
To be as specific as possible, in what I described, you don't count as a developer until you actually take your changes and give them to someone else, so distributor may be a more accurate term.
Software under the BSD license may be given to a user without providing the corresponding source code, effectively preventing the user (or an agent authorized by the user) from modifying their copy of the software.
Releasing software into the public domain is tricky.
I don't know a good way to do that, without running the risk that big company M will take the software, get a patent on it, and then sue me for writing my own software. Disclaimer: this is an over-simplification.
I wanted to point out that simply releasing code into the public domain can bite back. I use the MIT license because it's as close as possible. The BSD license has too much baggage due to that stupid advertising clause in the old 4-clause version.
I don't know a good way to do that, without running the risk that big company M will take the software, get a patent on it, and then sue me for writing my own software. Disclaimer: this is an over-simplification.
I wanted to point out that simply releasing code into the public domain can bite back. I use the MIT license because it's as close as possible. The BSD license has too much baggage due to that stupid advertising clause in the old 4-clause version.
> GPL is a better route because commercial entities that want to use your software now have to get the commercial license
They can use your software all they want. They just can't link to it or otherwise tightly integrate it with theirs (the line is a fuzzy one, but generally drawn at linking, IIRC)
They can use your software all they want. They just can't link to it or otherwise tightly integrate it with theirs (the line is a fuzzy one, but generally drawn at linking, IIRC)
[deleted](2)
The BSD license allows someone to take the code, improve it, and not share the improvements, which may sometimes lead to fragmentation. This happened in the Wine project, where some companies used the free Wine code and added closed improvements. Improvements to Wine were merged to the closed product, but improvements to the closed product could not be used by Wine. The licence of Wine was changed to the LGPL to stop this.
As a small Mac developer, I respect the GPL, but I don't always get it.
For example we created a GUI subversion client for the Mac that is pretty popular. I'm sure that it gave subversion usage on the Mac a boost as now more people can actually use it (half of our customers are not programmers). So our application actually stimulates the usage of subversion, which can't be bad for anyone involved.
We get a lot of questions wether we can also make a Git/Mercurial client, but the GPL makes that really hard as we would have to wrap the command line or make an open source communication library. Now, if the GPL GUI applications were as great as the commercial ones, there wouldn't be a problem. But for reasons I'm not sure about that doesn't seem to be the case.
For example we created a GUI subversion client for the Mac that is pretty popular. I'm sure that it gave subversion usage on the Mac a boost as now more people can actually use it (half of our customers are not programmers). So our application actually stimulates the usage of subversion, which can't be bad for anyone involved.
We get a lot of questions wether we can also make a Git/Mercurial client, but the GPL makes that really hard as we would have to wrap the command line or make an open source communication library. Now, if the GPL GUI applications were as great as the commercial ones, there wouldn't be a problem. But for reasons I'm not sure about that doesn't seem to be the case.
Hey Koen!
From the perspective of a person who chooses the GPL license for their code, the issue is that they want to the right to take your changes and then modify them as they see fit.
The GPL prefers that right over everything else, including overall use of any particular program or library. GPL advocates would suggest that it is in fact bad that you've increased the use of subversion, because you've done it in a way that all those new users can't go in and fix bugs in your program, or change some behavior that they feel needs changing.
I think one of the reasons people fail to understand this argument is that they see a complete disconnect between end users and developers. In other words, an end user is someone who will never even want to edit source code. I'm inclined to think this is usually true, but the authors of the GPL are the exception to that rule, and it is one of the primary reasons that the GPL exists.
As far as the git client is concerned, wrapping the command line, as you suggested, basically solves the problem. It's also probably not that hard. In fact, there are a couple ruby libraries that do it I believe, and maybe python ones as well, if you're still doing PyObjc.
From the perspective of a person who chooses the GPL license for their code, the issue is that they want to the right to take your changes and then modify them as they see fit.
The GPL prefers that right over everything else, including overall use of any particular program or library. GPL advocates would suggest that it is in fact bad that you've increased the use of subversion, because you've done it in a way that all those new users can't go in and fix bugs in your program, or change some behavior that they feel needs changing.
I think one of the reasons people fail to understand this argument is that they see a complete disconnect between end users and developers. In other words, an end user is someone who will never even want to edit source code. I'm inclined to think this is usually true, but the authors of the GPL are the exception to that rule, and it is one of the primary reasons that the GPL exists.
As far as the git client is concerned, wrapping the command line, as you suggested, basically solves the problem. It's also probably not that hard. In fact, there are a couple ruby libraries that do it I believe, and maybe python ones as well, if you're still doing PyObjc.
LGPL would be a good choice for something like Git, so you can still use it in proprietary software, but any improvements to Git itself must be contributed back.
What's wrong with wrapping the command line?
> We get a lot of questions wether we can also make a Git/Mercurial client, but the GPL makes that really hard as we would have to wrap the command line or make an open source communication library.
Couldn't you re-implement the GIT spec (including making such a spec if it does not exist now)?
Couldn't you re-implement the GIT spec (including making such a spec if it does not exist now)?
Incidentally, that is how github works, if I'm not mistaken; the 'grit' library (http://github.com/schacon/grit) does as much as possible in pure ruby, falling back to command-line if necessary.
It's also licensed under the MIT license, so you could use it in your Cocoa app using MacRuby or whatever.
It's also licensed under the MIT license, so you could use it in your Cocoa app using MacRuby or whatever.
Sure, they could, but it would take time away from the interesting features of the application and the user interface (see: http://versionsapp.com/)
I've done a little bit of open source work (a few small numerics libraries and the beginning of a small project in PHP) and I always release my stuff under the BSD license. To me, the GPL just doesn't seem 'free' (to reiterate what embeddedradical said earlier).
All of the stuff I've written has just been to fill a small hobby and because the only offerings out there were all expensive non-free libraries that I couldn't afford to pay for (not for a hobby, anyway).
I seem to remember that the very bottom of the networking stack in Windows was (and may still currently be) based on a BSD sockets implementation. If Microsoft had implemented their own methods from scratch, who's to say that things would be as compatible as they are now?
I respect that some authors want recognition (or perhaps a job) as a result of the hard work they put in (for free) on a lot of open source projects. But I think software is much more useful under a license that allows people to do whatever they want with it, commercial or otherwise.
All of the stuff I've written has just been to fill a small hobby and because the only offerings out there were all expensive non-free libraries that I couldn't afford to pay for (not for a hobby, anyway).
I seem to remember that the very bottom of the networking stack in Windows was (and may still currently be) based on a BSD sockets implementation. If Microsoft had implemented their own methods from scratch, who's to say that things would be as compatible as they are now?
I respect that some authors want recognition (or perhaps a job) as a result of the hard work they put in (for free) on a lot of open source projects. But I think software is much more useful under a license that allows people to do whatever they want with it, commercial or otherwise.
Every once in a while that a similar license discussion emerges, I see a clear pattern:
Many,many people do not understand the GPL.
In my opinion, this is the major drawback of the GPL: It's complexity. I've read it a dozen of times and still I'm not sure about some corner cases.
This leads to
a) Programmers who are not willing to use it and prefer a much simpler license, such as BSD.
b) To people spreading misinformation about the GPL that already worsens this situation.
Many,many people do not understand the GPL.
In my opinion, this is the major drawback of the GPL: It's complexity. I've read it a dozen of times and still I'm not sure about some corner cases.
This leads to
a) Programmers who are not willing to use it and prefer a much simpler license, such as BSD.
b) To people spreading misinformation about the GPL that already worsens this situation.
The fact that Zed wrote Mongrel and got no recognition is possibly an indictment of several things: the RoR buzzstorm, the Rails community, the “OMG Ruby is the new Java for Web 2.0″ technorati, maybe even venture capitalists. But it is not an indictment of the BSD license.
Here's where I stopped reading.
Here's where I stopped reading.
Could you expound why? I had a boss who hadn't written a line of code in his life ask me if we were using RoR around 2006...
Edit: what I mean to say is that the author is correct that there was a lot of baseless Ruby fanboyism.
Edit: what I mean to say is that the author is correct that there was a lot of baseless Ruby fanboyism.
And?
Short answer: because life's too short to read an essay about software licensing that appears to be shot through with commentary about the failings of the Ruby/Rails community. Am I wrong, and there was no RoR commentary after that graf? Oh well.
Short answer: because life's too short to read an essay about software licensing that appears to be shot through with commentary about the failings of the Ruby/Rails community. Am I wrong, and there was no RoR commentary after that graf? Oh well.
Yeah, myself as well. I don't understand this bitterness that comes from the Python community. Or maybe, it's just a vocal minority. There was no need for this in the article.
Can you please point out the parts of my blog entry that are "bitter"? Or was that one line - whose sole purpose was to mirror and acknowledge Zed's colored history in the Ruby world - enough to paint me as a "bitter" person?
Zed's "colored history in the Ruby world" is not relevant to your discussion of BSD vs GPL licenses. It feels like you put it in just to stick it to those "awful" Ruby people.
Also, your response to my comment doesn't improve or change my opinion of the article. Without that part there, it would've been a perfectly acceptable advance of the discussion of the two license systems. As it is, it damages the your argument.
Bitter maybe too harsh a criticism, but since you've chosen to put the irrelevant paragraph that made a side-comment on the Ruby community in an article about OSS licenses, you've pretty much opened yourself up to it.
Also, your response to my comment doesn't improve or change my opinion of the article. Without that part there, it would've been a perfectly acceptable advance of the discussion of the two license systems. As it is, it damages the your argument.
Bitter maybe too harsh a criticism, but since you've chosen to put the irrelevant paragraph that made a side-comment on the Ruby community in an article about OSS licenses, you've pretty much opened yourself up to it.
I've never been in a situation where dual licensing was applicable, but when I give away software, I usually paste in the MIT license. I figure - if it's going to be free, it should be completely free.
Maybe if I thought the GPL license stood a chance to ever make it so that all software, or at least the majority, was free and intellectual property was dead...then I would use it - but to try and make such a giant philosophical/political change just in the software industry appears naive.
If intellectual property is what we want to get rid of (the philosophical reason to go with GPL rather than BSD), it should be addressed as a whole: looking at it in sciences, software, literature, all of it -- for if it is true that we don't need it, or are hampered by it, I don't see how it only applies to software. I'm far more concerned that companies are patenting found genetics than I am that this stupid iphone which erased all my music this morning because I had recently formatted and it thinks it was synced to another computer, and how the new firmware breaks it from musicmonkey again, and now I can't transfer my flac files, and have to use their junky itunes instead -- yah it sucks, but the genetic stuff is even more troublesome - philosophically.