EU study recommends OpenBSD | Hacker News Reader

EU study recommends OpenBSD

undeadly.org

352 pointsfcambus150 comments

Theo De Raadt always complained that many of the institutions that run and use OpenBSD don't contribute back. Good to see the EU at least acknowledging that its something that they should explore. They probably use it and its features more than they realise.

I suspect there is a strong political motive as well behind being "technologically independent" after the NSA mass surveillance revelations.

I like the sound of an EU BSD fork - hopefully they fund one. We've always been lacking in the Operating Systems dev department over here in Europe. Linux is our main contribution but we can do more.

> Theo De Raadt always complained that many of the institutions that run and use OpenBSD don't contribute back.

Sounds like he needs a different license then.

More often than not, he wasn't referring to contributions in the FSF sense (i.e. people modifying code that they don't send back to the original authors). He simply meant that many of the institutions that run and use OpenBSD, which is available entirely for free, don't give anything in return - be it in the form of code, money, documentation or promotion. Another free license solves only a small proportion of this problem.

    Another free license solves only a small proportion of this problem.

True, but with BSD I'm not sure you can view it as a problem to begin with since the license is explicitly designed to legally absolve the user of all obligation to do just that.

If you desire monetary contributions be made, some kind of commercial license is the solution. If you desire modifications be contributed back, there are other licenses that cover that expectation. And there's nothing stopping you from creating your own license.

If you don't require or expect any contributions back or monetary contributions under any scenarios, then BSD is a great license for that.

I'm sure when confronted with a lack of contribution (monetary, labor, code modifications), most companies would reply "Well, yes. That's why we chose software with a BSD license."

I think from the BSD point of view, contributing back is seen more of a weak social obligation than a legal one. You contribute back because it's a nice thing to do for those giving you free stuff, not because of section 6 paragraph 1 of some ten page legal document.

Asking people to consider it is the right thing to do. Switching license would defeat the entire point.

There probably exists lots of differing experience on this, but I've found it easier to get permission to contribute paid work on a tit-for-tat basis, because it alleviates the "why should we let our competitors use our work for free" question.

I don't think that it is a coincidence that GPL led to Red Hat, a billion dollar support and services company, while BSD let to a multitude of hardware companies. The former is direct and the latter indirect profits of their respective software. The difference in worldview leads to different business ideas.

> I don't think that it is a coincidence that GPL led to Red Hat, a billion dollar support and services company, while BSD let to a multitude of hardware companies.

GPL isn't directly responsible for Red Hat. The popularity of GNU/Linux at the time (vs *BSD) of it's inception is responsible for that. Licence had nothing to do with it.

Don't take my word for it. Take Bob Young's.

There is definitely business value in contributing to these projects.

First of all, by contributing, you show a mutual interest in the increased quality of the solution. This in turn will motivate the maintainers to better understand the business concerns of the new contributor.

By contributing, the contributor will gain insights in the workings of the solution, thus increasing the quality of the product itself. (As an analogy: by taking apart an amplifier, you increase your understanding of the way the product satisfies your needs).

Last but not least, contributing generates good-will, subsequently increasing the probability of adequate answers to support questions.

There's also a lot of business value in freeriding when the software license explicitly allows you to do so.

Sure, the business values I mentioned are like 'extra income' over the free-riding 'income' you mention.

(Now this makes me wonder how to book the use of open source software in management accounting)

It's also free on-the-job training for your in-house developers, and it probably also helps your company when you're recruiting developers--you can look for potential employees among the other contributors to the same OSS project your company uses.

There are things in this world that are not a business.

But also this things don't have money to spend on software they can use for free. Or time to contribute in any other way.

Yes, but forget monetary/labor contributions. I think jkyle has a point: the BSD license is a "no strings attached" license, and so it can be chosen by people who presumably don't even want to promote the software, advertise the fact they are using it or campaign for more software like it. If Theo De Raadt finds this disappointing, maybe he should choose a different license?

