The Conflict at the Heart of Open Source | Hacker News Reader

The Conflict at the Heart of Open Source

drdobbs.com

104 pointsdraegtun81 comments

And that's not even the worst of it all in my opinion. What really struck me in the midst of that whole debacle was the number of programming-geniuses-in-hindsight.

OpenSSL is a free software project, meaning that everyone smart enough to snark after the fact could and should have been providing patches before all hell broke loose. I mean, it is amazing how many people were poking fun at the "awful coding practices" and the "bug-laced codebase". Where were all those people when the code was committed?

There's no winning in a culture where you devote your time and efforts for the greater good in an extremely complicated field of computer science only to be lambasted at the first mistake by the very same people who should have steadying the boat with you in the first place.

But it looks like until recently there was not sufficient funding to retain said developers, so you're restricted to the subset of developers who have a particular interest in openssl.

  > everyone smart enough to snark after the fact could and
  > should have been providing patches before all hell broke
  > loose.

Could have? Sure. Should have? Not so fast. Quite a few of those people had pointed out that the complexity and sheer ugliness of the OpenSSL code created a large unnecessary barrier to contribution, and that people's time would be better spent on alternatives. It would be very interesting to look at the use:contribution ratios over time for OpenSSL and e.g. PolarSSL, which also happens to be GPL-licensed. Sometimes the people who made a mess bear primary responsibility for cleaning up, and there's nothing wrong with others saying so. Bringing pressure to bear on the people who can actually make that kind of fundamental change might be more productive than submitting patches that have to be rejected because they're based on wrong assumptions about complex code.

Now, if someone from one of those freeloading companies that have eschewed alternatives and continue to ship millions of copies of OpenSSL without contributing anything were to offer such criticism, that would be wrong. It would be wrong not because it's kibitzing from an outsider, but because it's ingratitude from an insider. That's a different thing. If contribution was always a precondition for comment, this would be a very quiet world. Comments like these might not be allowed:

  > this is excruciating to read due to very strange page
  > layout.

Where's the patch for that?

I have nothing more to add to that except that what you just said indeed adds more nuance and I totally agree.

And touché (though I guess you nothed I merely criticized the form and thanked the author for the content) :)

> OpenSSL is a free software project, meaning that everyone smart enough to snark after the fact could and should have been providing patches

If you follow Valhalla, OpenBSD merged a number of patches which had been languishing in the OpenSSL tracker for months or years.

Perhaps we need to take a second look at where the "lambasting" first took place. It was well, well before this recent OpenSSL incident.

For many years now, the security community taken as a whole has very vocally stated, "Never roll your own crypto!", and been highly critical of anyone who has attempted to do so without the security community's blessing.

For many programmers, maybe that is good advice. They probably shouldn't try to design their own schemes, and probably shouldn't try to build them, either.

But I think this attitude has also driven away a lot of very talented programmers who perhaps could have caught an issue like this much earlier on, or perhaps even avoided it in the first place.

So I believe it's misleading for you to portray the users of OpenSSL as somehow being responsible, especially given how much effort the security community has generally put forth toward discouraging more direct participation from these users.

The security community took a holier-than-thou attitude for a long time. It has now been shown that they aren't necessarily any better at avoiding critical and very harmful bugs in their code, however. So of course people will call them out. And there's not a thing wrong with doing so.

Wait a minute, does OpenSSL === The Security Community? It's an honest question because I really don't know who is behind OpenSSL and what their standing is in the security community.

That said, your final sentence seems unfair either way. The warning not to roll your own crypto is to avoid the all too common noob pitfalls whereby a reasonably experienced developer invents a security scheme that is completely and utterly broken from its very conception. It's not tell smart people they are too stupid to do crypto (which is a lot of programmers' knee-jerk reaction to being accused of ignorance on any technical topic), it's merely to point out that there's a lot of existing knowledge out there about crypto, and if you don't go learn about it first then your contribution will almost certainly be of negative value.

It's not meant to say don't contribute to OpenSSL or one of its competing libraries, it's meant to say that you need to be grounded in the state of the art and have peer review in order to produce a solid cryptography product.

I got the same vibe from the chorus of "never roll your own crypto" rhetoric I heard on the Internet -- that I shouldn't even bother looking into OpenSSL's code unless I went to the Shaolin Temple of Crypto and trained under Master Schneier for 10 years. Just because the intent of the message was one thing doesn't mean that it won't be interpreted in a completely different way by the intended audience.

