You're introducing a logical non-sequitur. That there is a niche isn't the issue, it's what the niche is.
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.
I think you and I are wasting time. You care about making things easier for software users. Software users don't make more software; software authors do.
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.
I'm not sure what your point is, or how it counters the author's original point, which is that what's good for the goose is very much not good for the gander.
Why not talk about SourceFire, Sleepycat, Splunk, Hyperic, Zimbra, and Astaro
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.
I agree that the GPL is primarily useful as a vehicle for making money off software that is also released as open source. Since open source commercial software is strictly better than closed source commercial software, I don't have a hard time using words like "benevolent" to describe that practice
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.
You're arguing that users don't believe the current situation is a fair trade, and would rather enter into a GPL quodque pro quo agreement if they were not restricted by the purchasing department?
Well -- I for one am happy with the licensing status of Mac OS X, and think I've received a perfectly fair trade.
As I said below, I'm surprised by the emotional arguments engendered in your word choices -- "fairness", "benevolence", etc.
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.
I'm surprised at the appeals to emotion engendered in your word choices -- "fairness" and "benevolence".
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.
The only freedom GPL denies a developer is to close up software that was once free.
You can't "close up" software that was free. The software remains free.
The only freedom the allegedly "more open" licenses give developers is to deny freedoms to their users.
It gives developers the freedom to create an aggregate product without also releasing their own code under the GPL, allowing them to pursue a business model that they feel will fund the ongoing R&D necessary to produce that product.
For the users (and software freedom is about them), those licenses give nothing.
If users do not feel that a product does not provide a fair trade, they are under no obligation to purchase or use it, and the original code remains to do with what they will. However, as indicated by vast market success, users do feel that these licenses and the products produced using them do provide something of value.
Yes, the BSD license sure is better for software users.
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?
I'm not sure how I understand how a commercial license is "strictly more restrictive" than the AGPL, which requires that you also release your code under the AGPL. Whether or not it's "strictly more restrictive" rather depends on whether you want to also release all the source to your own code as well.
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).
I'm firmly disagree with Monty's duplicity, but I'll try to shed some light on it.
The "big deal" is that only two things provide a revenue stream around MySQL sufficient to support the heavy R&D costs associated with building a database product:
- The name ("MySQL")
- The copyright.
If you own the name, you can sell branded binaries and services. If you own the copyright, you can sell non-GPL licenses to commercial interests. Without these, creating a viable revenue stream is incredibly difficult.
In contrast, as a company looking to use and contribute to open-source software, BSD licensed code is an easier sell because you aren't locked to purchasing a commercial non-OSS license from the copyright holders (see: Oracle/Sun/Monty regarding MySQL).
Subversion 1.5, released in June of 2008, supports merge tracking.
If you're using the limitations of your VCS to manage team communication then you have bigger problems.
A simple but sufficiently powerful solution leads to simplified communication. If you're using the complexity of your VCS to hinder team communication and support cowboy coding, then you have bigger problems.
Frankly, a lot of the arguments against DVCS smack of the same sort of ignorance that the Java zealots were leveraging against Ruby back when Rails started picking up steam in 2005/2006 ... But I think the past few years have borne out the fact that mediocre and merely-competent programmers can make strong use of these tools without leading to disaster.
Nobody (intelligent) said there'd be disaster because of the "powerful features", just that operating in that manner would be more expensive than the much simpler alternatives.
Expending more effort with more powerful tools isn't actually an improvement, it's just busy-work -- constantly working on your muscle car instead of driving it.
My reading was that he was presenting the GPL as an inherently flawed dream unable to survive in the reality of the economic marketplace. In succeeding in market adoption, the proliferation of the GPL actually leads to its own failure due to its knocking the legs out of most of the higher-margin business models required to fund the R&D necessary to produce software.
The GPL was invented to leverage network effects to win in the market place, ensuring an exceptionally high entry barrier to non-GPL market entrants (a natural monopoly) should the GPL be successful in this goal.
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.)
You should consider partnering with (or contracting out) to someone already well familiar with OS X and interested in writing a GUI.
Tarsnap has one of the technically best back-end implementations available, but the barrier to entry for an interested customer is incredibly high -- not just on OS X, but on UNIX as well.
Even on UNIX, producing a working backup setup requires writing custom scripts to do so, and implementing anything like snapshot-based backups is complicated enough that even I spent a couple hours getting everything working/tested, and I'm very familiar with this area.
I'll be bold: You solved the backup problem, now the number one hinderance to your growth is solving the user experience problem.
The UNIX utility should have an exceptionally easy way to configure backup schedules. Possibly even an optional web UI.
A Mac release must have a native OS X GUI (no qt!), be easy to use/configure, and be well-integrated into system services.
After the first iteration on the above you should consider implementing support for network-based backup administration, so that we can control backups/restores across all of our desktop/server installations from a centralized administration console.
If the above is not your forte -- if you're only interested in the crypto and backup issues -- then you need to find a parter or contractor who can step in and solve them for you.
In subversion, yes, you don't go through the hassle of creating a branch for all these reasons.
svn cp ^/trunk ^/branches/tentonova-bugfix-x
svn co ^/branches/tentonova ~/branch
I wouldn't call this a technical "hassle", and I'm not sure what organizational issues would arise here.
The vast majority of branches are never seen by more than one developer, they are simply an organizational tool to be used at your discretion without imposing any overhead on anyone unless you have good reason to.
Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication.
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.