The problem is that de Raadt and crew have a much bigger priority: that OpenBSD's code proliferate and prevent any duplication of effort in creating secure programs. They've explicitly stated in the past that they consider proprietary use of their code to be a good thing (albeit it would be better if they'd push some money back to the OpenBSD crowd) because it prevents those companies from having to create yet another in-house-developed (and probably half-assed) security implementation.

    The problem is that de Raadt and crew have a much bigger priority: that OpenBSD's code proliferate and prevent any duplication of effort in creating secure programs.

I think that's an excellent reason to use a BSD license. If you want to facilitate wide industry adoption that has zero resistance from legal departments, BSD is an obvious choice.

That's a perfectly reasonable priority! It's just that it possibly comes along with some disappointment, caused by people who don't contribute anything back (money, code, documentation or simply promoting the software).

Indeed. I'm personally glad it's the priority; knowing full well that non-free software ain't going away any time soon (alas), I'd much rather that non-free software be using well-designed and thoroughly-audited OpenBSD-derived code than using some hacked-up monstrosity in its place.

Actually what he said was:

GPL fans said the great problem we would face is that companies would take our BSD code, modify it, and not give back. Nope—the great problem we face is that people would wrap the GPL around our code, and lock us out in the same way that these supposed companies would lock us out. Just like the Linux community, we have many companies giving us code back, all the time. But once the code is GPL'd, we cannot get it back.

As we've seen with GPL'd code, many companies are happy to skirt the license restrictions if they feel that they can get away with it. How much money and effort would then need to be expended to enforcement of said new license for OpenBSD? How many companies would do a cost/benefit analysis of the likelihood of OpenBSD lawyers suing them, and even then ignore the license if they thought that it would be less expensive to risk a lawsuit?

"Change the license" isn't a silver bullet. Companies aren't machines that are fed licenses that they then obey like punch cards into an old IBM machine.

I don't think that would make them likely to contribute back, they'd just use something else. He'd rather have selfish people using good software than choosing to use something inferior.

Maybe, maybe not. They'd all do the same sort of cost/benefit assessment and if they deemed the benefit to outweigh the cost of contributing back they would do it.

There'd be some who would change their options and some that would become contributors. Hard to say how it would pan out.

But, when you select a license like BSD (which I've done myself) you shouldn't complain when users don't contribute back.

You selected a license that formally declares your intent and expectations; the user has formally agreed to them.

Actually one's expectation can very well be that people be nice to you even if you're not using legalese to require that of them.

I wonder how much of an actual analysis is done in these cases, and how much it's just a boss saying that he doesn't want people "wasting their time" working on something that isn't directly related to their stuff.

Somehow Google, Samsung, and Intel are sticking the Linux kernel in everything despite it being GPL'd and them having to release their modifications. Might have something to do with how reengineering the Linux kernel would cost on the order of billions of dollars in engineer time.

Just look at how many Android vendors actually honor the GPL. Even the major vendors tend to mess up their source code dumps, and lots of the Chinese (hi Mediatek) vendors don't even react on emails.

Google should require in the vendor license terms for the Android brand and the Play Store that the sources be released on Github.

I don't think any of the free/open licenses require users to contribute to the parent project. I don't think any even require that people distributing modified versions, send those modifications back upstream.

In fact there was a shitstorm when some licences had "all modifications must be sent upstream" clauses e.g. Plan9's original license had that clause. And then the "tick this box if you don't make nuclear weapons" clause was lambasted in Theo's colourful style [1]. There was a time when OpenBSD were considering moving to the plan9 tool chain - which is now available under both GPL and MIT licensing.

That sad part was, most everyone in the plan9 community agreed with him but had their hands tied by Alacatel/Lucent legal and US law.

[1] https://groups.google.com/forum/?_escaped_fragment_=topic/co...

The GPL kinda-sorta does. I guess it depends on your definition of "contribute back." People that derive from GPL source have to release those changes to the public, which could just be a zip archive on their web-site rather than a git pull request.

I guess what I mean is, the company can try to be as unhelpful as possible (e.g. strip comments, place all code into a giant .cpp file, etc) but it does technically have to publish source code regardless.

The GPL requires you to distribute source code in addition to binaries. If you don't distribute binaries (i.e. if you're running the code on your server farm only), then you don't have to distribute anything.

That is why some choose to license their work under AGPL.

If you work for a bigger organization these licenses are banned for a good reason. There are some companies who are a little bit too relaxed with this ban (like VMWare) and you can see the results. I know for fact that some of the big guys take licensing very seriously and there are licenses that are approved for use while others are banned. The want to make sure there is no surprise down the road.

And that's why some stay away from AGPL licensed projects.

That still only goes so far, though. If you're building a product on top of a database that's licensed with the AGPL, like Mongo, you have to distribute those changes.* If you build your Intranet site on Mongo, though, you don't need to distribute those changes in a way that gets back to upstream.

* I think. And I don't know if this has withstood the sort of court scrutiny the GPL has.

For the intranet site, I think you'd still need to make the source code available to users, who could then make the source publicly available.

IANAL, though, so I don't know if corporate policy forbidding this would be legal under the terms of the AGPL.

>I don't know if corporate policy forbidding this would be legal under the terms of the AGPL

Section 10 of both the GPLv3 and AGPLv3 prevent the imposition of "further restrictions" on the subject of the license.

I'm aware. What's not clear is whether applies to the individual components of an organization (i.e. its employees) or just the organization as a whole. I want to think the answer is that intra-organizational distribution still counts as distribution (and therefore cannot be restricted), but usually it's considered acceptable to use a modified version of (A)GPL'd software internally (i.e. not used outside the organization) without it counting as "distribution", so things are kind of fuzzy without explicit terms in that regard.

Such are the side-effects of treating organizations as singular entities :)

As far as I know mongo think they have solved this by providing dricers under a different licence.

Again, AFAIK, this licencing (AGPL + MIT/BSD or Apache) has not been tested in court.

And that would make no change for things like OSs.

If OpenBSD was AGPL and my ISP used it on all its network hardware with some custom modification, they still wouldn't be forced to contribute back those changes.

We need to stop making licences that attempt to force people to do the right thing, and start educating people to do the write thing out of free will.

> People that derive from GPL source have to release those changes to the public

This is entirely not true. If I take a GPLed application, download it, modify it, and never distribute it, then I am under no obligation to release the source.

People that derive from GPL source have to release those changes to the public

No, only to the people who have received binaries of those derivations.

    I don't think any even require that people distributing modified versions, send those modifications back upstream.

Copy Left licenses require those changes be shared on request. Which is pretty close.

Copyleft licenses require changes be shared on distribution, and only to whom binaries have been distributed.

Technically speaking, a license only has to require that changes be licensed under the same terms as the original to be deemed "copyleft".

