5 ms·

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

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.

jashkenas 9y ago
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.
- jordigh 9y ago
  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.
  - jashkenas 9y ago
    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-contributions-under-repository-license 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-Legislating-the-Nonobvious.html https://writing.kemitchell.com/2017/02/16/Against-Legislatin...
    - carussell 9y ago
      > 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".
  - lgas 9y ago
    For those of us that may have never learned those lessons, could you perhaps share what they were?
    - jordigh 9y ago
- JamesFM 9y ago
  Apache also has some weird stuff about needing to clearly mark modifications to the code that frankly feels a little unneeded.
  - nerdponx 9y ago
    I wonder if a revision control system like Git obviates this problem, so long as you make clean patch merges.
    - JamesFM 9y ago
      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.
legulere 9y ago
> 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.

jashkenas 9y ago

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.

jordigh 9y ago
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.
- jashkenas 9y ago
  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-contributions-under-repository-license 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-Legislating-the-Nonobvious.html https://writing.kemitchell.com/2017/02/16/Against-Legislatin...
  - carussell 9y ago
    > 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".
- lgas 9y ago
  For those of us that may have never learned those lessons, could you perhaps share what they were?
  - jordigh 9y ago
JamesFM 9y ago
Apache also has some weird stuff about needing to clearly mark modifications to the code that frankly feels a little unneeded.
- nerdponx 9y ago
  I wonder if a revision control system like Git obviates this problem, so long as you make clean patch merges.
  - JamesFM 9y ago
    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.

legulere 9y ago

> 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.