I Love the GPL (Except When it Applies to Me)
teddziuba.com
teddziuba.com
With all other FOSS licenses, it's lazy bullshit to use them in the LICENSE field of your installer maker -- I absolutely do not have to accept the terms of the GPL to use your software, it's right there in the text of the license, so don't you dare make me click an 'I accept' checkbox.
With the AGPL it's absolutely necessary to do this, because I don't actually have The freedom to run the program, for any purpose
The RMS of twenty years ago would have never approved of such a thing, that he has lent it the imprimatur of the FSF now is testament to his intellectual bankruptcy.
The AGPL will never ever succeed. It will only ever be used by egotistical idiots and dying companies that wish to sear a scarlet letter into their code -- noone but I may profit directly from this work -- as you still retain copyright by default. Is the AGPL transitive across the network the way the GPL is by linking? It seems to me like either answer would show how poorly considered it is as a license.
The RMS of twenty years ago would have never approved of such a thing, that he has lent it the imprimatur of the FSF now is testament to his intellectual bankruptcy.
Is the AGPL transitive across the network the way the GPL is by linking?
From my non-lawyer reading of the AGPL, it does transit between processes and systems because it covers the output of the application.
Virtually every piece of commercial closed-source software is distributed under terms that are strictly more restrictive than the AGPL, and the AGPL's objectives are --- unlike those of commercial vendors --- benevolent.
Finally, licenses aren't in competition. They're just tools. You use the one that supports your objectives.
I also don't understand how the AGPL's objectives are "benevolent" when the primary purpose of those objectives as applied by commercial interests is to ensure a revenue stream via commercial license.
You yourself said: "GPL-style licenses make it harder for competing companies to use your code. GPL is therefore an easier sell inside of a company."
How is that benevolent? (charitable, intending or showing kindness).
You and I may be arguing at cross-purposes. You seem to care a lot about the hardships licenses create for software users. I couldn't care less. I think it's an inherently benevolent thing for a software author to give away her code for free, and if she wants to do that under a strict copyleft... her code, her terms.
The objective of the AGPL is reasonable. "Don't use my code in closed-source applications". As a developer, that term has been annoying on many occasions (shudder readline), but it has never seemed unfair.
I don't think either applies. The GPL is primarily useful as a means to maintain a very specific business model that relies on selling commercial licenses. There's nothing moralistic or benevolent or "fair" about it -- it's simply business.
The only moral argument I could possibly make is that it's disingenuous if not outright hypocritical to claim that the GPL is about "freedom" when its used as merely a business tool that leverages the closed-source work of others to fund ongoing development.
Remember, people can still compete with GPL/AGPL software. They just have to do it with open source code.
Finally, your third graf is profoundly disingenuous. Most GPL software is noncommercial. Everything we use to post on HN is traceable in some way back to GCC, which isn't making money for anyone.
I'm not sure I understand your use of "strictly better" here. If my goal is to solve a specific problem, then isn't the software that solves that problem the best strictly better software?
As far as benevolence, why ascribe primarily altruistic motives to clear business decisions? MySQL's use of the GPL allowed for pervasive adoption, which increased demand for commercial licensing and support services.
Finally, your third graf is profoundly disingenuous. Most GPL software is noncommercial. Everything we use to post on HN is traceable in some way back to GCC, which isn't making money for anyone.
How do you think GCC development is paid for? Just take a look at the (closed source, proprietary, et al) companies providing the primary funding ongoing GCC development (although many are moving to or looking at LLVM, since its licensing provides a better model for this sort of shared OSS funding).
It always comes down to money and either commercial interests or government funding.
The business benefits of the GPL are so compelling that I don't think they need my cheerleading. If I write 50,000 lines of C code, and you want to stick that code in your $10,000 software package and not pay me a dime, the GPL (for the most part) keeps you from doing that. Total win.
Actually, I think "users" should pay for software as that's all they're able to contribute, and I don't think that the GPL dual-licensing model users by some enterprise vendors can actually work for most consumer software.
If I produce developer-oriented software that's outside of our core business -- but perhaps enables our core business -- I am very likely to release it under the MIT/BSD license to help aid in wide adoption and external contribution from funding business interests.
If I produce software that is our core business, then I won't MIT/BSD license it. I might GPL it, but only if there's a clear value (ie, leveraging the 'open source' name, aiding in widespread adoption by hobbyists while targeting enterprise users, etc) in doing so.
The business benefits of the GPL are so compelling that I don't think they need my cheerleading.
The benefits are only compelling for --some-- business models. And this doesn't disprove the author's point.
As for other business models, especially around commoditized software, the BSD license often provides the most compelling business benefits as corporates are free to pool resources on code they are free to link against without having to release the entirety of their products under a copyleft license.
Another important point, the AGPL or GPL license is applicable (not at the execution) only when you are distributing (conveying) the software. The AGPL is just an extension of the distribution nothing to do with the execution of the software.
diff -u gpl-3.0.txt agpl-3.0.txt
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
+ GNU Affero General Public License for more details.
- You should have received a copy of the GNU General Public License
+ You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
- If the program does terminal interaction, make it output a short
-notice like this when it starts in an interactive mode:
-
- <program> Copyright (C) <year> <name of author>
- This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
- This is free software, and you are welcome to redistribute it
- under certain conditions; type `show c' for details.
-
-The hypothetical commands `show w' and `show c' should show the appropriate
-parts of the General Public License. Of course, your program's commands
-might be different; for a GUI interface, you would use an "about box".
+ If your software can interact with users remotely through a computer
+network, you should also make sure that it provides a way for users to
+get its source. For example, if your program is a web application, its
+interface could display a "Source" link that leads users to an archive
+of the code. There are many ways you could offer source, and different
+solutions will be better for different programs; see section 13 for the
+specific requirements.
You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
-For more information on this, and how to apply and follow the GNU GPL, see
+For more information on this, and how to apply and follow the GNU AGPL, see
<http://www.gnu.org/licenses/>.
-
- The GNU General Public License does not permit incorporating your program
-into proprietary programs. If your program is a subroutine library, you
-may consider it more useful to permit linking proprietary applications with
-the library. If this is what you want to do, use the GNU Lesser General
-Public License instead of this License. But first, please read
-<http://www.gnu.org/philosophy/why-not-lgpl.html>.The AGPL is only an extension of the distribution constraints as far as the strings embedded in the program are covered by copyright. It can't use distribution as an enforcement boundary for the code, which never gets sent to the user.
The AGPL has everything to do with the execution of the software. That is its entire purpose! I am not allowed to run the software unless all parties providing it input can get its source, with an advertising clause. Anyone bound by the license does not have Freedom Zero.
Regarding the "enforcement boundary", the AGPL is more there to not abuse the "private use" ("not conveying") of a free software as described here :
http://www.gnu.org/licenses/gpl-faq.html#UnreleasedMods
In AGPL, You can run the software but if you make it accessible to end-users via a public network in a interactive way, this is considered as conveying.
I know someone who has a small AI + semantic web company, they use the AGPL, and I think that they are doing OK. The trick is selling a "commercial use" exception.
Also, my understanding is that if you use AGPL code in a web service, then you need to make the entire web service implementation AGPL. However, other systems that use the newly created AGPL web service do not need to be AGPL - if I am wrong about this, I would appreciate being corrected.
$ wc -w isc apache
192 isc
1395 apacheNow, I'm an open-minded child of the modern age and I don't agree with the oppressive old-fashioned idea that every essay must have a point. And truthfully this piece does bring up some interesting food for thought (the SaaS loophole). But it is nothing we haven't heard before, with less juvenile tone.
That might also be my own bias showing.
I'm sure Stallman and the like who have given their whole life to free software will appreciate. Meanwhile, this guy hasn't done much and yet not only complains about free software while using them but also calls them lazy at the same time. Shameless.
You use the BSD license when you don't care about the commercial value of your code. But, for the most part, I think using the BSD license means you're not going to care about the commercial value of your code, because if it's valuable, people will freeload.
In my industry, the GPL has done a servicable job protecting some key software projects (Snort, Nessus, Wireshark). The counterexamples (notably Metasploit) are utterly dependent on the continued effort of the original authors --- Metasploit goes stale faster than almost any other security tool.
It's also better for software contributors who want to leverage the code in their own products, and use the resulting revenue to contribute back their changes (but not their entire product).
But, for the most part, I think using the BSD license means you're not going to care about the commercial value of your code, because if it's valuable, people will freeload.
Some people will free-load. Many won't. Look at the Apache project, where a vast majority of development is funded by corporations using the software in their closed source products while contributing improvements back to the original product.
In my industry, the GPL has done a servicable job protecting some key software projects (Snort, Nessus, Wireshark).
How do you define "protecting", and what evidence would you use to demonstrate that protection? What would you say those projects were protected from?
This is simply business, not ideology. In terms of ideology, I think there's a simply check for whether Sourcefire meets the criteria of "I love the GPL. Except when it applies to me": Sourcefire could not ever include anyone else's GPL code in their own product without breaking their business model.
From my vantage point, it's the people who produce interesting and valuable code whose interests should come first. Companies who reallllly want to use that code in their for-profit endeavors can buy a license or build their own replacement or open their code; I don't care.
That sounds almost as ridiculous as someone saying:
"You use the GPL license when you want to scare off anyone else interested in using your code."
Seriously, though, there are a dozen examples with the code that runs GitHub to dispute your statement.
Any encouraging of upstream communication comes from the difficulty of keeping up with a fork and the knowledge that most code is a liability not an asset. The GPL only pushes you that way indirectly.
Of course there is the other side of the coin where I haven't used a library I really wanted to use because I couldn't GPL my app.
It hasn't won in the market place -- and it won't -- primarily due to the fact that the coupling between funding and licensing is so indirect -- it's very difficult to earn a high margin on writing GPL licensed code, and most revenue models require an indirect and complex approach to earning money from the software without charging directly for the software itself.
(Yes, you can charge for GPL software. No, that's not a sustainable business model. No, RedHat is not a counter-example. RedHat charges for support and their trademarks, not the software itself, and in doing so appeals to a very specific niche enterprise market.)
http://news.ycombinator.com/item?id=211736
Red Hat is a cop-out example. Why not talk about SourceFire, Sleepycat, Splunk, Hyperic, Zimbra, and Astaro? These are all companies that sell software, GPL their code, and are (or were, before lucrative aquisition) extremely successful. SourceFire IPO'd off their GPL package; the company's name comes from the fact that they're open source.
All selling services and products around a very specific type of software, selling to a very specific market niche, leveraging both trademarks and non-GPL licensing to do so.
They're not selling the GPL software itself.
Take your Sourcefire example. They fund development by selling proprietary hardware and proprietary licensed IDS rulesets under trademarked names to an enterprise market niche.
It's also not true that all successful open-source companies sell to enterprises. Tenable sells Nessus to consultants. Sleepycat sold Berkeley DB to OEMs and developers. Automattic certainly doesn't sell Wordpress to enterprises.
Enterprise services.
The fact that they're also not actually selling GPL software (ie, an indirect business model), this all doesn't really disprove my point -- or the original authors.
The patent / IP language in the GPLv3 still scares a lot of larger companies, my employer included. It's in Blackduck's commercial interest to present information in a way that exaggerates the prominence of that family of licenses. Thus, the chart is of the number of projects released under that license, and does not take into account the maturity or market penetration of a project. For instance, a new entry on Sourceforge with nothing but a README in its repo would be included in Blackduck's count.
That's not to say Blackduck itself is all bad, mind you. I've sat through a few Continuing Legal Education webinars that they've hosted, and they've all been quite objective and accurate. In each case, they brought in fairly prominent figures from the Open Source law space (Karen Copenhaver, Mark Radcliffe, etc) for the sessions.
One problem with the AGPL is that it seems to work for projects that are totally owned by one individual or company because there is a clear stratgey for supporting alternative commercial use licenses with no software distribution requirements. If alternative use licenses are low cost for received value and if the commercial license passes corporate lawyer scrutiny, all is good.
The big problem with the AGPL is projects with multiple contributers - makes a paid for commercial license difficult.