Looking at OpenSSL source code and fixing a bug are pretty much the exact opposite of "rolling your own crypto."

The impression I got from "don't roll your own crypto" (especially after the Debian key bug thing) was that crypto code was so nuanced and complicated that even if you thought something was a bug, you were likely to be horribly wrong for really complex reasons outside the realm of understanding of anyone who wasn't an expert, and everyone would laugh at you for even bringing it up.

After an entire webpage was created to ridicule the Debian developers for how stupid they were when they changed something in OpenSSL's code in their distro's version (complete with references to Dilbert strips about faulty random number generators), I just assumed that I shouldn't even bother trying to look at OpenSSL's code (and especially not try to send patches or ask questions on their mailing list) unless I was willing to make a lifestyle out of it, lest I get ridiculed in the same way (but probably not at Debian's magnitude). I wasn't willing to make a lifestyle out of it.

Obviously a lot of security people and cryptographers develop a holier-than-thou attitude, no doubt from spending their lives scrutinizing things that people continuously get wrong and for which failure is catastrophic.

That attitude, off-putting though it may be, shouldn't cause us to read too much into what they say.

Many said this in hindsight, but for OpenSSL it was no lack of people that said this in foresight as well, i.e. they complained about the shoddy code quality of OpenSSL long before the heartbleed attack. One of those was Poul Henning Kamp, that have mentioned OpenSSL as a problem in many talks before Heartbleed was discovered. He is not alone. It is also quite well known that OpenSSL have had a unusually high number vulnerabilities in its history, mostly because its low quality. I have read the code, even before the heartbleed bug was introduced, and I was not surprised that this could happen. Some of the code that lead to the heartbleed bug was made to bypass security measures done by the operating systems to make it hard to exploit such vulnerabilities, and the maintainers did this instead of fixing the problem.

So why have nobody fixed them. I guess one of the reason is that the codebase is broken beyond repair, and it was not just to "provide patches". In fact a major rewrite or reworking of the code was required, and this is what the people behind LibreSSL currently are doing.

Another reason is that people (and companies) generally are not willing to pay for security, and does not know when something is secure or not. Thus for something that works, but is insecure, the incentive for doing something about it is missing. Security vulnerabilities is only theoretical for most people.

It's been linked by me (and others) at times, but PHK's recent talk at FOSDEM[1] is something every engineer needs to see. In the talk, he not only has a well-reasoned warning about OpenSSL months before Hearbleed, but he makes a pretty convincing argument about the "PSYOPS For Nerds" we could be witnessing in this very thread.

Are the nerds about to fix some of the security holes you've been exploiting? Easy; just distract them with yet another "gpl vs bsd" bikeshed argument! They never get tired of it!

[1] http://video.fosdem.org/2014/Janson/Sunday/NSA_operation_ORC...

The OpenSSL license is a little strange, which may have pushed away potential contributors.

I have two conflicting moods here.

First, companies using OpenSSL for free were completely living up to their end of the bargain, which was "you can use this for free."

Second, there was absolutely nothing stopping a few banks and/or giant web companies from getting together to raise a million dollars to have this code professionally audited. Banks do spend lots of resources auditing the code they write themselves, so how come nothing was spent here?

(Related to second point: There was also absolutely nothing was stopping people from doing what the OpenBSD team is doing now and deciding to tear it apart to clean it up. There was also absolutely nothing forcing people to use OpenSSL. )

... Or OoenBSD.

Hang on a second tho'. What sort of warped design process came up with the idea that a "ping" should be up to 64k in length? That's so far off the wall it's not even wrong (Feynmann). Whoever came up with that idea is the one at fault...

"Not even wrong" is something W. Pauli said first, although Feynman might have quoted him.

IPv4 ICMP echo request/response packets can be 64k in length.

Wait a minute: The moment OpenSSL actively started seeking for funding did receive bids from huge corporations. Same thing happened for OpenBSD, the time window from the moment De Raadt started shouting about funding to the moment where OpenBSD received the needed funding can be seen as extremely small (and for a good reason since both OpenBSD and OpenSSL are corner-stones technologies/achievements).

Of course these projects (and many others) should receive scheduled funding by lucrative corporations or the state, but to me seems like ultimately our current approach works fine and it is just auto-adjusting to the need for better/more responsible development and funding. Let's wait and see how the situation will evolve next year and the year after that.

I think the author is just choosing a half-empty-glass view for no reason. Financially successful projects offering an open-source/community version and a SaaS version of their software are extremely popular these days, which means that generally speaking it works.

Why are non-monetary donations ignored? The Heartbleed bug was discovered by a person working for Google, and the patch was written by other two employees - is that not an important contribution?

Exactly. In fact it's far easier for a company to justify that kind of spending to its accountants and shareholders than "donations" that appear totally discretionary.

I don't think a license was a problem in this case. Do we know of any companies that internally improved OpenSSL and did not open source the changes? For a crypto infrastructure code like this, it would be a very strange strategy. It doesn't seem like any competitive advantage to be the only company that runs OpenSSL with proprietary fixes.

> Do we know of any companies that internally improved OpenSSL and did not open source the changes?"

Akamai did (covered on HN when the Heartbeat vulnerability was at the top of the news).

The entire logic chain of this article can be summed up as: author likes copy left, heartbleed is still a timely topic, OpenSSL was copy middle, ergo if OpenSSL had use the license style the author prefers we wouldn't have had heartbleed, ignore copious easily obtainable counter points at every link in the chain.

Some software thrives in copy left, some thrives in copy middle, some thrives in copy right. If you are an empiricist, it remains eminently unclear which license style is best suited for which kinds of projects in the long term.

I read it more like if you use a copy right license for your project you'll have a hard time funding your project for the long haul.

Anybody who qualifies BSD/MIT style licenses as "business-friendly" and juxtapositions that with "copyleft", thereby implying that copy left is anti-business is not someone advocating copy left.

Quite the contrary, the whole suggestive false premise is remarkably similar to 90's style anti-GPL FUD. Unless the the author is a card carrying communist and believes anti-business is a good thing, I would say he's not a big fan of copy left.

I read "business friendly" as having a snide tone. Large swaths of the copy left community don't like the concept of business friendliness and I often hear it in the same sentences as "leeches" or "steal."

That said, copy middle, or permissive licenses, or whatever term you want to use, is at least a little more business friendly than copy left.

I personally don't allow copy left code into my applications so I can keep my IP rights clean. I do that for long term option value, aka business reasons.

> If you are an empiricist, it remains eminently unclear which license style is best suited for which kinds of projects in the long term.

Only if you're the kind of empiricist who hasn't done a systematic survey of what they're trying to figure out, but just assumes that all options are even by default due to the Law of Averages.

That is, unless you're summarizing some study about Free and Open Source software licensing and project growth that I'm unaware of. If you are, I'd be highly interested in reading it.

The data set I'm most familiar with is web frameworks where copy middle seems to have a substantial lead:

http://en.m.wikipedia.org/wiki/Comparison_of_web_application...

Another data set: http://www.softwarefreedom.org/resources/2013/lcs-slides-aar...

"Some software thrives in copy left, some thrives in copy middle, some thrives in copy right."

That's the problem. There is no "copy middle."

BSD, MIT, Apache2, wtfpl

I consider all of those to be copy middle

All these licenses are based on copyright.

What killed me was the financial incentives of the OpenSSL devs were directly opposed to cleaning it up. If you make money through consulting to fix it up on an ad hoc basis then having an impenetrable mess that everyone uses by default and you happen to be the one major expert in is very good for your earning potential.

What's worse is it seems like the incentives didn't line up to motivate a clean up, but they didn't convert that potential into actual cash either. Lose-lose.

The sad thing is, that conflict of interest exists for nearly every open-source project out there. The only real way to make money from creating open source is to do consulting based on your expertise, or an"open-core" model like nginx. Both of these become less profitable as the quality of the open-source code increases.

The worst is small projects that do one thing well. Although you can produce a stream of them to fill a niche. Most consultancy is around bloated projects.

It's odd that the article doesn't discuss the most common[1] ways in which corporations contribute to free software: by employing the maintainers and allowing them to spend a portion of their time at work improving the software. I know of nearly a hundred people in the same situation (albeit often with much lower-profile projects than OpenSSL) and I know zero programmers working on open-core projects. The consulting model is a lot more common than open-core, but nowhere near as common as the employment model.

[1] - in my own experience

I've long thought crowdfunding could be an important source of funding for open source developers. I even built a website designed for the purpose [0], but no one has used it, and (as you'll see if you look) I've let it stagnate for a while. I haven't really tried to publicize it, admittedly, though I post here about it occasionally and hardly anyone ever responds.