The requirement to release source is specifically a GPLism and not part of all copyleft licenses. It's not infeasible for a copyleft license to imply "sure, it's legal for someone to create and distribute derivative works based on top of your modifications, but only if they have the technical skill to reverse-engineer it".

The Artistic License 2.0 (and possibly 1.0/1.1; I'm not as familiar with their license texts) specifies making changes available to the original author (without necessarily making them public) under the terms of the original license as one option for conditions by which one can use Artistically Licensed code (along with "give it a new name and don't interfere with installing the original version" and "release the source code publicly under a FOSS license", in that order).

TBH a single organization adopting and customizing a GPL software for internal usage isn't forced to contribute back, as GPL affects redistribution not adoption.

The only licence that will fix this is one that requires payment from users, and that's never going to happen.

Things like GPL don't force users to send back contributions unless you redistribute a derivate product (which is not usually the case). Theo is talking about giving something back (an acknowledgement, or even better, money).

Easy like that?

In general, the EU is _very_ strong on open source commitments. Almost all projects that I know of and some of which I'm working on funded as part of FP7 (Seventh Framework Programme) will eventually end up open-sourced.

Interesting! Could you elaborate some more and perhaps list a few projects, if you're allowed to?

I primarily know about the projects listed at https://www.fokus.fraunhofer.de/809f10db25eddf3e/projects A personal observation is that, nowadays, gitlab seems to be preferred to github as part of a push to rely more on software developed inside the EU (guess it's an aftermath of the whole NSA story).

PolicyCompass, for example, lives at https://github.com/policycompass

Carneades lives at http://github.com/carneades

MARKOS is up on SF http://markosproject.sourceforge.net/

GitLab CEO here, we indeed see more and more organizations starting to host their own GitLab server to become self reliant.

This has to be taken with a grain of salt. Frauenhofer in particular is rather "patent focused" and I think it carries over to their (there's a lot of Frauenhofers...overgeneralizing) general view on software. It's only anecdotal evidence from being at some research matchmaking events (Horizon 2020 etc.) and working in that field.

That being said OpenSource is explicitly mentioned in many calls. I'm mostly working on country specific calls but they are usually constructed similarly. OpenSource is often mentioned as a "potential use after the project" or a "result". Interestingly the provided headlines for calls will often read like this: "Potential use (for example OpenSource, patents, marketable product)" :D

+Actual software development usually isn't the goal of research projects. In the EU they use maturity levels (initially from the aviation industry I think) and it's quite a bit more "actual software/solutions" focused than the country specific calls (by design). Overall anyone who has worked in software development or even better at a startup would get a good chuckle out of these research funding events and the general process btw. (my personal opinion).

Just curious, is that software developed by consultants or by actual EU employees?

FP7 founds research projects, so we're mostly talking about research software which is usually developed by researchers.

Consultants essentially. There's also some IT development going on by actual EU employees, but the projects I listed above are usually won through tenders often submitted as a joint project by multiple companies/organisations (research partners - i.e. universities -, development partners - i.e. big companies - + public partners - often for demo purposes) although the EU also funds some purely research oriented projects of course.

Thanks for the answer.

I met a couple of developers employed and contracted by the EU / Parliament, I really don't want to generalise this but they did not seem the type that would work on such software that you linked to...or the type that would actually recommend OpenBSD..or even actually know what OpenBSD is.

Never heard of them. Neglected PR?

Those 3 I linked above are mostly research projects, all funded as part of FP7 and the EU doesn't seem to do much PR for those themselves.

I'd expect the upcoming (pan)"European Open Data Portal" to receive significantly more PR from the EU.

"the EU is _very_ strong on open source commits."

Had to re-read a couple times to get that right -_-

"said the great problem we would face is that companies would take our BSD code, modify it, and not give back. − Nope. We have many companies giving us code back, all the time." - Theo De Raadt

You could have easily taken the full quote -- it's not quite the contradiction you're trying to make:

"GPL fans said the great problem we would face is that companies would take our BSD code, modify it, and not give back. Nope—the great problem we face is that people would wrap the GPL around our code, and lock us out in the same way that these supposed companies would lock us out. Just like the Linux community, we have many companies giving us code back, all the time. But once the code is GPL'd, we cannot get it back."

>Nope—the great problem we face is that people would wrap the GPL around our code, and lock us out in the same way that these supposed companies would lock us out.

Does he offer any examples of this happening ?

That comment came about because of a licensing spat with the atheros source code.

http://undeadly.org/cgi?action=article&sid=20070913014315

It's worth remembering the full context to that incident. Earlier that year OpenBSD had been found to contain code that had been copied from a Linux GPL wireless driver project, in violation of the GPL. The Linux developers made a public mailing list posting about it and a lot of drama ensued:

http://thread.gmane.org/gmane.linux.kernel.wireless.general/...

Theo got very upset that the Linux devs practised 'full disclosure' over the violation and didn't contact OpenBSD privately (presumably he thinks customers who make use of OpenBSD should be fully informed about security threats that affect them, but not informed at all about legal threats that might put them at risk). He also tried to argue that the multiple commits over a period of time that contained copy and pasted GPL code was accidental, and got very upset when people suggested that one couldn't possibly accidentally copy specific portions of a GPL codebase and commit it to the repo multiple times. Theo also tried to argue that it wasn't a copyright violation since the code wasn't actually run-able (he knows full well that isn't how copyright law works).

The Linux developers response to that incident was also possibly partly motivated by earlier requests by some Linux developers for OpenBSD to dual licence portions of a different driver (i.e. also make it GPL). OpenBSD refused, for some of the reasons discussed already in this thread (they would likely receive GPL licensed changes that they would not be able to use). The strong reaction from the Linux devs was maybe to be expected after they had been told they couldn't use OpenBSD code, but then found OpenBSD had been stealing their code.

So there was a great big mess of egos and petty squabbling. I think a lot of that motivated the later copyright violations in the atheros drivers by the Linux developers that Theo is (rightly) complaining about above.

The point I think Theo is trying to make is in the open source world you simply have to expect that people will take code - put it under a different licence and modify it - restricting their ability to take back the modified code into OpenBSD.

Typically OSS licences allow and tolerate "selfish" behaviour. I don't think I or he needs to back up this claim with examples.

>that people will take code - put it under a different licence and modify it

Ok, although the 'take code and put it under a different license' is untrue, you can't re-license code unless you are the copyright owner, I gather that he means someone making modifications/enhancements and placing them under a license which OpenBSD can't use while remaining fully BSD licensed.

This happened when Apple adopted pf they added a few enhancements of their own but wrapped them in Apple's license so pf maintainers could not add the changes back into upstream pf.

This also happened with Linux's Atheros drivers (which were derived from OpenBSD, but modifications were published under the GPL instead of the BSD or ISC licenses; Theo argued that doing so was actually a violation of the BSD license (apparently they were stripping out the BSD license in the actual source files? I'm fuzzy on the details)). I don't remember what the outcome was.

> once the code is GPL'd, we cannot get it back

I don't get it. Can't you retain copyright to code you yourself release under GPL and also use it under a different license or as part of closes source software? As far as I know, you can...

Let me rephrase the quote for you: "once the code is GPL'd, we cannot get the modifications back"

That's what he meant. Look at the full context.

And you can from proprietary licensed modifications?

FSF recommendation is that you use the same license as the project which you are contributing to. If you use a BSD project, contribute your patches under BSD. If its GPL, contribute under GPL. If you combine work under BSD and GPL and write modifications, contribute back the modifications based on what code you are doing modification for.

The proprietary way is to release modification only if its make a business sense to do so, and I don't know if OpenBSD actually has a official recommendation in this aspect. If they do, its not something I have ever seen.

That's not the point. Let me rephrase that:

- one of GPL's cool thing is that it prevents proprietary software from including GPL'd code without contributing back to the community

- Because BSD is not as strict as GPL regarding license derivation, GPL says "BSD is bad, you're allowing proprietary software to use BSD code without giving back"

- Some people take BSD code, modify it and distribute modifications under GPL

- Because of this, the original BSD code authors can't benefit from the modifications, only GPL projects can... doing exactly what GPL was against in the first place (preventing authors from enjoying modifications)

Theo is only pointing out the irony of it all.

> exactly what GPL was against in the first place (preventing authors from enjoying modifications)

This is not an accurate description of what the GPL is shooting for, which has significant consequences on the things built up from this misunderstanding.

You're right, it is important to remind that GPL is shooting for user freedom, and final users getting free access to modifications; that authors enjoy modifications is only a nice side-effect that isn't even required at all, but is in practice common. The misunderstanding seems to be from the clear separation between users and developers that GPL does.

One could argue that the they can get the GPL project, build over it too and distribute it.

Not much a comparison to proprietary software.

But then they would not be free to use the BSD license, they would have to use the GPL license. If you were able to take a GPL project and "wrap it" in a BSD license, then you would be taking away all of the GPL restrictions effectively rendering the GPL null and void. Do you really think that it is that "easy" to skirt the GPL? What point is the GPL if all you need to do is "wrap it" in a BSD project and then everything becomes BSD licensed?

I guess that other way that I could interpret your response is that you are suggestion that the BSD people should just relicense their stuff as GPL to be able to use GPL'd project. This really ignores the points being made (if this is what you are saying).

You can ask all copyright holders of the code since the code was GPL'd to relicense the code under a different license (BSD presumably). If only one declines you can't use their code and anything based on it.

I responded to the statement that Theo De Raadt is always complained about people not contributing back. The rest of the quote, including the "GPL fan" and "we cannot get it back" is only leading to the regular flame wars and do not contribute to the question: Do Theo De Raadt always complain about contributions? Yes, No?

I dislike labeling like BSD fanatics, BSD fans, GPL fan, and GPL fanatics. Neither contribute to clam and reasonable discussion. Thus I did not include it.

I also find the implied statement that proprietary licensed software can be relicensed by anyone to BSD to be very misleading and wrong. If a author who license something under a proprietary license later decides to relicense part of it under BSD, then a author of GPL licensed software can equally do so to part of their code. The BSD author has as little entitlement to proprietary changes as to GPL changes.

If so, then the issue is they don't contribute money?

That used to be a case for a very long time but it is _slowly_ changing. We still mostly rely on contributions by individuals.

> an EU BSD fork

Why fork it? That is completely stupid. Do you want to have the EU version of North Korea's Red Star Linux? Do you want to make it so Google doesn't work properly on EU BSD?

The EU is not North Korea.

A fork would make sense if the EU puts enough man-power into the project and they don't agree with the current leadership.

The idea of a EU BSD fork sounds terrible. What needs to happen is government funding for key open source infrastructure projects that require it like OpenSSL, OpenBSD, GnuPG, etc.

> I like the sound of an EU BSD fork - hopefully they fund one. We've always been lacking in the Operating Systems dev department over here in Europe.

There's no need to fork and split manpower, you can contribute to OpenBSD being in Europe.

minix is/was sponsored by EU http://wiki.minix3.org/doku.php?id=www:documentation:read-mo...

Link to Part 1 of the study (wherein the recommendation lies):

http://www.europarl.europa.eu/RegData/etudes/STUD/2015/52740...

Part 2 of the study recommends government funding of Open Source Projects:

http://www.europarl.europa.eu/RegData/etudes/STUD/2015/52741...

Potential and actual conflicts of interest between governments and citizens in regard to privacy are not addressed.

They don't address conflicts of interest but it seems like they're fine with privacy:

"[...] the use of open source computer operating systems and applications reduces the risk of privacy intrusion by mass surveillance.

They seem to be touting that as a benefit, not a drawback.

When the same governments are funding signals intelligence gathering with one hand and open source software development with the other, there is potential conflict of interest, if not actual conflict.

The NSA's role in weakening open source encryption standards was the result of the internal logic by which all intelligence organs typically operate irrespective of sponsoring state. The differences between the politics of some EU states and the politics of the US or Russia or the UK don't change that internal logic of intelligence organs. Their job remains to maintain data collection capability.

If there's one kind of entity that can finance attacks and the dissemination of defenses against those attacks without any kind of internal conflict, it's a government.

That kind of logic holds for individuals, corporations, and single organizations inside a government. But modern governments are explicitly designed to be internally conflicting, and that's universally thought as a good thing.

And with OSS we can see when the create back doors or modify the code. We can see what the modifications do. And if they are doing anything wrong we can revert the changes and publicise it. Following on from your thinking, what is their angle here? On the surface it seems more difficult to exploit OSS but is there something they can do with it that users won't know about and is easier to exploit?

Subtle security leaks are not in the center of the all-bugs-are-shallow theory. Cryptographically insecure communications don't cause code to throw exceptions or systems to crash. The effects are social. Unless Eve tells Alice or Bob, neither will know she's read their communications.

Also not addressed: potential and actual conflicts between governments and Theo De Raadt. Remember that OpenBSD used to be funded by DARPA.. used to: http://en.wikipedia.org/wiki/Theo_de_Raadt#DARPA_funding_can...

Support OpenBSD, but NEVER fork it..

http://www.openbsdfoundation.org/

http://www.openbsd.org/want.html

http://www.openbsd.org/donations.html

https://www.openbsdstore.com

     Nice to see recognition from the trenches of bureaucracy.

It's really nice that they can write such statement.

Kudos to the OpenBSD team!

I like OpenBSD. I like the spirit of the developers, which don't compromise on security. I like the simplicity of the OS, very good documented and very robust. They are prepared to break a ton of software to advance the state of security/correct code.

I would like to have OpenBSD on all my machines, but unfortunately their license don't have the "infectious" effect of GPL. From my limited understanding, their license[0] is not a philosophical license like GPL. Linux popularity spread because of the distributed development style(everyone developed in their own tree, Linus decided if it had enough value to get in his tree) and GPL.

Even if you don't care on the philosophy of GPL, you can't deny that it helped make a lot of vendors to publish(even if half-hearted) their code which eventually after some cleanup(3rd party or themselves) got into the Linus tree.

If OpenBSD would be GPL licensed, I could see a BSD which would be have all the bleeding edge features, but Theo's tree was separate, conservative on features but not lacking on drivers. Men can only dream.

I realize that FreeBSD is the bleeding edge of BSD land and I'm not trying to start a license flamewar, but a lot of companies, i.e. graphics, wireless cards, laptop manufactures don't have (good) working drivers for BSD land, at least not published code which goes back to the community.

[0] - http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/misc/lice...

While it's true that the GPL and the distributed nature of Linux development helped GNU/Linux proliferate, that isn't the reason why the BSDs didn't. In reality, they were encumbered by legal problems due to being derivative works of AT&T's Unix; the ensuing legal war of attrition caused a lot of folks to be unsure of whether or not they could legally use any of the BSDs without having to pony up for Unix licenses.

As a result, Linux was created (Linus Torvalds has said that if Hurd existed or if the BSD legality issues were resolved, he wouldn't have felt the need to develop the Linux kernel), and folks jumped onto that as the preferred free Unix due to it being unencumbered by the massive legal warfare taking place in BSD Land (of course, SCO would eventually bring the battle to the GNU/Linux world, but by that point, Linux was already well-entrenched).

It depends on what you're after, but in some respects I think Dragonfly and NetBSD are bleeding edge in their own ways (filesystem, VM subsystem, networking)

For those that know more about OpenBSD than the EU (and I salute you for it), the EU parliament is a fairly powerless institution. Eurocrats show it little respect; one described it as "just one big fucking NGO".

Update after reading it: this isn't even an official parliament document or recommendation. It's something by the parliament's research service.

> the EU parliament is a fairly powerless institution

This is certainly not true. Thanks to the EU parliament the IT freelancers in the EU don't need to suffer software patents.

The Eurocrats did everything to invent it some years ago, even with dirty tricks (like pushing it through immediately before summer vacation). We IT freelancers contacted politicians of the EU parliament, told them about our concerns, and they actually supported us.

I remember the victory celebration at heise.de (a leading IT newsticker in Germany). Usually there are about some hundred comments per hot thread but in this case it was more than eleven thousands.

Politicians in EU and US call various institutions a "NGO" when they disagree with it and want to ridicule it to intentionally reduce its public reputation.

EP is a high reputation organization and has force within the EU structure. Calling an EPRS study "something by the parliament's research service" is not only redundant (EPRS = European Parliament Research Service) but also short-sighted (do you do the same thing to the deliverables by your R&D department?).

So, this is an EP study that you can cite in order to support your arguments for switching to free software in your government / school / workplace / home / hobby group.

I wasn't dismissing the study's quality, just saying that this is not necessarily going to lead to any change in policy (e.g. all EU computers mandated to run OpenBSD).

> all EU computers mandated to run OpenBSD

That kind of social change would require a change in the econo-political system.

I think mandating all EU computers to run _anything_ would be a very bad idea.

> the EU parliament is a fairly powerless institution.

Nope. The EU Parliament (elected), the Commission (periodically nominated by national governments) and the Council (meeting of national governments) are the three "heads" of the EU political system, and they are locked in a constant struggle to determine the exact boundaries of their powers. The Parliament is the youngest institution, hence the historical disregard of entrenched interests; at the same time, it's the institution most hungry for power, because it's the only one with a clear democratic mandate.

As others mentioned, software patents were a battlefield for such struggle: the Commission repeatedly recommended their introduction (IIRC, at the behest of a certain Microsoft-friendly Irish commissioner), and the Parliament repeatedly sent them packing. You will find several other instances of this happening: the democratic mandate of the EU Parliament in most cases will eventually trump backroom agreements in the Commission, as long as the topic becomes mainstream enough to invoke such mandate.

In future, the institution that is destined to become more and more powerless is one between the Council and the Commission, since their scope overlaps now that the Parliament has taken over the "legislative" process earlier left to the Commission.

I don't know about that. It's the EU Parliament that comes up with most of the new EU-wide directives. It's the EU Parliament that defeated ACTA, while the EU Commission was trying its best to pass it. The Commission is generally much more prone to lobbying influence, and perhaps unsurprisingly it also tends to be less democratic as a consequence. The new Commission might not be as bad as the previous one, but it's still too early to decide.

On HN, "the EU" is a fictional European entity which can be anything people want it to be depending on the argument they're trying to make.

Excuse the snark, but the wilful ignorance concerning the EU and Europe in favour of ideological posturing makes it near impossible to discuss most relevant topics.

Starting with a somewhat misleading headline doesn't help.

Between the lines of your comment is a lot of disregard against the EU and the EU parliament. How come so?

The EU also funds Minix 3 development, though that is more about reliability than security.

The thing about security is that it touches everything.

Ease of use? If something's hard to use, it's easy to confuse people into doing insecure things. Security issue.

Unreliable? Security depends on predictable behavior, and failure modes are often unpredictable. Security issue.

Proprietary protocol? Even if it wasn't intentionally backdoored, you don't know its real attack surface, because you don't know all of the verbs it contains. Verbs imply actions, actions imply changes of state, changes of state imply the Dark Side... uh, security concerns. Security issue.

Performance? Even aside from timing attacks and simple DoSing, things often behave oddly when pushed to a limit, especially if that limit involves otherwise-hidden race conditions. Security issue.

The pypy project also benefited from EU grants early in its history.

Not anymore. The money from those grants is gone.

The study also recommends Qubes and Tails.

I love openBSD, it's implementation of certain things is slower (like networking), but it's so clean and well implemented.

even if it doesnt' get to play with all the toys (like ZFS) it's what I'd love to default to for application servers/bastion server/firewalls etc;

my only qualm with it currently is it's reliance of X11 for ports to work- I don't like install X11 libs on my servers wherever I can avoid it. :\

> my only qualm with it currently is it's reliance of X11 for ports to work- I don't like install X11 libs on my servers wherever I can avoid it. :\

Can you give a reference to this? I'm not doubting you, as I always install x11 anyway, I just didn't know this was still the case. I remember an issue with a lib in xbase.tgz a few years back that was required by lots of ports, but I thought they moved it to base.tgz.

Thanks!

http://comments.gmane.org/gmane.os.openbsd.ports/54692

http://www.openbsd.org/faq/faq15.html#NoFun (at the bottom of this section)

Good call. I was thinking packages in my head despite you specifically referring to ports. Thanks for following up!

To be fair I have this problem on Debian too. Sometimes there is foo-nox, the foo version without X dependencies, but I seem to find myself building such packages for myself to omit some afterthought GUI bit which drags in Qt, gtk, or half of the gnome universe for no reason.

At least with packages, there are "no-X" versions of most packages available (useful if you don't have X on a machine).

the problem isn't that it's dependant for X11 on packages.. moreso that the port system requires X11 to function..

http://comments.gmane.org/gmane.os.openbsd.ports/54692

http://www.openbsd.org/faq/faq15.html#NoFun (at the bottom of this section)

Ah, I see.

My point about packages still stands, though; I don't use ports on my OpenBSD servers (since it's much easier on server load to just download/install a package than to try to build things from source; well, that and the lack of a need to install a whole lot on an OpenBSD server besides a runtime for $SERVER_PROGRAMMING_LANGUAGE, but whatever). I suppose if you're particularly paranoid about downloading things from the internet, you could build packages on your personal workstation with the necessary env vars to disable X11 support in the package, then move those packages over to the server and install them there (basically, doing what OpenBSD's ports/packages maintainers already do in order to create the packages in the first place, but on your own).

> "It is recommended that users install ..." OpenBSD?

The EU isn't serious if that's what they mean. It's not really an option for end users. My impression is that even technical users who are new to *nix should start with something more accessible.

Does the OpenBSD community even want to deal with a flood of nubes?

Didn't everyone recommend Linux and Mac OS back when vulnerabilities on these systems just hadn't been discovered (or possibly written) yet?

Make OpenBSD popular, add a ton of devs, and attack value, and I'm pretty sure these problems will repeat themselves.

I think the second study, which briefly names OpenBSD, does a good job of pointing out that technological changes alone are insufficient.

Yes, and a Brinks armored truck is just as vulnerable to carjackings as a Ford Pinto, we just don't know about the vulnerability because nobody drives them.

People were saying the same things about Linux. In the late 1990s and early 2000s. By which time Linux had already become the de-facto go-to OS for web servers around the world. It was, in short, already a high-value target, and yet the apocalypse didn't occur.

Of course that's true. I'm just not convinced that OpenBSD : Linux :: Armored truck : Pinto.

In fact, the point of a good portion of the second study [1], p.17-25 is pointing out the flaws that have occurred in the Linux operating system and other existing technologies.

[1]http://www.europarl.europa.eu/RegData/etudes/STUD/2015/52740...

I never claimed Linux was a Pinto. My point is, some things are just built well, and even if they're not used very often we can expect a certain level of quality, as opposed to saying that the only reason we don't see them stolen is because so few people drive them. Especially if they're used all the damn time, just not in places people see a lot.

So some bugs will be found in OpenBSD. That's a given. However, it isn't like OpenBSD is never used, or that the people who made it are bad programmers.

Yeah, I agree 100% :-)

