Hacker News Reader

Comment by s_dev | Hacker News Reader

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.

View on HN

> 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.

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.

> 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.

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.

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

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.

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

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).

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."

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.

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.

    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.

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.

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.

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.

Easy like that?

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.

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.

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).

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/

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

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.

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

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

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.

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).

"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

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.

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 ?

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.

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.

> 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.

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).

> 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.

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.

> 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...

Reply on news.ycombinator.com