Despite this discouraging experience, it still seems to me that the open-source world needs crowdfunding, and Kickstarter-style crowdfunding isn't ideal. Certainly, no significant fraction of open-source development is being crowdfunded yet.

My site isn't the only one trying to get a piece of this market, of course; there are others, and we all have different systems. But the question I'd love to see some discussion of here on HN is, why aren't any of these sites catching on? Why is open source not as good a fit for crowdfunding as a few of us think it should be?

[0] https://bountyoss.com/

When people type "[port|yum|apt-get|R CMD] install blah" it's not obvious that often unpaid people have spent significant time and effort making, enhancing, and porting the software that magically shows up. I'm old enough to remember when netscape cost $60 and eudora cost $90 or so for an email client, and you where even supposed to pay for winsock to connect to tcp networks. People now seems to assume that software should be fully featured, included, and free.

I do know that I think open source often fails to produce good software for this reason; when unpaid efforts compete with job, consulting, SO, kids, sports, recreation, etc for time it's inevitable they will often be a lower priority; I wish I knew some way to help people get paid and change that.

Currently, I think open source seems to do best in "base of the pyramid infrastructure" type projects. The kind of software that everyone uses, but that is not a differentiator ("the secret sauce") that makes something stand out. Companies that 'get it' will contribute back to something like that with a portion of the profits that they make with what actually makes their money. We see this to varying degrees with lots of big companies like IBM, Google, Facebook, Amazon, and.... gasp, even Microsoft, which is taking some baby steps in that direction.

