Hacker News Reader

Comment by kimixa | Hacker News Reader

So many times I've seen people complain about situations that would have been solved by choosing the license that actually matches how they intend others to use their work.

Some engineers seem stuck to the idea that if they choose a permissive license, people will still contribute back for some idea of "community" or "goodwill" - while really the license itself is the declaration of expected behavior.

By choosing a license, you're explicitly setting how you intend that code to be used - if you want don't /really/ want other people to monetize your work with no feedback, for example, that is what the license is for. If you don't want people to "leech" on your work, then choose one of the (many) licenses that disallows that.

View on HN

This might not be charitable, but my perspective is that some of the advocates want it both ways.

I would be interested in seeing an MIT/BSD licensed project saying, from the beginning, something like "This project is available under a permissive license, but I have a strong ethical expectation of my users to give me money if they build a product off of this work. I am fully aware that I can't legally enforce this, but I will certainly call you out publicly for your greed and lack of respect for my wishes."

My hunch is that many advocates would hesitate to put this in their project Readme, because they know that some companies might actually comply... by not using the code. (Call me naive but I think this is plausible.) They would rather give the impression that the code is truly no-strings-attached, because that would help drive adoption. Then later they can come back and say they ought to be given a cut.

> My hunch is that many advocates would hesitate to put this in their project Readme, because they know that some companies might actually comply... by not using the code.

Definitely. And not only companies; even Debian rejected some packages because the upstream owners added restrictive "desires" on top of the actual licenses.

Yep. And the reality is that 99.99% of open source is driven by a single contributor. I used to live in the open source world and talk with companies who were thinking about releasing something as open source and the biggest myth I had to disabuse them of was the idea that lots of contributors would show up to work on the code. In rare cases with high value projects that does happen, but mostly not. Honestly, GitHub was the best thing to happen to open source because it made it much easier to get the code and create PRs. In the old days, you had contributor agreements, emailed patches, etc. The bar was a lot higher for a contributor.

These days I honestly suspect tons of people do not think about the license they choose for their projects AT ALL and just reflexively put MIT. Like, if they were sleeping and you prodded them and said "license", they would mumble "MIT".

Yeah, and this is blatant when it is VC startup type stuff. But on the other hand you have say Redis, which seemed to be just some legitimate OSS cool but boring infrastructure for a long time, patches welcome. And then it becomes some VC 'cloud solution'. And everyone has to adapt (or pay).

Reply on news.ycombinator.com