open source doesn't necessarily mean "anyone can edit it and improve it".
patches and added features need to be reviewed by project owners.
open source mostly mean "you can read the source and modify your version, but that doesn't mean you can make a change that will go into the official release."
There are some very sensitive implementations of software which should be thoroughly examined by experts and criticized if they're not good enough. If there is no resources available to maintain a particular open source software, don't bother use it, ESPECIALLY if it's sensitive like openssl.
Open source allows software companies and other programmers to easily work together to solve a problem. Developer's time is precious so it's often time-saving to use somebody's else work, but that doesn't mean you should use it blindly.
You are correct, of course. But what the Heartbleed showed us is that even at the scale of OpenSSL (millions of users), almost all were using it blindly. People often care more about the free in pricing aspect more than the freedom to inspect, modify and contribute - because as you say, dev time is precious.
> open source doesn't necessarily mean "anyone can edit it and improve it".
I think you missed the point in the article - it was about how anyone can create or contribute to open-source. Not about submitting patches to existing projects and have them pulled upstream without any review process.
Proprietary code is subject to a market value, companies can actually invest in a codebase to improve it and add features, whereas open source is subject to common interests or volunteering. I agree that open source can increase quality thanks to the "community", but unless there is a community, nothing gets done. "there is no such thing as a free meal".
If you don't have the source code, it's actually a little harder to find a vulnerability since all you have is a big blob of binary assembly. Hackers can still find vulnerabilities with enough time on their hand, but it's still much discouraging.
I just think that invisible hand of the market is an equally virtual limit effect as the many eyes ensemble. The stream of closed-source vulnerabilities is also substantial and a time-to-fix is much larger there, what effectively pays for the additional effort required to identify a flaw.
No free lunch in security rather hides in the trade-off with convenience.
Generalizations about whether open-source developers or closed-source source developers have more resources, or are more professional, or whatever, are silly. The two groups of developers are very large with high variance in many dimensions, and a lot of overlap. There are open-source projects with one or 2 developers, and open-source projects that are the primary focus of $100-million, thousand-employee companies. There are also closed-source commercial projects developed by teams of hundreds, and closed-source commercial projects developed by a solo programmer when he's not busy answering customers' phone calls. Lots of developers work on both open and closed-source projects at one time or another.
It's important to discuss what changes we can (and should) make to make problems like heartbleed less likely in the future, but wildly waving competing generalizations in the air doesn't help anything.
What you say is true. The argument is still useful though. There are those that follow one at the expense of the other. This is no more useful than saying the only way to develop software is agile.
There has been a lot of really insightful hindsight about the heartbeed issue. This one seems to fall into the category of "we should of expended more resources on such a critical piece of infrastructure", where resources could of been time, attention or money. That is true, but not really very helpful.
This particular observation comes up any time something goes wrong in any context. The stuff about the shallowness of bugs really has nothing to do with the argument. This bug was in fact quite shallow, some random entity just found it by looking. If more people had of been looking then it would of likely been found sooner. You can only find a bug once.
"you cannot expect a person working in academia to be held to the same standards as professionals working in the industry for many years"
This is absolutely BS, especially in security and cryptography. Most security related code written by most so-called "professional" software developers is astonishingly terrible (e.g. ECB mode encryption, storing encryption key in code, reusing encryption keys, relying on (unauthenticated) encryption for authenticity, reusing IVs, linear time MAC verification, ...). Most cryptographers are academics. Also, anecdotally, the poisonous "demo an exploit or it doesn't happen" attitude in response to hints at a flawed system design is much more prevalent among "professional software developers" than in academia.
If anything, we should encourage more security experts in academia to engage in implementation, verification, and improvement of security code, not the other way around.
(Not that most academics write good code either, but this is not an academia/industry issue. It is a security expert/non-expert issue.)
Isn't the problem that cryptography, solid protocol design and secure software development are actually almost unrelated disciplines that just happen to overlap in some applications?
I don't see why an OpenSSL developer would need either of the first two skillsets at all. Ideally, yes, but not necessarily.
I disagree with the premise of your question. I think the overlap is larger than it looks like on the surface. I have come to believe that you cannot do solid secure protocol design without a firm grasp of the basics of encryption schemes. You don't need to be a full fledged cryptographer, but to quote Phil Rogaway, "Reading [Schneier] does not qualify one to do cryptographic design." [1]. In fact, the context in which he wrote "Problems with Proposed IP Cryptography"[1] is a perfect evidence of this: IETF committee designing IPsec, back in 1995, which I think is fair to think of as mostly "professional software developers", was clearly warned about potential consequences of some of their design choices[2] (like using Encrypt-then-MAC), but they reacted quite harshly to his comments and did not take them as seriously as they should have, and actual attacks were demonstrated on those issues years later[3]. For me, reading the mailing list is enough evidence that it is very dangerous to draw the line between secure protocol design and other things. Similarly, I believe the lack of understanding of the reasons behind design choices in a protocol specification will surface as implementation bugs done by purely "secure software development" experts (e.g. "optimization" of random data generation at the beginning of the protocol to use in place of an invalid input by reordering the operations leading to a timing attack in TLS). There is enough historical evidence that makes anything except the "ideal" case dangerous.
I'm not sure that you're actually disputing my statement at all.
Your main case there is software developers failing to do protocol design, which is exactly what I'm saying is a bad idea if they don't happen to be independently expert in it.
The reality is these situations would be a whole lot easier to resolve if people actually respected the expertise of each other. This works in all directions, but recent bugs show a definite weakness in terms of respect given towards relatively basic software engineering practices.
I may have been unclear: I am claiming that you cannot be a good protocol designer without sufficient expertise in cryptography AND you cannot be a good implementer without sufficient expertise in protocol design (I have updated my OP to add an instance of an implementation bug caused by insufficient knowledge about protocol design as well: TLS timing attack).
You could make the argument that if the implementer has to know anything about why the protocol or crypto works then the spec is poorly specified.
Certainly it helps to have a minimum of appreciation of the other parts of the domain, but I think you greatly overestimate how important that is for the kinds of problem we've been seeing lately.
In any other field, I would agree with that assessment. In the world of crypto, with side-channel attacks on the sound of your keyboard as you type, I think that having domain knowledge is essential for any implementer.
You could make that argument, but I will join with mehrdada in disagreeing with it.
It's possible that more vulnerabilities are caused by programming errors than by protocol misimplementation, but the latter do happen and are just as bad.
> (Not that most academics write good code either, but this is not an academia/industry issue. It is a security expert/non-expert issue.)
Security experts write bad code. Non-security experts write bad code. Code, by default, should be assumed to be bad -- you're right far more often than you are wrong. That's why stringent review and re-review of code (both at the micro and macro level) are required to actually end up with a decently secure product.
I'm a huge fan of setting up adversarial teams for this. If you have two product teams in a company, have each team breaking the other's product; the closer you are to something, the less likely you are to see the bugs, so this model works phenomenally.
In my experience, security training (even up to the level of expert) helps people write better code only in terms of the most low-hanging fruit (SQLi, CSRF, basic XSS). But due to how close the author is to the code, it's nigh impossible for them to see the really bad bugs. But if you train your developers to break things and then point them at other teams' products, you're going to end up with a far more secure company.
OpenSSL, and the other security problems lately, are just the top of a rabbit hole that is only ultimately resolved with isolated special hardware. Frankly we shouldn't trust our systems, open or proprietary, on the very simple basis they are too complex to verify.
Only by moving crypto functions to a separate user maintainable black box will this tide ever be stemmed. Of course, verifying that black box then becomes problematic, but it would be easier than the current situation.
There is a verified optimizing C compiler, CompCert. Admittedly, it is not gcc, and it is not easy to do, but still. Writing a verified SSL implementation is probably not more difficult than that.
> seL4 is 9000 lines of C and took 11 person-years to verify. How big is OpenSSL?
Total market cap of the top three tech companies is more than a trillion dollars. Even a hundred times more resources is affordable for them given the criticality of the project. The replacement does not have to be written in C, it can be written in ML-like languages and expose an external C interface.
> Also, verification isn't a magic bullet, you need a good spec.
True, but drawing from the CompCert anecdote, I suspect bugs in a verified implementation would be orders of magnitude less likely.
Apple has all the resources, and they had the "goto fail". You should not underrate open source. Bugs are shallow, but that can never mean every single bug. Some bugs will always be overlooked, no matter if open source or closed source.
It seems to me that the author of this piece has a lot of "misconceptions about Open Source" himself.
An example: "anyone can contribute, regardless of background or proficiency".
I'd encourage the author to research how open source projects are run before making claims like this.
Also.. How was this bug found again? Oh yeah. By analyzing the _open_ source code.
Professionalism is orthogonal to open source vs. closed source. There's a place for both, and there is good and bad open source and closed source software.
That's funny. When I make this exact point here on HackerNews I get downvoted to oblivion.
Open Source gives you potential to build a rocket to the moon. But it requires money and time and people willing to mind the code, and people with humble attitudes willing to accept when they've made mistakes and patch the code.
Quality Assurance requires effort, and that's where the fallacy of "Free" software really comes from. If you're not paying for it, you're going to pay for it. (Either by being the QE team and fixing bugs yourself or by living with buggy software.)
> The article wasn't particularly good, which may explain that.
So it's not that you think the article isn't very good but instead it just isn't? Bold statements like this need an explanation...
Stating that the article isn't very good and using it as an explanation as to why someone's comment was downvoted without giving any reasons does not really contribute to the discussion and also does not prove your point. Just because awalton has a different opinion does not mean that he/she is wrong.
> So it's not that you think the article isn't very good but instead it just isn't? Bold statements like this need an explanation...
First off, everything I say is "according to my opinion". That is implied and I don't have to explicitly state it on every sentence I write (especially on sentences that already sound like opinions).
Second, it's really not a bold statement. Read the other comments here—quite a lot of them are critical and the top rated ones all have excellent points. Given that, claiming the article isn't very good isn't much of a stretch. You want reasons? Read the rest of the %$#@! comments.
Now, my comment may have been on the pithy side, but I found it particularly funny that the guy was commenting about how he agreed with the article, complaining that when he expresses the same sentiment on HN he gets downvoted, but nearly every other comment on the story was attacking its shallow understanding of Free Software/Open Source, cryptographic library programmers, and virtually every other point it tried to make. IE, he appears to have same misguided opinions as the article's author, but not the self awareness to enlighten himself.
I've always interpreted Linus's law in the following way: given a bug, there will exist someone to whom the bug is obvious and will immediately spot it. However the law doesn't state how many people you would need to check, it might be 2 or it might be 100,000 required.
BinPress is misusing the term Open Source in their slogan. All four of their featured "Popular Products" are closed source. IMO http://opensource.org/ should be suing them to protect their trademarks, because their use of the term is trying to piggyback on the popularity of the Open Source community that OSI represents.
So I don't think they are in a good position to be talking about the meaning of Open Source, as they're doing in this article.
We are a marketplace. Our developers can pick which licenses they want to use - our only stipulation is the complete source-code would be included and meets the guidelines we publish (i.e, nothing is closed-source on Binpress). We have FOSS licensed projects, dual-licensed projects and projects licensed with our license generator, which for most purposes only differs from open-source licenses on one point - that the code cannot be redistributed as-is without any modification or extension. The reason we provide those licenses is that a lot of developers are worried that people will copy their code as is and sell it somewhere else. We think it's better if people share more code, if we can alleviate some of their concerns.
I don't think it's that surprising that our most popular projects use our own licenses instead of FOSS licenses. Most people care about results and access to the code, and not whether the license was generated by the OSI or the FSF. You can go over our licenses and provide commentary if you feel the need to do so - but please don't accuse us of doing something we don't.
I think you might be confused about what Open Source means. It does not mean access to the source code. Even Microsoft didn't try to hi-jack the term with their "shared source" licenses.
Open Source is a made-up word. It did not exist before the OSI used it to promote OSI approved licenses.
The OSI trademarked the term Open Source to avoid confusions just like this. Not allowing redistribution is BIG difference! Not only is BBpress selling proprietary software, its diluting the very meaning of Open Source!
It's interesting how you choose to spin it to fit your narrative. That product has multiple licenses, the one that allows redistribution of the source is this - http://www.binpress.com/license/read/id/1567/app/859
The one you linked to only allows binary distribution. This is how those projects support themselves, by offering tiers of pricing depending on the user needs. We just require that at least one of the licenses allows redistribution of the source. So I'm understanding that by your world-view, Open-Core projects are not open-source? or that open-source can only be used if sanctioned by the OSI? I'm afraid that no one has monopoly on that term. It means different things to different people. We call our products "Commercial open-source", which you can find the usage of which on the web and wikipedia as well. Most projects on GitHub do not have a license, which means they are copyrighted by default. We vet licensing for each project on our site, to make sure there are no copyright or licensing breaches, and provide a range of licensing options to fit the developer POV. Not sure where all the hate is coming from.
Some hate is coming from the fact that you're running a code-selling website, and you mentioned it on Hacker News of all places. Code-selling websites rank just above insurance salesmen and expertsexchange on the list of things that programmers hate.
Another good portion of the hate comes from the fact that you're selling projects that are not open-source as open-source.
Maybe it's just me, but if you're running a slimy code-selling website you should at least know better than to call it open-source. Here's a link you should read before you get sued by the OSI, which I will be kind enough to not charge $750 for: http://opensource.org/docs/osd
I'm also curious why you think integrating a PDF reader into your app costs $36k. In my world we just use a UIWebView. Or, if you want to type maybe five more lines of code, you can use CoreGraphics. You can then spend the $36k you save to get Donald Trump to fire your horrible developers.
Finally, you probably want to fix the grammatical issues in your laughable "commercial open-source" license if that's a core part of your business.
I would like to mention I have no problem with code selling sites. I think Code Canyon is a fine site, granted I've never used it. Also I do not have a problem with selling stuff under a proprietary license and then selling the same thing for more money under an open source license.
My issue is 100% the association of the word Open Source with proprietary software. Yes, even the enterprise license is proprietary. I think we have a big issue in the software world with confusion about what makes something open source. Part of this is because web software skirts the GPL and so some people have come to see Open Source as for the benefit of the developer.
Open Source is about the user. It is about giving the user freedoms, not saving developers money.
Now, the enterprise license is interesting. It is better than the introduction licenses and I think is 90% to the four freedoms. The only thing is the requirement to only distribute modified source. Which is a weird requirement since one need only add a no-op.
If I was running BinPress I'd inverse things. iOS devs and devs of proprietary software do not want to make their software open source, so charge them for the ability to use your library without distributing their code. This is the dual license business model and it can work well. Propreitary software has the money so get them to finance the open source project.
As far as I am concerned if you are not distributing source and redist rights to end-users then you are worth only as much as you can finance real open source.
Edit: I would also like to mention that I did not downvote pytrin.
Thanks for the explanation, we always appreciate sensible feedback on our messaging and product. We are always looking for ways to get our projects more open and accepted by the traditional open-source community. Our default option when adding new products on the marketplace is GPL + a commercial license (which is the option you mention). Most developers still pick only our own proprietary licenses, since they are worried about people abusing it.
We are also in touch with the OSI for creating a 100% open-source compatible license of our own that could be officially sponsored by them. It's been a slow process, but we hope to get it done in the near future. Our own license was created with the help of copyright lawyer that has dedicated his professional life to supporting and advocating open-source. It is a compromise between closed-source / commercial and fully open-source (what we call "commercial open-source"). For many purposes, it is less restrictive than the GPL (no stipulation on releasing your source if you modify and distribute on other formats), which makes it more attractive to businesses building commercial products (for example, iOS application, which cannot use GPL).
"Commercial open-source" is a pathetic term, please. Sorry for the strong words, but it hurts me when I see the term 'open source' with 'commercial'. Whatever happened to 'Hacker Ethic' ?
Sir, I must say, being on HN, you are at the outright wrong place!
Actually, (and this is not intended to defend Binpress's deceptive marketing!!) all Open Source as defined by OSI allows commercial use, and there is nothing anti-commercial about Open Source. So there's nothing wrong with commercial stuff when it otherwise respects all the Open Source values (which Binpress does NOT do, so there is something wrong in their case).
Everything you said is right with an important exception: The OSI's application for the trademark was denied by the government. So there is no trademark on Open Source.
Well, yes, Binpress totally abuses the term "Open Source", but the Open Source Initiative was denied their application for the trademark on the term, so there's nothing legally that can be done. All we can do is post a comment on Binpress links telling everyone that despite their claim, Binpress sells mainly just proprietary software.
Good to know. I tried to find it out by googling, and I had a hunch this might be the case but wasn't sure. Still, it might be worth a shot, because they could argue that it's a reference to the Open Source Initiative and its approved licenses, just like Chick-Fil-A is trying to argue that "Eat More Kale" is a reference to "Eat Mor Chikin".
If openSSL was closed-source and a vulnerability was found in it, couldn't it have been patched without revealing what the issue was? This seems to be a big security issue with open-source.
No, unless it's the sort of software that doesn't need to be distributed at all. Security patches to widely-used software are attractive targets for reverse engineering.
"OpenSSL is used and run by millions of companies around the world, many of which have dedicated software engineers working for them full-time, while reaching hundreds of millions of users. And yet, this issue was undiscovered for almost 2 years"
This is almost a non-sequitor (Sp?). Almost none of those software engineers looked at the source (and those few that did got eye bleed).
> “Given enough eyeballs, all bugs are shallow” – Eric Raymond
> only obvious problems are easily caught. An issue that manifests itself only under very specific conditions or not in a way that is obvious to the end-user, can go undetected for a long time.
There are fundamental differences between bugs and security holes. Bugs are something everyone has an interest in fixing. If a bug rarely manifests itself - then it is not that much of a problem.
Security holes are things which some people scrupulously search for, and then sometimes keep secret, for their own ends. Sometimes people even try to create security holes where there are none ( http://lwn.net/Articles/57135 ).
The main point, that more eyeballs doesn't necessarily lead to more bugs found and fixed, is a good one. Reading code, or text, specifically with the intent of finding errors is very hard, and is itself an error-prone activity. Anyone who has had to do close proof-reading knows this. It's hard work, so our brains are constantly fighting us and trying to "relax" back to a higher level of abstraction. That's one of the reasons I read the Coverity post with some interest. We humans are hopelessly ill-suited for these tasks, and we need all the help we can get.
This is BS; the bug was found by people analyzing the open-source code because anyone can do so. Also, criticizing the developer because he's a PhD student makes zero sense; the two best developers I've known were a student and a 13-year-old.
I also love how the author puts a thinly-veiled plug of his slimy "open-source" code-selling website in the middle. As benatkin said in his excellent comment [0], all four of their featured products are closed-source. The OSI should sue them for violation of their trademark of the term "open source".
Binpress doesn't promote Open Source software as anyone else knows it. Binpress promotes proprietary software where licensees can see the source code and modify it privately. Binpress calls this "Open Source" although it lacks all the qualities that everyone else assumes with that term.
Thus, Binpress always looks to combine their one very good point (that better funding for Open Source is important) with a bunch of junk trying to say that buying their proprietary software is the answer.
54 comments
[ 4.0 ms ] story [ 150 ms ] threadpatches and added features need to be reviewed by project owners.
open source mostly mean "you can read the source and modify your version, but that doesn't mean you can make a change that will go into the official release."
There are some very sensitive implementations of software which should be thoroughly examined by experts and criticized if they're not good enough. If there is no resources available to maintain a particular open source software, don't bother use it, ESPECIALLY if it's sensitive like openssl.
Open source allows software companies and other programmers to easily work together to solve a problem. Developer's time is precious so it's often time-saving to use somebody's else work, but that doesn't mean you should use it blindly.
> open source doesn't necessarily mean "anyone can edit it and improve it".
I think you missed the point in the article - it was about how anyone can create or contribute to open-source. Not about submitting patches to existing projects and have them pulled upstream without any review process.
You can look at the frequency of patches between proprietary and open source software, which shows a lot.
If you don't have the source code, it's actually a little harder to find a vulnerability since all you have is a big blob of binary assembly. Hackers can still find vulnerabilities with enough time on their hand, but it's still much discouraging.
No free lunch in security rather hides in the trade-off with convenience.
It's important to discuss what changes we can (and should) make to make problems like heartbleed less likely in the future, but wildly waving competing generalizations in the air doesn't help anything.
This particular observation comes up any time something goes wrong in any context. The stuff about the shallowness of bugs really has nothing to do with the argument. This bug was in fact quite shallow, some random entity just found it by looking. If more people had of been looking then it would of likely been found sooner. You can only find a bug once.
This is absolutely BS, especially in security and cryptography. Most security related code written by most so-called "professional" software developers is astonishingly terrible (e.g. ECB mode encryption, storing encryption key in code, reusing encryption keys, relying on (unauthenticated) encryption for authenticity, reusing IVs, linear time MAC verification, ...). Most cryptographers are academics. Also, anecdotally, the poisonous "demo an exploit or it doesn't happen" attitude in response to hints at a flawed system design is much more prevalent among "professional software developers" than in academia.
If anything, we should encourage more security experts in academia to engage in implementation, verification, and improvement of security code, not the other way around.
(Not that most academics write good code either, but this is not an academia/industry issue. It is a security expert/non-expert issue.)
I don't see why an OpenSSL developer would need either of the first two skillsets at all. Ideally, yes, but not necessarily.
[1]: http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipse...
[2]: http://www.sandelman.ottawa.on.ca/ipsec/1995/04/msg00148.htm...
[3]: http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf
Your main case there is software developers failing to do protocol design, which is exactly what I'm saying is a bad idea if they don't happen to be independently expert in it.
The reality is these situations would be a whole lot easier to resolve if people actually respected the expertise of each other. This works in all directions, but recent bugs show a definite weakness in terms of respect given towards relatively basic software engineering practices.
Certainly it helps to have a minimum of appreciation of the other parts of the domain, but I think you greatly overestimate how important that is for the kinds of problem we've been seeing lately.
It's possible that more vulnerabilities are caused by programming errors than by protocol misimplementation, but the latter do happen and are just as bad.
Security experts write bad code. Non-security experts write bad code. Code, by default, should be assumed to be bad -- you're right far more often than you are wrong. That's why stringent review and re-review of code (both at the micro and macro level) are required to actually end up with a decently secure product.
I'm a huge fan of setting up adversarial teams for this. If you have two product teams in a company, have each team breaking the other's product; the closer you are to something, the less likely you are to see the bugs, so this model works phenomenally.
In my experience, security training (even up to the level of expert) helps people write better code only in terms of the most low-hanging fruit (SQLi, CSRF, basic XSS). But due to how close the author is to the code, it's nigh impossible for them to see the really bad bugs. But if you train your developers to break things and then point them at other teams' products, you're going to end up with a far more secure company.
i'd rather say "and you just don't know about the closed source ones because they're harder to find" ;-)
Only by moving crypto functions to a separate user maintainable black box will this tide ever be stemmed. Of course, verifying that black box then becomes problematic, but it would be easier than the current situation.
There is a verified optimizing C compiler, CompCert. Admittedly, it is not gcc, and it is not easy to do, but still. Writing a verified SSL implementation is probably not more difficult than that.
Also, verification isn't a magic bullet, you need a good spec.
Total market cap of the top three tech companies is more than a trillion dollars. Even a hundred times more resources is affordable for them given the criticality of the project. The replacement does not have to be written in C, it can be written in ML-like languages and expose an external C interface.
> Also, verification isn't a magic bullet, you need a good spec.
True, but drawing from the CompCert anecdote, I suspect bugs in a verified implementation would be orders of magnitude less likely.
An example: "anyone can contribute, regardless of background or proficiency". I'd encourage the author to research how open source projects are run before making claims like this.
Also.. How was this bug found again? Oh yeah. By analyzing the _open_ source code.
Professionalism is orthogonal to open source vs. closed source. There's a place for both, and there is good and bad open source and closed source software.
Moving right along nothing to see here.
It was found by fuzzing. OpenSSL being open has absolutely nothing to do with its security, in a positive or negative way. It's just a poor project.
Open Source gives you potential to build a rocket to the moon. But it requires money and time and people willing to mind the code, and people with humble attitudes willing to accept when they've made mistakes and patch the code.
Quality Assurance requires effort, and that's where the fallacy of "Free" software really comes from. If you're not paying for it, you're going to pay for it. (Either by being the QE team and fixing bugs yourself or by living with buggy software.)
The article wasn't particularly good, which may explain that.
> …that's where the fallacy of "Free" software really comes from. If you're not paying for it, you're going to pay for it.
The "Free" in "Free Software" has never meant "No Cost". It has always meant "Freedom". When you start talking about cost you are missing the point.
So it's not that you think the article isn't very good but instead it just isn't? Bold statements like this need an explanation...
Stating that the article isn't very good and using it as an explanation as to why someone's comment was downvoted without giving any reasons does not really contribute to the discussion and also does not prove your point. Just because awalton has a different opinion does not mean that he/she is wrong.
First off, everything I say is "according to my opinion". That is implied and I don't have to explicitly state it on every sentence I write (especially on sentences that already sound like opinions).
Second, it's really not a bold statement. Read the other comments here—quite a lot of them are critical and the top rated ones all have excellent points. Given that, claiming the article isn't very good isn't much of a stretch. You want reasons? Read the rest of the %$#@! comments.
Now, my comment may have been on the pithy side, but I found it particularly funny that the guy was commenting about how he agreed with the article, complaining that when he expresses the same sentiment on HN he gets downvoted, but nearly every other comment on the story was attacking its shallow understanding of Free Software/Open Source, cryptographic library programmers, and virtually every other point it tried to make. IE, he appears to have same misguided opinions as the article's author, but not the self awareness to enlighten himself.
So I don't think they are in a good position to be talking about the meaning of Open Source, as they're doing in this article.
I don't think it's that surprising that our most popular projects use our own licenses instead of FOSS licenses. Most people care about results and access to the code, and not whether the license was generated by the OSI or the FSF. You can go over our licenses and provide commentary if you feel the need to do so - but please don't accuse us of doing something we don't.
Open Source is a made-up word. It did not exist before the OSI used it to promote OSI approved licenses.
With that out of the way I fount at least one non-open source product: http://www.binpress.com/app/pdftouch-sdk-for-ios/859 The licenses is almost 100% non-open source: http://www.binpress.com/license/read/id/1565/app/859 The only Open Source like-clause is the non-expiration!
The OSI trademarked the term Open Source to avoid confusions just like this. Not allowing redistribution is BIG difference! Not only is BBpress selling proprietary software, its diluting the very meaning of Open Source!
The one you linked to only allows binary distribution. This is how those projects support themselves, by offering tiers of pricing depending on the user needs. We just require that at least one of the licenses allows redistribution of the source. So I'm understanding that by your world-view, Open-Core projects are not open-source? or that open-source can only be used if sanctioned by the OSI? I'm afraid that no one has monopoly on that term. It means different things to different people. We call our products "Commercial open-source", which you can find the usage of which on the web and wikipedia as well. Most projects on GitHub do not have a license, which means they are copyrighted by default. We vet licensing for each project on our site, to make sure there are no copyright or licensing breaches, and provide a range of licensing options to fit the developer POV. Not sure where all the hate is coming from.
Another good portion of the hate comes from the fact that you're selling projects that are not open-source as open-source.
Maybe it's just me, but if you're running a slimy code-selling website you should at least know better than to call it open-source. Here's a link you should read before you get sued by the OSI, which I will be kind enough to not charge $750 for: http://opensource.org/docs/osd
I'm also curious why you think integrating a PDF reader into your app costs $36k. In my world we just use a UIWebView. Or, if you want to type maybe five more lines of code, you can use CoreGraphics. You can then spend the $36k you save to get Donald Trump to fire your horrible developers.
Finally, you probably want to fix the grammatical issues in your laughable "commercial open-source" license if that's a core part of your business.
My issue is 100% the association of the word Open Source with proprietary software. Yes, even the enterprise license is proprietary. I think we have a big issue in the software world with confusion about what makes something open source. Part of this is because web software skirts the GPL and so some people have come to see Open Source as for the benefit of the developer.
Open Source is about the user. It is about giving the user freedoms, not saving developers money.
Now, the enterprise license is interesting. It is better than the introduction licenses and I think is 90% to the four freedoms. The only thing is the requirement to only distribute modified source. Which is a weird requirement since one need only add a no-op.
If I was running BinPress I'd inverse things. iOS devs and devs of proprietary software do not want to make their software open source, so charge them for the ability to use your library without distributing their code. This is the dual license business model and it can work well. Propreitary software has the money so get them to finance the open source project.
As far as I am concerned if you are not distributing source and redist rights to end-users then you are worth only as much as you can finance real open source.
Edit: I would also like to mention that I did not downvote pytrin.
We are also in touch with the OSI for creating a 100% open-source compatible license of our own that could be officially sponsored by them. It's been a slow process, but we hope to get it done in the near future. Our own license was created with the help of copyright lawyer that has dedicated his professional life to supporting and advocating open-source. It is a compromise between closed-source / commercial and fully open-source (what we call "commercial open-source"). For many purposes, it is less restrictive than the GPL (no stipulation on releasing your source if you modify and distribute on other formats), which makes it more attractive to businesses building commercial products (for example, iOS application, which cannot use GPL).
Hope that makes sense!
Sir, I must say, being on HN, you are at the outright wrong place!
This is almost a non-sequitor (Sp?). Almost none of those software engineers looked at the source (and those few that did got eye bleed).
I quit reading after that.
There are fundamental differences between bugs and security holes. Bugs are something everyone has an interest in fixing. If a bug rarely manifests itself - then it is not that much of a problem.
Security holes are things which some people scrupulously search for, and then sometimes keep secret, for their own ends. Sometimes people even try to create security holes where there are none ( http://lwn.net/Articles/57135 ).
I also love how the author puts a thinly-veiled plug of his slimy "open-source" code-selling website in the middle. As benatkin said in his excellent comment [0], all four of their featured products are closed-source. The OSI should sue them for violation of their trademark of the term "open source".
[0] https://news.ycombinator.com/item?id=7579700
Thus, Binpress always looks to combine their one very good point (that better funding for Open Source is important) with a bunch of junk trying to say that buying their proprietary software is the answer.