I don't think of it as a "solved problem" though, so it'll be interesting to see where open source goes in the future. The public goods link I posted elsewhere here is a good read, although a lot of negativity regarding copyright has crept into it.

OpenSSL is at the base of the pyramid and it proved that that model can fail.

> The kind of software that everyone uses, but that is not a differentiator ("the secret sauce") that makes something stand out.

Doesn't OpenSSL fit this definition perfectly?

Sure, but that doesn't mean it works all the time, everywhere. Like I said: not a solved problem. It seems no one really stood up and took the lead to fix things.

"Sure, but that doesn't mean it works all the time, everywhere."

...which is a rather unsettling property in the foundation of your pyramid.

I agree with your theory--I'm just sad to see that there isn't always a lot of that in practice.

Hell, they almost killed off SPARC support on Debian a month ago because of developer ADD.

I see this "pyramid" across society in general, and I find it extremely troubling:

- There is no effective monetization scheme to develop, maintain, improve, or redesign basic infrastructure that is critical and used by everybody

- There is lots of money thrown around for tiny little non-reusable services that depend on that infrastructure

Where and how money is spent on the core infrastructure is typically sporadic, subject to the whims or neglects of the big companies that have R&D budgets, and typically their best interest for the infrastructure is not quite that of the general public.

Example: the web, which grew from a simple consumer-is-in-control document sharing system to an incredibly complicated and misengineered producer-is-in-control application engine that abuses user data/privacy all throughout. Yes the infrastructure was developed, but very poorly and incrementally, and with bad intentions.

Yes the infrastructure is largely open-source / open-protocol, so that counts as a win? But I wish we could invent a society in which shared-infrastructure is valued and monetized proportional to its contribution to the society (which would outweigh the utility of the services on top of it), rather than vice-versa.

Open-source verifiable operating systems, security libraries: these are more important than your text-messaging app! But we don't know how to fund them.

"Public goods" is what you are talking about, and the link I suggested covers their provisioning, and its problems, in depth.

I like the LGPL/GPL/AGPL licenses. They are, indeed, a best-of-all-worlds approach for most projects.

Maybe for projects such as OpenSSL and other "infrastructural" software, but choosing a copyleft licence for e.g. a compiler/runtime library would be IMO a mistake. For example, LLVM chose a non-copyleft open-source licence, and one of the main issues preventing OCaml from becoming more mainstream is its horrible licence (which is actually much worse than GPL, as it requires that all modifications to code be distributed as original code + a patch).

