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.

What GPL prevents that BSD doesn't is closed forks. Obviously some people don't care about closed forks --- some people may even like them on principle --- or nobody would BSD-license anything.

It's far too common that the person who assigns value to software and that signs the check is not the same person who puts it to work.

Well -- I for one am happy with the licensing status of Mac OS X, and think I've received a perfectly fair trade.

My wife had to build an intranet on top of Sharepoint because a PHB said so. I have to read my e-mails off an Exchange server because corporate IT finds it nice. Far too many servers are Red Hat while I would prefer Debian (I am a fan of APT). Perhaps you have to make your presentations on PowerPoint for Mac, even knowing how much better they would look with Keynote. Life's not perfect.

And, while I love the NeXT side of OSX, I find the Unix side far too early 90's for my taste ;-)

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.

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.

I think this ties into this discussion, as well: http://news.ycombinator.com/item?id=1028638 -- I Love the GPL (Except When it Applies to Me)

Yes, and Monty knew that when he chose to structure MySQL the product that way. Everything is proceeding exactly as he foresaw and intended.

On the other hand, if I thought my project was going to be a cash cow, I would have done exactly what Monty did, except the whining after the fact. I think if I buy a car, then sell it to someone and that person sells it later to my arch nemesis for a discount and he plans on wrecking the heck out of it, my screaming about how this is not right is not going to attract many supporters, is it?

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.

That might also be my own bias showing.

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.

But I have no doubt the reason while your revenue doesn't make you happy yet it is because hackers are not the right target for it. I do differential backup using encFS and dropbox; it's not even remotely as cool as tarsnap but it's free for now. You see my point?

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.

I agree 100% -- and this was exactly my intention. I wanted to make sure that I had a solid backup system in place before I made it easy to use, because I hear far too many nightmare stories about backup software which is the opposite way around -- easy to use, but doesn't actually work.

A GUI will happen. Sample cron jobs for automating backups will happen. A web interface... well, that might happen, but really it needs to be built in to something like virtualmin.

I've always worked to constrain non-linear development to the absolute minimum required because the technical costs are easily dwarfed by the human communication overhead and inherent organizational complexity engendered in multiple disparate branches of development.

What you're talking about seems to be multiple, long-running development or release branches. Those are hard to manage and generally a bad idea in any VCS. But, with a system like Git, you don't tend to have long-lived divergent development branches. Typical branch lifetimes are more like hours or days, rather than weeks or months. There are exceptions, but by-and-large, branches are just used differently in git.

I've worked with both git and hg.

There is no "inherent organizational complexity" in me having a private branch that I share with no one and which is only used for an hour or two while I work on a critical bug fix.

What's the value of this private branch beyond simply committing to the actual branch?

If it's just a bug fix, how big can it be?

If it's more than a bug fix, why am I hiding this code from the team by implementing it on a private, local, non-backed up, non-code-reviewed, non-centralized branch?

Typical branch lifetimes are more like hours or days, rather than weeks or months. There are exceptions, but by-and-large, branches are just used differently in git.

Why wouldn't I just commit this work incrementally to the actual upstream branch, rather than hiding it for "hours or days" from the rest of the team?

To quickly comment on a couple of your other concerns, my local hard-drive is backed up, so that's irrelevant; and I personally feel that code review at the level of individual commits has very little value, and you should instead be reviewing complete feature implementations.

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.

Merging.

Hiding your development branches on a shared codebase often incurs either communication overhead, or the costs of lack of communication.

If you're using the limitations of your VCS to manage team communication then you have bigger problems. The obvious analog to the "problem" you mention is people not checking in code because it's not ready yet. Maybe you think this is better because you only want deployable software in your main branch, but for large features that makes the history opaque and leaves your developer effectively without any of the benefits of version control while they are working on the large feature.

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. There's this fear that powerful features will lead to chaos and are in effect too powerful to be used safely. And the reality is that yes, in environments truly incompetent programmers work, there's definitely a strong argument to be made for limiting the damage they can do. 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.

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.

This is a blub attitude plain and simple.

Apparently the new svn:mergeinfo property helps, but we haven't migrated at work so I don't know how well.