Comment by jordigh | Hacker News Reader

Comment by jordigh | Hacker News Reader

While I appreciate the intent, patents are complicated, and the reason more complicated and weak licenses like the Apache license version 2 exist are precisely to address the complexity of patents.

Software nerds don't like complicated licenses just because they're not lawyers, but legal complexity is inherent in human affairs and cannot be simplified too much. The shortest license isn't necessarily the most desirable one. Writing a new license just because the Apache license is tl;dr is just not a good idea. Saying that you'll just ignore the law because you disagree with it will actually probably work out for a while until you're big enough for the law to no longer ignore you in return.

We've had amateur licenses written many times before. GPLv1 and the first Perl license are examples. They both had to be rewritten once someone who actually knows law looked them over.

In other words, kids, don't try this at home. There are professionals who can do this for you.

Totally. And if it's a terrible idea, then it will die a quiet death, and that will be fine. But there's a little more here than just "don't try this at home."

The Apache license is a wonderful license. If you want to use it, you absolutely should use it.

But people don't use it. They prefer to use something they can understand, something that doesn't have to be interpreted by a legal team, and something that they can feel comfortable imposing on the users of their code.

According to a 2015 survey conducted by Github, MIT and BSD simple licenses are nearly five times more often used than Apache. Out of the top ten most starred open source projects, nine of them use MIT/BSD, and only one uses Apache.

Clearly, there's a desire — in the actual practice of sharing open source — for something that explains your legal and social obligations in as plain an English as we can muster, while still being crystal clear in legal terms.

I'm pretty sure that's because Github encouraged, and to some extent still does, for people to completely ignore licenses. This attitude spreads and explains why people want the least amount of license posible.

The solution isn't to make licenses more "user-friendly". That user friendliness can be a dangerous illusion. The solution is to not forget the legal lessons that we already lived back before free software was renamed to open source in 1998.

Github is fairly aggressive these days about alerting you to put a standard license in your repository.

But they still remain with the problem that most folks choose the user-friendly MIT (I would, and 9 out of 10 of the top projects do). This leaves them with an issue: It's not clear that contributions submitted to an MIT project grant permission to incorporate those contributions under the same terms. We understand it socially, but it's not legally explicit.

Github has been trying to address this in their Terms of Service, by saying that simply by using the site, you agree that "inbound=outbound": https://help.github.com/articles/github-terms-of-service/#6-...

But the Github TOS isn't really the right place to be legislating that. For more, see: https://writing.kemitchell.com/2017/02/16/Against-Legislatin...

> It's not clear that contributions submitted to an MIT project grant permission to incorporate those contributions under the same terms. We understand it socially, but it's not legally explicit.

Given that GitHub works only through forks and pull requests, this is not a problem. There are two repos A and B published under the MIT License. There is no need to address what happens when the contributor behind B sends you a pull request. (There is no need for contributor who published B to even send you a pull request; in theory, you could "reach over" and start incorporating anything from B into A without any participation from the person behind B—just like you [probably] did with all your vendored libraries.)

Worrying about this is one of the cargo cultiest memes, second only to all the videos on YouTube who think they're protected by a notice that says, "I don't claim ownership of this video; all rights belong to X".

For those of us that may have never learned those lessons, could you perhaps share what they were?

Basically, (1) software licenses matter, if not not today then tomorrow, and (2) just because you think the language sounds clear doesn't mean that a judge will agree with you.

You can also see this in the evolution of several licenses that have gone through more than one version. While I really hate comparing software to licenses, think of those as "bugfixes" (or perhaps, warnings to others of bad example licenses). I already gave GPLv1 and the original Artistic License as what not to do; Apache v1 is another example because of patents.

"back before free software was renamed to open source in 1998"

That's an interesting reading of history, and one that the creators of the terms "free software" and "open source" would probably both vigorously dispute.

The creators of both terms agree. I asked them:

http://jordi.inversethought.com/blog/5-things-we-have-forgot...

And here:

https://opensource.org/faq#free-software

The "creators" are interested in securing their legacy. The term "open source" was in use before OSI got in the game:

1996:

https://groups.google.com/d/msg/no.linux/1UZo-3iv0tM/XPrPljd...

1995:

https://groups.google.com/d/msg/comp.graphics.raytracing/6oZ...

Both of those say "open source code". It's not a phrase like "open source" alone. The emphasis is on "source code" not on "open source".

While it sounds pretty brain-dead to put "open" in front of anything, to the point that it seems like the most natural thing for it, most people did not use this term and there was very little widespread understanding of what "open source" meant. If it wasn't for OSI, we'd still be saying a bunch of disjointed things instead of being universally aware of something called "open source".

Every time I have this discussion, someone comes along and thinks, "wait a minute, there's no way that OSI coined that term", but yes, they did. This is probably a Mandela effect.

https://en.wikipedia.org/wiki/Mandela_effect

You missed the hyphen in Caldera's "open-source", clearly linking them into a single term.

Well then. I guess you found the one instance of it happening. It was very rare and essentially unheard of.

Sure, OSI has an official doctrine, and Perens has (or had) kind of a unique point of view within that, about the two terms being fully synonymous -- but he partly walked back that view later, and Stallman and FSF's has historically been very different:

https://www.gnu.org/philosophy/open-source-misses-the-point....

And especially:

"The two terms describe almost the same category of software, but they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement.... Most discussion of 'open source' pays no attention to right and wrong, only to popularity and success..."

And of course OSI officially wrote "We realized it was time to dump the confrontational attitude that has been associated with 'free software' in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape." (http://web.archive.org/web/19981206185148/http://www.opensou...)

In other words, "open source" was about depoliticizing "free software" to make it more commercially palatable. (And arguably, it worked.)

Yep. It's a rebranding. And it worked.

Kind of like machine learning instead of statistics.

Apache also has some weird stuff about needing to clearly mark modifications to the code that frankly feels a little unneeded.

I wonder if a revision control system like Git obviates this problem, so long as you make clean patch merges.

I think that is the assumption. I’ve never encountered a change list of files on Github.

I still find it to be an odd requirement. I guess the intention is to keep people from misrepresenting your original code.

> but legal complexity is inherent in human affairs and cannot be simplified too much.

Legal systems are systems constructed by humans just like software and also contain complexity by cruft. Our law concepts are based on Roman law. For instance ownership was designed in a way to also deal with ownership over your wife and kids, slaves and debt peons.

Reply on news.ycombinator.com