GCC is (unsurprisingly) copyleft and incredibly mainstream. QPL patch requirements are a big hassle for distros, although Debian has special casing in dpkg building to handle it.

GCC's traction is mainly due to it being, for a very long time, the most complete and widely-ported open source compiler system available.

Its competitors tended to be expensive commercial options, or comparatively limited open source projects. Any individual or organization wanting to use an advanced, yet free, compiler system generally ended up with GCC by default.

It wasn't GCC's licensing that attracted them. In fact, its licensing ended up being a liability, especially for commercial users. That's why we've seen LLVM and Clang really take off lately. They started to not only match the functionality of GCC, but did so with a far more flexible licensing approach. This made them a much more appealing set of tools for many users, both commercial and open source.

Clang/LLVM are also much easier to work with architecturally, as well as being 20 years newer and offering new ways of using IL; difficult to control for that variable.

> There is now a distinct strain in the OSS market that advocates loudly for non-viral licenses. The growing view ...

[Citation needed]

This article is drivel from beginning to end.

It even misses the main story -- that the OpenSSL license has a peculiar advertizing clause that causes all sorts of integration problems with other projects.

My tale is a little bit different.

I wrote an open-source library for a popular service in a popular programming language. I wrote a couple of e-mails and suddenly my library became popular.

Today it has had about 50 different people work on everything from off-by-ones to upgrading to the next language version.

This library has been a reason to employ me, so the monetary benefits are there.

I don't expect somebody to pay for something that I put out for free, I don't expect anybody to help me make that something better either. However, the time I've put into this project is worth a thousand times less to me than the standing and respect I gained, and the people I got to interact with so far.

I cite this site. If you still don't believe me, wait around for the next GPL licensing fight to break out on HN and you'll see plenty of people calling it "viral" and insisting everyone should go with BSD or equivalent and if you don't it's not truly "open source".

It's such a common argument at this point that I would disagree that it's a "citation needed".

I don't know that it's growing, either. I think the distribution of people making the anti-GPL argument is just super fat amongst decisionmakers and influencers in businesses.

I post all kinds of controversial things on Twitter. I _never_ receive as much pure hatred as when I talk about my preference for a viral license.

Running a business is not easy, open source or otherwise. Neither is building a community. Has the author considered that maybe the OpenSSL people are just bad at business and community-building?

> Among the many discussions was one regarding Google's steadfast refusal to pay for OSS software it uses.

Well, we can count on the US government to fund OSS, like Tor.

Government funded open source is certainly one possibility, and one that people like RMS favor to some degree, if I understand them correctly. Governments do fund plenty of other public goods (using the definition from economics: https://en.wikipedia.org/wiki/Public_good ). There are plenty of problems with this approach too, though.

Don't forget about the EU government.

Which EU government?

There is an EU parliament and there is the EU commission.

Since the EU is comprised of 28 sovereign countries there is no such thing as an EU government.

I'm sure he means the Commission. And arguably, sovereignty is decreasing for member-states. For instance, possibly as much as two-thirds of the laws and regulations that affect people living in the EU come from the EU itself - not the member-states. For Eurozone members, monetary policy is controlled by the EU, and increasingly fiscal policy. What does sovereignty look like in this picture?

Although, I'm not sure if the Commission itself would have the revenue to support key open source projects. They could certainly enact regulation to encourage funding, however.

The EU spends a lot of money on research (it paid my wages for 5 years when I worked on ESPRIT projects):

"€53 billion has been made available between 2007 and 2013"

http://europa.eu/about-eu/funding-grants/index_en.htm

Nice! Thanks for the link.

Horizon 2020 is the new programme "with nearly €80 billion of funding available over 7 years (2014 to 2020)".

http://ec.europa.eu/programmes/horizon2020/

What kills me is that the US Gov does pay for a fair amount of work (the military loved funding gcc for instance)

I'd also point out that we've (google) spent scads of money on oss software development , orgs and the rest at Google. The author really didn't research before writing the article.

redhat's revenue is from service/support. Agreed it's rare.

dual-licensing works, but a problem is getting customers to pay in a timely fashion - we already have it, what's the rush? However, to be fair, this may be due more to organization delays (getting management approval, waiting for the meeting to get management approval, etc)

What I like about open-source is the "transparency" nature of it more than the "free-of-charge" aspect. I think the the perfect business is somehow open and transparent, and at the same time monetizing. People love to pay if they see what their money is doing.

This is actually a big problem for me. I'd like to start a great open source project but then I'd also really like to somewhen get enough money out of it, so I could actually care about it full-time. But this seems rather hard to do :(

I'm sure there's a license that allows the code to be open however if used for commercial purposes requires companies to contribute back either financially or with code.

O wait isn't that GPL?

If you're afraid that companies will steal it and not respect the license face it they always do.

However if your tool becomes widely used they will eventually have follow the license and if you know with certainty that a certain company is using your too and braking the license you can always sue them.

The most devastating thing the community can do now is fund a organization that can sue companies for breaking the terms of free software they are using I'm certain 90% companies are in violation of at least one license.

I recommend they start with high frequency trading companies.

>I'm sure there's a license that allows the code to be open however if used for commercial purposes requires companies to contribute back either financially or with code. O wait isn't that GPL?

No.

The GPL says nothing about people contributing back financially, even if they use the code for commercial purposes. It also only requires people to contribute back code if a) they make changes and b) they distribute the changed version of the library outside their organisation. It's trivial for people to base multi-million dollar business on GPL code and contribute nothing back. It happens all the time. If you think the GPL protects you from that you need to read it more closely.

