Hacker News new | ask | show | jobs
by burntsushi 2073 days ago
Just to pop up a level here, we're moving beyond my initial argument with the top poster here I think. I took issue with saying that it was "common sense" to use a license that prohibited things you didn't like. My argument is that you might actually intentionally not do that because there is nuance here that common sense shouldn't and couldn't paper over.

> Why do you not just pick a license that forbids uses not compatible with your ethical standpoint, and chose to just not enforce the terms should they be violated? This way, companies are likely to respect your intent and preference and you don't have to make use of a legal system you don't support.

I think that leads to a lot of grey area in terms of what people are and aren't allowed to do with my code. It also kind of presumes that I would ever try to enforce anything, which is itself not just an ideological decision but a decision to be made in light of costs and resources and will.

Since we're now getting deeper into what I personally do, I'll note that in practice, I dual license under the UNLICENSE and the MIT. I use the UNLICENSE because it's goal is to explicitly disclaim monopoly copyright interest while attempting to be a public domain dedication. I also add the MIT because some folks stopped using my code when I only used the UNLICENSE because they were too risk averse and wanted a more established license.

2 comments

> Since we're now getting deeper into what I personally do, I'll note that in practice, I dual license under the UNLICENSE and the MIT. I use the UNLICENSE because it's goal is to explicitly disclaim monopoly copyright interest while attempting to be a public domain dedication. I also add the MIT because some folks stopped using my code when I only used the UNLICENSE because they were too risk averse and wanted a more established license.

As an aside, an alternative to this dual licensing might be the 0BSD license: http://landley.net/toybox/license.html

It's on spdx: https://spdx.org/licenses/0BSD.html

It's approved by OSI: https://opensource.org/licenses/0BSD

Available on choosealicense.com: https://choosealicense.com/licenses/0bsd/

Unlike the unlicense, google allows it: https://opensource.google/docs/patching/

Firstly, I am sooooo over Google's open source policy. I'm thankful that they document it, but it's just plain annoying.

Secondly, I use the UNLICENSE because it is an ideological statement. The 0BSD is not. Dual licensing with the MIT gives me a very small activist voice while also providing a practical option for the risk averse Googles of the world.

> I took issue with saying that it was "common sense" to use a license that prohibited things you didn't like

Not a good characterization of the argument. It's a matter of negative rights vs. positive rights. The original commenter's argument was cogent.

In copyright, the default is that no one has rights to your creations but you. In licensing it as open source, you're broadening what others can do with it. It's an active choice. If granting someone X could result in them doing X where they otherwise wouldn't, and you'd be uncomfortable with that, then don't go out and invite people to do X.

The hackneyed "common sense ain't so common" aphorism is certainly something to avoid though.

I don't see how that's not a good characterization. That's almost literally what was said:

> Yes, folks, if you don't like the idea of a corporation taking your ("software-as-a-service") code and using it to create and sell proprietary products, then maybe don't license your code under the MIT License (or any of the others which explicitly allow exactly that)!

As for:

> In copyright, the default is that no one has rights to your creations but you. In licensing it as open source, you're broadening what others can do with it. It's an active choice. If granting someone X could result in them doing X where they otherwise wouldn't, and you'd be uncomfortable with that, then don't go out and invite people to do X.

Well, I don't think giving people a legal grant to do X is inviting them to do X, especially in the context of permissive licenses or public domain dedications. Otherwise, you could accuse me of inviting people to do X for any value of X, no matter how pernicious.

> I don't see how that's not a good characterization.

For the reason just stated:

"It's a matter of negative rights vs. positive rights."

You're say the license prohibits certain things, which isn't true. It's copyright law that prohibits, by default, almost everything. Choosing a public license to make something FOSS is an active choice that selectively enables more use for people who follow the cultural and legal patterns you do like. That a person while doing so doesn't also enable even the uses one doesn't like is not what you're characterizing it as: an active effort to prohibit those things. Wide open, MIT-like permissive reuse is not the default.

I don't see what the "default" has to do with what I'm saying. That's just an artifact of the US's backwards intellectual property legal system. It has nothing to do with positive vs negative rights.

Bottom line is that laws and ethics aren't the same. A legal grant to do something (even if it isn't the default) doesn't constitute an invitation to do something unethical.

And I stand by my characterization. The parent post was literally talking about prohibiting things one doesn't like.

> I don't see what the "default" has to do with what I'm saying.

Indeed. Based on your other comments in the thread, it looks like you're committed to not understanding.

> The parent post was literally talking about prohibiting things one doesn't like

The parent post was literally talking about not talking extra effort to whitelist things they don't like. There's a real difference between that and what you're saying, and whether you want to acknowledge it or not doesn't change whether that distinction exists.

> it looks like you're committed to not understanding

Ah okay, so you're troll. Please don't bother communicating with me in the future.