I guess what I'm saying is that it would make more sense to me if OpenBSD and Linux were both on the list. As you also mentioned, flaws existing in programs is inevitable, so unless the defect rate, normalized for usage, is significantly higher in one case, it's not good evidence for the quality or security of one over another.

In OpenBSD's case, the defect rate's pretty low, even when normalized for usage. It's had, what, 2 significant security bugs (that actually compromised the security of the base installation) over the last 2 decades or so? Pretty damn good if I may say so myself.

Well there's the difference that security is basically the core focus of OpenBSD's development, and the project actively researches and updates development practices with that in mind.

OpenBSD is already quite popular. It runs on plenty of routers. Routers have very high attack value.

"[...] the use of open source computer operating systems and applications reduces the risk of privacy intrusion by mass surveillance. Open source software is not error free, or less prone to errors than proprietary software, the experts write. But proprietary software does not allow constant inspection and scrutiny by a large community of experts."

That worked great for OpenSSL didn't it? ;)

Microsoft has had 2 Heartbleed-level vulnerabilities in its Windows code so far, that were not just 2-3 years old but 10+ years old, leaving systems vulnerable to them for much longer.

The "advantage" of proprietary code here was that Microsoft got to downplay them (surprise surprise, no scary logo made by Microsoft for them!), and that's how proprietary code owners deal with security issues in general - they try to hide that they exist to keep the illusion that the software is (more) secure.