>The most devastating thing the community can do now is fund a organization that can sue companies for breaking the terms of free software they are using

Only the copyright holders have standing to sue.

"The GPL says nothing about people contributing back financially"

That's kind of the point, if you own the source, you can license it as GPL for the general public or anyone else willing to participate in the ecosystem (aka other GPL compatible projects), or for a modest $100K fee per year I'll license the same code to you under whatever crazy license you like just for your company.

"Only the copyright holders have standing to sue."

See above, if you're the copyright holder, you can sell a "special" license to special buyers.

If you've ever wondered why some GPL projects are "weird" about demanding patches will not be accepted unless you reassign your copyright for those patches to the project, well, now you know.

Its only fair after all. Either you'll contribute to the ecosystem by donating your source like we did, or you'll contribute to the ecosystem with a fat stack of cash, but either way, no freeloading bums.

But that isn't a consequence of the GPL, is it? That's a consequence of you being the copyright holder.

The misconception that the poster above was correcting was the claim that the GPL requires you to contribute back either code or money: it does not (unless you distribute changes to the code, etc, etc, in which case it's about making your changes available under the GPL, and not at all about giving money to anyone).

> I'm sure there's a license that allows the code to be open however if used for commercial purposes requires companies to contribute back either financially or with code. > O wait isn't that GPL?

No, the GPL allows code use for commercial purposes without contributing anything back. Though MySQL AB for a while based its business around pretending this wasn't the case.

That's why you have the AGPL. I'm not being snarky here at all. The most recent example of someone taking their product from MIT(or similar OSS) license to AGPL is ServiceStack, .NET library. The author felt that he did not want to continue support this fairly popular library at the expense of his livelihood.

Interesting that they say "you shouldn't write SASS software".

http://www.gnu.org/licenses/why-affero-gpl.html

also: We don't see any sensible way to address the SaaSS problem with license conditions on particular programs

Every single developer would like to work like that (getting paid to work on own code that you have complete control over).

Bitcoin!

Maidsafe!

I don't think this is an especially good article, and I don't much like the term "viral" in this context since it seems to be being used for propaganda purposes.

There's no reason why businesses can't use software under copyleft licenses. The copyleft licenses are intended to ensure that systems produced for the public always remain available to the public and don't get turned into closed secret systems available only to the privileged. In economics terms it's a kind of free rider problem - how to stop a common resource from being parasitised.

This article pushes a misconception that there are only two or three FLOSS licenses out there. There are dozens and dozens to chose from today and even older projects once licensed one way can convert to be licensed another way. Mozilla makes its code available under either the file based MPL or the more popular full copyleft GPL and that is the result of a multi-year project led by Gerv Marham to find all of the MPL contributors and work with them to get their agreement to re-license under both MPL and GPL. No project is "stuck" with a license and there are far more licenses and combinations out there than the few mentioned in this article.

Reply on news.ycombinator.com