tentonova
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.
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.
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'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.
Well -- I for one am happy with the licensing status of Mac OS X, and think I've received a perfectly fair trade.
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 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.
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.
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 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).
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)
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.
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.)
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.
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.
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?
No.
... if you want your build to be deterministic, and of course you do, you still have to specify bar and baz explicitly
If you declare a dependency on non-snapshot foo, then it will also declare a dependency on non-snapshot bar, ergo, reproducible build.
Your comments seem to be the standard "I don't understand Maven, but I hear that it's broken."
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.
His "over-commented" example is clearly extreme hyperbole.
His under-commented counter-example is extremely poorly commented code which fails to explain the "why", ensuring that nobody can make sense of the code path without actually stopping to read the entire expression and possibly the expressions to which it refers.
I've yet to work with anyone outside of an undergraduate class that over-commented their code.
It takes effort to over-comment code, and those that do are invariably writing both poor code and poor comments.
A much more prevalent malaise is that of developers with an unduly high opinion of their code's readability grossly under-commenting their code. This increases the long-term maintenance overhead and sometimes leads to forced rewrites by follow-up maintainers (which may be the author himself).
Maven is declarative, not imperative.
Ant is broken in many respects, but your provided example is not true. Ant only attempts re-encoding of a file if you specify text filters (aka variable/string replacement). It shouldn't be a surprise to anyone that string replacement breaks on binary files.
Why didn't you have the descriptor files? Optimizing for ease of external reverse engineering seems rather counter to the authoring organization's actual goals.
If you want third parties to be able to interoperate, give them the descriptors you use.
As for parsing, I guess I don't get what the big deal is.
Writing lots of code to read and parse data types as text, especially when no schema is available, is time consuming.
Protobuf is necessarily validated. The input types are known-correct, conversion to the domain model is direct and straight-forward, and it's exceptionally easy to generate code or otherwise automatically deserialize to native representations.
It's not non-deterministic if your dependencies include an explicit version. You should not be using unversioned -SNAPSHOT dependencies for release builds.
And if I want my dependencies to be preinstalled rather than checked in and bundled, I'd rather use yum so the rest of the world can reuse them too. Does Maven even support dependencies upon native (non-JVM) apps and libraries which are available for a given platform?
No. Maven is intended to support easy-to-use bundled code dependencies, not to operate as a complete replacement UNIX packaging system.