16 ms·

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

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
    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.
- kensey 9y ago
  "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.
  - jordigh 9y ago
    The creators of both terms agree. I asked them: http://jordi.inversethought.com/blog/5-things-we-have-forgotten-about-open-source/ http://jordi.inversethought.com/blog/5-things-we-have-forgot... And here: https://opensource.org/faq#free-software https://opensource.org/faq#free-software
    - kevin_thibedeau 9y ago
      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/XPrPljdFk6gJ https://groups.google.com/d/msg/no.linux/1UZo-3iv0tM/XPrPljd... 1995: https://groups.google.com/d/msg/comp.graphics.raytracing/6oZasTgNo1A/Vv2qZq-Ha4sJ https://groups.google.com/d/msg/comp.graphics.raytracing/6oZ...
      - jordigh 9y ago
        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 https://en.wikipedia.org/wiki/Mandela_effect
        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.

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
  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.
kensey 9y ago
"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.
- jordigh 9y ago
  The creators of both terms agree. I asked them: http://jordi.inversethought.com/blog/5-things-we-have-forgotten-about-open-source/ http://jordi.inversethought.com/blog/5-things-we-have-forgot... And here: https://opensource.org/faq#free-software https://opensource.org/faq#free-software
  - kevin_thibedeau 9y ago
    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/XPrPljdFk6gJ https://groups.google.com/d/msg/no.linux/1UZo-3iv0tM/XPrPljd... 1995: https://groups.google.com/d/msg/comp.graphics.raytracing/6oZasTgNo1A/Vv2qZq-Ha4sJ https://groups.google.com/d/msg/comp.graphics.raytracing/6oZ...
    - jordigh 9y ago
      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 https://en.wikipedia.org/wiki/Mandela_effect
      - 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.