This is the second time today you've spread innuendo about how software security teams at big companies handle vulnerabilities, and the second time you've managed to casually insult teams that include some of the best software security people in the entire industry.

Here's the first:

https://news.ycombinator.com/item?id=9445436

These are egregiously bad arguments you're making, involving people who you don't know but that, from my experience reading so many of your comments, I believe are operating many levels above your own comfort level with actual software security.

The trouble is, like me, you comment on HN all the time, and so, like me, you get a huge name recognition boost for these comments you make. People reasonably believe that you know what you're talking about when you "explain" to them how Apple and Microsoft handle vulnerabilities. But you don't, and so these misleading comments prey on their lack of information.

Are you contesting the fact that Microsoft downplayed some of its major remote code execution vulnerabilities or that Microsoft has been sharing zero-days with the NSA for years (and now Apple is doing the exact same thing - voluntarily)? I can come back with sources, but I think you know exactly what I'm referring to.

Maybe I painted with a too wide brush the "proprietary software teams pretending the vulnerabilities don't exist", but the "security through obscurity" expression didn't just come out of nowhere. Many proprietary software companies do try to hide or downplay their security holes when they happen - you can't seriously tell me you you're contesting that?

He is actually more or less correct in the case of both Microsoft and Apple.

You know that's not true.

