Sounds like he needs a different license then.
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."
Asking people to consider it is the right thing to do. Switching license would defeat the entire point.
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.
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.
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.
(Now this makes me wonder how to book the use of open source software in management accounting)
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.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.
"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.
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.
Google should require in the vendor license terms for the Android brand and the Play Store that the sources be released on Github.
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...
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.
* I think. And I don't know if this has withstood the sort of court scrutiny the GPL has.
IANAL, though, so 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.
Such are the side-effects of treating organizations as singular entities :)
Again, AFAIK, this licencing (AGPL + MIT/BSD or Apache) has not been tested in court.
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.
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.
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.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".
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).
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/
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).
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.
I'd expect the upcoming (pan)"European Open Data Portal" to receive significantly more PR from the EU.
Had to re-read a couple times to get that right -_-
"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."
Does he offer any examples of this happening ?
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.
Typically OSS licences allow and tolerate "selfish" behaviour. I don't think I or he needs to back up this claim with examples.
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.
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...
That's what he meant. Look at the full context.
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.
- 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.
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.
Not much a comparison to proprietary software.
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).
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.
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?
A fork would make sense if the EU puts enough man-power into the project and they don't agree with the current leadership.
There's no need to fork and split manpower, you can contribute to OpenBSD being in Europe.
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.