Sounds like he needs a different license then.
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."
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.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)
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.
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.
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.
* 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.
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).