I know it is true, and I know you probably know people who work(ed) there, and they'll confirm it. This isn't because there aren't good security people who want to do the right thing, it's because management and PR doesn't support it.

You'll notice that the recent TLS bulletins were the only ones to credit an internal finder. There's a reason for that, and it's not because MS people aren't finding vulns in their own software.

You're here arguing that Apple traded zero-days to NSA in order to get Apple Pay contracts with USG. At what level am I supposed to take this thread seriously?

My issue is that the comment that roots this thread is, as you discreetly agree, totally uninformed, yet written in a tone suggesting direct knowledge of how vulnerabilities are handled at big software companies.

If you want to discuss the subtleties of internal vs. external reporters, patch timelines, prioritization, pre-disclosure, and things like that, I'm up for it, but not until there's clarity about what --- let's call it: --- "the HN community" --- does and does not know about this stuff.

I am fine with random commenters on HN talking about vuln disclosure without ever having reported a vulnerability or triaged a report. I don't think our having spent so much time with those things makes us special. I am less fine with people pretending to know things that they don't, or, to be as charitable as I can, writing comments that carelessly create that impression.

What? No. Hah. That comment is indeed ridiculous, and isn't the one I'm agreeing with. That appears to be a different thread. I'm only referring to:

Microsoft has had 2 Heartbleed-level vulnerabilities in its Windows code so far, that were not just 2-3 years old but 10+ years old, leaving systems vulnerable to them for much longer. The "advantage" of proprietary code here was that Microsoft got to downplay them (surprise surprise, no scary logo made by Microsoft for them!), and that's how proprietary code owners deal with security issues in general - they try to hide that they exist to keep the illusion that the software is (more) secure.

Related to the other claim, I'm fairly certain that the NSA does get pre-disclosure of MS vulns via MAPP, but it's pretty obvious that this is a side effect of disclosure complexities and not a quid pro quo deal. China also gets the same pre-disclosure, or did, until they got caught leaking it. But they probably still do, one way or another.

I'm actually laughing out loud at the Apple Pay in the USG thing.

I don't think it's that funny anymore. It's funny until you realize lots of readers believe him.

If you want to roll the discussion up to the original claim on this thread:

* Yes, closed-source vendors, Google included, do not as a rule announce severe flaws they find (or contract to find) in their own code. On the other hand, when we're talking about Google, Microsoft, and Apple: they are actually finding sophisticated flaws in their own product, which is something very few open source projects can credibly claim.

* Open source projects are not as a rule particularly awesome about handling disclosures either. See, for instance, AFNetworking.

* Nobody made logos for HTTP.sys (that I know of). On the other hand, HTTP.sys was a bigger deal in the industry than POODLE or pretty much any other vuln with a name besides Heartbleed, which, because it implicated a library used by lots of products, was particularly prevalent among Internet SAAS sites, and was easier to quietly exploit than an RCE, was a legitimately more important flaw. The idea that Microsoft gets a free pass for vulns is something you can only believe if your only contact with them is HN.

* There's no evidence Microsoft hid those vulnerabilities. They were there for 10+ years because nobody found them. In Microsoft's case, you can't reasonably claim that's because they weren't looking. Minesweeper gets more pentesting effort at Microsoft than most open source crypto projects.

I strongly prefer open source software to closed-source software, but I'm not unrealistic about how open source security works. See security tire fires such as: OpenSSL, Rails, PHP, Cryptocat, BIND --- each distinctive not just for having vulns but for the manner in which they've historically handled them.

The above comment isn't attacking "teams with great software security people" but the fact that in proprietary software people can and do downplay vulnerabilities (not a very controversial statement).

I've noticed tptacek over the past few years that your comments have shifted from great general security advice to more defending "the security profession". Please consider this shift and whether it is helpful.

Is your assessment that "in proprietary software people can and do downplay vulnerabilities" based on looking at HN/news stories, or based on directly interacting with security teams at those companies?

In my experience, the worst security offenders are either small businesses or big businesses whose core competency is not in tech. My friend managed to download 50,000 passwords from GreatestJournal.com because they left their MySQL server exposed to the Internet, with no password, and the open-source LiveJournal code stored passwords in plain text in the DB. He reported the vulnerability to them, and their response was to put a password on the MySQL server (and take it off the Internet a few days later), write a blog post saying "You may want to change your passwords if you reuse your GJ.com password on other sites", and then take down that blog post a couple days later.

By contrast, when I worked at Google, a security bug was a drop-everything P0 bug. I recall grabbing dinner at In'n'Out at 11:00 PM because a potential data leak was discovered at 6:00 and the culture is such that when a potential security bug is discovered, you drop what you're doing, assess the impact, fix it, and don't do anything else until you've done that. And I didn't work on a security team, just an infrastructure one responsible for google.com.

Google is the exception. Most major closed source vendors, even those known for their security, hide vulns that were not externally reported.

If tptacek's attitude has shifted, it's probably because the prevailing attitude on HN has shifted as well, in the direction of "never have people cared so much yet known so little".

What on earth is HN sheep's obsessions with making logos for security bugs? This seems to be a very new phenomenon that the young upstarts expect to see when a big bug is found?

This has nothing to do with Microsoft. It is about a false assertion (i.e. OSS peer review leading to less bugs) made so fleetingly that the authors clearly expected it to be accepted by readers as a proven fact. It isn't proven. And I gave just one of countless examples why OSS peer review has proven itself to not necessarily work as one might naively expect it to.

Yep, the issue was fixed (even though it took a while).

And by "a while", one means "a few days after discovery" (a few months after it was introduced, but that's actually not terrible, all things considered).

Fact check: It was introduced years priors to discovery, not mere months.

Thanks for the fact check!

Looks like it was indeed committed to OpenSSL about 2 1/2 years prior.

Reply on news.ycombinator.com