8 ms·

Open source license usage on GitHub

129 points by hodgesmr 12y ago

sergiotapia 12y ago
I'm really happy that MIT is in the lead by such a wide margin. It's the best license in my opinion.
- logn 12y ago
  Why do you prefer it over Apache 2.0? Apache discusses patents and contributors and can allow for more complex attribution requirements.
  - Aldo_MX 12y ago
    Usually my intention writing software is to build something useful for the people. I'm not interested in the legal mumbo-jumbo and MIT is a license which it's easier to understand for non-lawyers like me.
    - tracker1 12y ago
      I like ISC for similar reasons... just a little bit shorter.
    - technomancy 12y ago
      Code that doesn't have patent protection isn't very useful to people who live in countries with oppressive patent laws.
      - tedunangst 12y ago
        If I could make all my patent problems go away by sprinkling magic Apache License dust on my code, I'd consider it, but I don't think it works that way.
      - Aldo_MX 12y ago
        Code with encryption isn't very useful to people who live in countries where encryption is forbidden, does that mean I shouldn't write code with encryption?
  - sergiotapia 12y ago
    Less legalese, I'm here to write code, not interpret law. That's why I prefer the MIT license.
    - Alupis 12y ago
      > Less legalese, I'm here to write code, not interpret law. Is reading/understanding the License one time really that difficult? After your first read through, you basically just copy a text file into the root of your repo for each project and you're done... For me, the license could be 1 paragraph or 1,000 pages. I only have to understand it once then it just becomes a standard part of any new repo I create.
      - Aldo_MX 12y ago
        You must remember that: a) Many people don't speak English natively. b) Jurisdictions are different in every country, and sometimes in every state, the law of where you live takes precedence over what your LICENSE file says. Ex. jurisdictions where encryption is forbidden. c) Some people just make projects "for fun". Reading and understanding different licenses until you find the one you agree the most with is definitely "not fun". d) Nobody recommends a license without a disclaimer of "at your own risk" unless that person is a lawyer and it's getting paid to do that recommendation.
      - bronson 12y ago
        ...until you want to integrate some code that's under a different license. Wading through pages of potential incompatibilities is not the way I want to spend my time. Speaking from experience here.
      - fnordfnordfnord 12y ago
        >Is reading/understanding the License one time really that difficult? Yeah, actually, it is. Otherwise, litigation over these matters wouldn't take months and tens or hundreds of thousands of dollars. >I only have to understand it once Sorry, but just let some judge/jury make a decision that changes or restricts the meaning of a word like "distribute" and you've potentially got a big job ahead of you.
  - frik 12y ago
    BSD* and MIT are easier to read than Apache license, and compatible with all GPL licenses. Apache 1.x license is incompatible with GPL. Apache 2.0 license is a free software license and is compatible with GPLv3+, but not with GPLv2. http://en.wikipedia.org/wiki/Apache_License#GPL_compatibility http://en.wikipedia.org/wiki/Apache_License#GPL_compatibilit... GPLv2 incompatibility hurts many open source projects, also in the Linux area (Android code is Apache, Linux GPLv2). The Mozilla Public License and the related CDDL are problematic as well: http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License http://en.wikipedia.org/wiki/Common_Development_and_Distribu... (ZFS and DTrace cannot be included in Linux source)
    - dragonwriter 12y ago
      While the FSF portrays them as GPLv2 and earlier compatible, BSD and MIT both require downstream notices and language not required by any version of the GPL, which makes them incompatible with any version before GPLv3, which allows additional terms of the type at issue.
- teamhappy 12y ago
  I encourage you to look at the ISC license. Same thing, but shorter. https://en.wikipedia.org/wiki/ISC_license https://en.wikipedia.org/wiki/ISC_license
  - frik 12y ago
    The GNU lawyers advise: This license does have an unfortunate wording choice: it provides recipients with "Permission to use, copy, modify, and/or distribute this software…" This is roughly the same language from the license of Pine that the University of Washington later claimed prohibited people from distributing modified versions of the software. [...] to help make sure this language cannot cause any trouble in the future, we encourage developers to choose a different license for their own works. The Expat License and FreeBSD License are similarly permissive and brief. -- https://www.gnu.org/licenses/license-list.en.html#ISC https://www.gnu.org/licenses/license-list.en.html#ISC
    - teamhappy 12y ago
      I never got that quote. Pine's license said "and," and so did the ISC license. FSF pointed that out and ISC changed the license. Now it says "and/or." Both OSI and FSF have approved the license. And then they added (updated?) the text you quoted, complaining about the use of "and/or" ?! The problem with Pine seems to have been that it is/was a registered trademark (compare node.js/io.js). Also note the "Richard Stallman claims [...]" part of the Wikipedia article. Also note that nobody actually sued anyone. And even if they would have, who says they would have won? (Never mind the fact that legal precedents don't really matter outside of the US.) All things considered. I think we're good. --- Nothing wrong with choosing the MIT license though. Or the FreeBSD license. Or zlib, if you don't care about attribution.
  - vezzy-fnord 12y ago
    Even more terse, there's the "0-clause BSD" (Toybox) license [1] and the Fair License [2]. The first one is essentially akin to releasing in the public domain, whereas the second is the MIT/ISC license distilled down to its very core. [1] http://landley.net/toybox/license.html http://landley.net/toybox/license.html [2] http://opensource.org/licenses/fair http://opensource.org/licenses/fair
- cpach 12y ago
  That’s interesting indeed! I get the feeling that the GPL has lost a lot of mindshare over the last fifteen years or so.
  - tracker1 12y ago
    I don't think that is the case at all... I think it depends on how high level you get... when you are building simple libraries in JS, that are abstractions on top of abstractions, MIT makes more sense because you can use it much more broadly. When you develop an operating system or driver, GPL makes far more sense because it won't lock things away... the closer you are to the hardware, the more GPL makes sense. The Apache-style licenses make a bit of sense for the stuff in between.
    - quadrangle 12y ago
      Actually, the GPL makes total sense for end-user software. In fact, lots of people argue that it makes the most sense for downstream software since it protects user freedom and won't be used in a way where compatibility is an issue. But you're right it makes sense for the OS too. I guess the GPL just makes sense, period.
      - tracker1 12y ago
        Maybe it's just a matter of a complex system, vs something more simple... a JS module can be used much more broadly as MIT/BSD/ISC than with GPL... and for the most part, because JS is typically open (though obfuscated as an artifact of minification)... where something like a complete application, or OS would have a greater desire for those safeguards... A client library to an application, less so.
  - Aldo_MX 12y ago
    It really depends on the scope of your project, if you are writing a library (for example), GPL is a bad choice because you limit your audience to strictly GPL grounds (unless you really want that). Many libraries have changed their licenses from GPL/LGPL to MIT because GPL/LGPL have proved to be troublesome for specific platforms (ex. Mobile Devices). There are many political views involved, but the reality is that users are the ones who suffer the consequences.
- belorn 12y ago
  Remember that the statistics need to be read in the context where it was gathered from. The data looks completely different if you look at packages in distributions like Debian and derivatives, Redhat, and so on.
eliotfowler 12y ago
I'd like to see them do some analysis and attempt to include licenses in READMEs. That seems to be VERY common amount projects on GitHub.
- logn 12y ago
  Also in my license file I always list licenses of dependencies. I glanced at the source of Licensee and it doesn't seem to weight the license that appears first which would help in this case.
- reiz 12y ago
  I wrote once a license crawler for VersionEye which recognises the most common licenses in README files on GitHub. But I didn't crawl whole GitHub! Only projects which are submitted in package managers and did not provide a license info on the package manager. I'm using it for example to complete license infos about RubyGem projects without a license on RubyGems.
reiz 12y ago
Very interesting blog post. I wouldn't have thought that so less projects on GitHub provide a proper license! I'm working on https://www.versioneye.com https://www.versioneye.com and we track currently more than 500K open source projects in package managers. I just did a quick lookup in our database about Ruby licenses. Currently we have licenses for 56803 Ruby projects (RubyGems) and 49842 of them are MIT! That means 87% of all Ruby projects who provide a license at all, provide an MIT license! I will do a couple more queries and write a blog post to this!
frik 12y ago
It's good to see MIT and GPLv2 in the top 3, with BSD* and LGPL* in the top 10. The MIT license is also known as the X11 License: https://www.gnu.org/licenses/license-list.en.html#X11License https://www.gnu.org/licenses/license-list.en.html#X11License In the age secure boot functionality of UEFI (BIOS replacement) to hinder or outright prevent the installation of alternative operating systems and locked firmwares on common smartphone and tablet hardware. The source code license has a strategic value, especially with high profile open source projects like operating systems. Examples: Android based on GPLv2 Linux, OSX/iOS and many routers based *BSD operating system source code that ship on a closed down hardware.
andrewguenther 12y ago
Just a friendly reminder about what it means to not have a license in your repository. You can read about it here: http://choosealicense.com/no-license/ http://choosealicense.com/no-license/ Essentially, by not including a license, you default to standard copyright protections and "you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work." However, GitHub's ToS say that "by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."[1] If you go into the glossary you can see that the definition for fork "allow[s] you to freely make changes to a project without affecting the original."[2] Since I'm not a lawyer, I'm not going to do any deeper analysis other than direct quotation here, but I can say that I personally like to submit pull requests with the MIT license to projects I wish to use which do not include a license, as well as a link to http://choosealicense.com/ http://choosealicense.com/ before I will use them in my own project. [1] https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership https://help.github.com/articles/github-terms-of-service/#f-... [2] https://help.github.com/articles/github-glossary/#fork https://help.github.com/articles/github-glossary/#fork
- zanny 12y ago
  I have to expect that the TOS of Github supersedes default copyright, since you are intentionally uploading your files to the service. You have to agree to that TOS to do so, and that TOS forfeits presumed copyright assumptions for public repositories.
  - justincormack 12y ago
    No, it cannot legally do that.
    - zanny 12y ago
      You cannot willingly transfer information to a second party and agree to terms that make you partially forfeit copyright so they can enable others to see or modify the information you gave them? Then what the hell is every Facebook post ever that the company mines for personal information? Thats in their TOS, and you agree to it by posting to their service.
agwa 12y ago
> To detect what license, if any, a project is licensed under, we used an open source Ruby gem called Licensee to compare the repository's LICENSE file to a short list of known licenses They should also look in COPYING, which is the conventional place to declare that a project is licensed under the GPL. The GPL percentage would likely get a boost if they did this.
- JoshTriplett 12y ago
  I checked Licensee, and it does look in COPYING: https://github.com/benbalter/licensee/blob/master/lib/licensee/project.rb https://github.com/benbalter/licensee/blob/master/lib/licens...
  - rmc 12y ago
    But not LICENCE
    - benbalter 12y ago
      It does! https://github.com/benbalter/licensee/blob/master/lib/licensee/project.rb#L56 https://github.com/benbalter/licensee/blob/master/lib/licens...
    - caf 12y ago
      or COPYRIGHT
JoshTriplett 12y ago
There are several entire communities of projects, such as Ruby or node.js, which by policy put all of their myriad projects on GitHub. Those communities have thousands or tens of thousands of repositories each, which make up a significant part of the 80000 repositories shown in the main graph in this article, and they're almost all MIT. So I'm wondering how much of the huge set of MIT repositories on GitHub all come from that handful of communities, and how much is random contributors. I'd also suggest that there's a significant overlap between people who choose copyleft licenses and people who avoid proprietary hosting services. So while I do think this data is significant, I think it represents the GitHub community, not the broader FOSS community.
- arfar 12y ago
  >I'd also suggest that there's a significant overlap between people who choose copyleft licenses and people who avoid proprietary hosting services. Very true, I quite like that some have adopted the "Don't Fork Me"[1] flag for the corner of their software pages. Nice cheeky little stab [1] http://librecmc.org/librecmc/wiki?name=github http://librecmc.org/librecmc/wiki?name=github
  - ChuckMcM 12y ago
    I think this page: http://librecmc.org/librecmc/wiki?name=Source+Repository http://librecmc.org/librecmc/wiki?name=Source+Repository really spells out the challenge. The librecmc folks are scrambling to find someone who will give away their work for free to host their repository which they give away for free. Except there isn't anyone at the moment[1], and so they are nominally forced to shoulder the costs for that or just evaporate. The "strength" of free software is that you have all the code so you can shoulder that cost. But its really painful to bear the costs of your free software that other folks are benefiting from every day, for free. Github seems like a reasonable compromise in this regard. [1] Well not since the acquisition of Gitorius
  - detaro 12y ago
    It is strange to see an argument like "They didn't like our change to the license descriptions to a more political one". You want everything to be copyleft, including your infrastructure, that is fine and consistent. Say so, act accordingly and encourage others to do so, but that is just petty.
pointfree 12y ago
I'm pleasantly surprised to see that AGPLv3 is at least in the 10th spot.
vitno 12y ago
If I start a project on GitHub, I generally put a license in the LICENSE file (at their repo creation). If I don't start it on GitHub and later add it, I generally just put the license in the README(.md, 'cause GitHub). This should definitely crawl the README as well.
HeadlessChild 12y ago
All those Linux "dot-files" and similar stuff take up quite a lot of space on GitHub.
ksk 12y ago
>Here at GitHub, we're big fans of open source, When will GitHub be open sourced?
- Xylakant 12y ago
  I'd downvote you twice if I could. Open Source is not and never was about not making money and it was never about giving away what makes the core of your business. Github shares a lot of code and projects that are useful to the open source community [1] and at the same time provides a free service that is tremendously useful for a lot of open source projects. I feel like they're doing their part of sharing, attacking them because they're a profitable company is just cheap. [1] see https://github.com/github https://github.com/github, https://github.com/libgit2/libgit2 https://github.com/libgit2/libgit2
  - adrusi 12y ago
    Licensing their entire infrastructure would probably not impact their profit. There are already very capable competitors to Github, the also-proprietary Bitbucket, and the Free Gitlab most notably. It's not so much their technology that keeps them the market leader, their tech isn't really anything special (not saying it's poor quality or trivial). It's their network momentum that makes them the perennial favorite. If they released their entire source code under GPLv3 and started accepting pull requests, they would almost certainly be fine. Bitbucket couldn't make much use of their code unless Atlassian followed suit and released their source under the terms of GPLv3 as well. They also of course sell a self-hosted version of github to enterprise customers, who now could give them the finger and just build the application from source, but if they wanted to do that, they would just use Gitlab. The enterprise customers are paying for the support package that comes with the software. Free software isn't about not making money. It is about "giving away" the core of your business. Not because we want to run ourselves out of business, but because we have an ethical obligation to preserve our users' freedoms to run the software however they want, to study and modify its implementation, and to redistribute it regardless of whether it was modified. Or at least many of use believe we do. Part of the reason the GPL exists is to help your users without endangering your business.
rmc 12y ago
Seems to look for the file "LICENSE". Some people spell it "LICENCE"
- benbalter 12y ago
  It does! https://github.com/benbalter/licensee/blob/master/lib/licensee/project.rb#L56 https://github.com/benbalter/licensee/blob/master/lib/licens...
  - rmc 12y ago
    Yes, turns out I was mistaken!
tracker1 12y ago
I prefer the shorter ISC license to BSD or MIT... It's the default from npm's init, and just feels better than putting more verbiage than what's really needed.
igravious 12y ago
Well. Thanks for the reminder. I always mean for the code I put on Github to be shared but I rarely seem to plonk a license file in the project root folder. (Does that mean I subconscious _don't_ want to share???) I just GPLv2'd https://github.com/igravious/clearsilver_ruby https://github.com/igravious/clearsilver_ruby and https://github.com/igravious/clearsilver_ebuild https://github.com/igravious/clearsilver_ebuild Nothing earth-shattering but it's a start I hope...
- __david__ 12y ago
  > Does that mean I subconscious _don't_ want to share??? No, it's just a reminder that releasing software is kind of a pain. You have to write docs, you have to choose a license, you have to organize things, tag your repo, maybe make a .tar file if your project is big enough (or it's expected by your audience). > Nothing earth-shattering but it's a start I hope... Everyone has to start somewhere! Nice job.
  - igravious 12y ago
    Thanks :)
kibwen 12y ago
I was curious how this handled repositories that use are offered under more than one license, so I tried this out on the Rust repository: "license": { "key": "apache-2.0", "name": "Apache License 2.0", "url": "https://api.github.com/licenses/apache-2.0" } Rust is offered under both MIT and Apache 2, and has corresponding LICENSE-MIT and LICENSE-APACHE files in its root directory. I'm assuming that Github simply searches alphabetically for all files that begin with LICEN[CS]E and eagerly terminates upon finding a single match.
- yaeger 12y ago
  That would be very bad for projects that not only use dual licenses but especially if one of them is a commercial license. If you just checked there and found the apache and think "Great, I can put that into my closed source tool" you might be in for a surprise when the author contacts you and tells you that the apache is only for non commercial use and there is a second, paid license for commercial use available that you should have taken.
  - delsalk 12y ago
    Surely doing that would require them to rewrite the Apache license (thus making it no longer the apache license) otherwise there's no legal way of enforcing the non-commercial use?
fiatjaf 12y ago
Ok, I just added a lot of LICENSEs from the web interface to a lot of repos and I'm not ashamed.
quadrangle 12y ago
Too bad that choosealicense.com is so carefully designed to maintain neutral appearance while actively discouraging copyleft licenses (relegate GPL to last option, describe it as only about sharing rather than about preserving freedom, make it outdated GPLv2 — since they like GPLv2 loopholes better than closing the loopholes etc.)
seth_gillette 12y ago
So some intern put together a list of all the licenses?
XiZhao 12y ago
For another alternative: https://tldrlegal.com/api/license https://tldrlegal.com/api/license is available w/ default REST pagination/query params for content on TLDRLegal
kijin 12y ago
Is there any way to select a license for an existing GitHub repository, without adding or modifying any file at a particular location in the tree? Also, it's difficult to find out the license for any given repository while casually browsing or searching. I'm often looking for things that come with (or without) a particular license, e.g. "I can't use any GPL components in my current project." It would be really nice if the license was displayed prominently, just like the programming language used.

129 points by hodgesmr 12y ago

sergiotapia 12y ago

I'm really happy that MIT is in the lead by such a wide margin. It's the best license in my opinion.

logn 12y ago
Why do you prefer it over Apache 2.0? Apache discusses patents and contributors and can allow for more complex attribution requirements.
- Aldo_MX 12y ago
  Usually my intention writing software is to build something useful for the people. I'm not interested in the legal mumbo-jumbo and MIT is a license which it's easier to understand for non-lawyers like me.
  - tracker1 12y ago
    I like ISC for similar reasons... just a little bit shorter.
  - technomancy 12y ago
    Code that doesn't have patent protection isn't very useful to people who live in countries with oppressive patent laws.
    - tedunangst 12y ago
      If I could make all my patent problems go away by sprinkling magic Apache License dust on my code, I'd consider it, but I don't think it works that way.
    - Aldo_MX 12y ago
      Code with encryption isn't very useful to people who live in countries where encryption is forbidden, does that mean I shouldn't write code with encryption?
- sergiotapia 12y ago
  Less legalese, I'm here to write code, not interpret law. That's why I prefer the MIT license.
  - Alupis 12y ago
    > Less legalese, I'm here to write code, not interpret law. Is reading/understanding the License one time really that difficult? After your first read through, you basically just copy a text file into the root of your repo for each project and you're done... For me, the license could be 1 paragraph or 1,000 pages. I only have to understand it once then it just becomes a standard part of any new repo I create.
    - Aldo_MX 12y ago
      You must remember that: a) Many people don't speak English natively. b) Jurisdictions are different in every country, and sometimes in every state, the law of where you live takes precedence over what your LICENSE file says. Ex. jurisdictions where encryption is forbidden. c) Some people just make projects "for fun". Reading and understanding different licenses until you find the one you agree the most with is definitely "not fun". d) Nobody recommends a license without a disclaimer of "at your own risk" unless that person is a lawyer and it's getting paid to do that recommendation.
    - bronson 12y ago
      ...until you want to integrate some code that's under a different license. Wading through pages of potential incompatibilities is not the way I want to spend my time. Speaking from experience here.
    - fnordfnordfnord 12y ago
      >Is reading/understanding the License one time really that difficult? Yeah, actually, it is. Otherwise, litigation over these matters wouldn't take months and tens or hundreds of thousands of dollars. >I only have to understand it once Sorry, but just let some judge/jury make a decision that changes or restricts the meaning of a word like "distribute" and you've potentially got a big job ahead of you.
- frik 12y ago
  BSD* and MIT are easier to read than Apache license, and compatible with all GPL licenses. Apache 1.x license is incompatible with GPL. Apache 2.0 license is a free software license and is compatible with GPLv3+, but not with GPLv2. http://en.wikipedia.org/wiki/Apache_License#GPL_compatibility http://en.wikipedia.org/wiki/Apache_License#GPL_compatibilit... GPLv2 incompatibility hurts many open source projects, also in the Linux area (Android code is Apache, Linux GPLv2). The Mozilla Public License and the related CDDL are problematic as well: http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License http://en.wikipedia.org/wiki/Common_Development_and_Distribu... (ZFS and DTrace cannot be included in Linux source)
  - dragonwriter 12y ago
    While the FSF portrays them as GPLv2 and earlier compatible, BSD and MIT both require downstream notices and language not required by any version of the GPL, which makes them incompatible with any version before GPLv3, which allows additional terms of the type at issue.
teamhappy 12y ago
I encourage you to look at the ISC license. Same thing, but shorter. https://en.wikipedia.org/wiki/ISC_license https://en.wikipedia.org/wiki/ISC_license
- frik 12y ago
  The GNU lawyers advise: This license does have an unfortunate wording choice: it provides recipients with "Permission to use, copy, modify, and/or distribute this software…" This is roughly the same language from the license of Pine that the University of Washington later claimed prohibited people from distributing modified versions of the software. [...] to help make sure this language cannot cause any trouble in the future, we encourage developers to choose a different license for their own works. The Expat License and FreeBSD License are similarly permissive and brief. -- https://www.gnu.org/licenses/license-list.en.html#ISC https://www.gnu.org/licenses/license-list.en.html#ISC
  - teamhappy 12y ago
    I never got that quote. Pine's license said "and," and so did the ISC license. FSF pointed that out and ISC changed the license. Now it says "and/or." Both OSI and FSF have approved the license. And then they added (updated?) the text you quoted, complaining about the use of "and/or" ?! The problem with Pine seems to have been that it is/was a registered trademark (compare node.js/io.js). Also note the "Richard Stallman claims [...]" part of the Wikipedia article. Also note that nobody actually sued anyone. And even if they would have, who says they would have won? (Never mind the fact that legal precedents don't really matter outside of the US.) All things considered. I think we're good. --- Nothing wrong with choosing the MIT license though. Or the FreeBSD license. Or zlib, if you don't care about attribution.
- vezzy-fnord 12y ago
  Even more terse, there's the "0-clause BSD" (Toybox) license [1] and the Fair License [2]. The first one is essentially akin to releasing in the public domain, whereas the second is the MIT/ISC license distilled down to its very core. [1] http://landley.net/toybox/license.html http://landley.net/toybox/license.html [2] http://opensource.org/licenses/fair http://opensource.org/licenses/fair
cpach 12y ago
That’s interesting indeed! I get the feeling that the GPL has lost a lot of mindshare over the last fifteen years or so.
- tracker1 12y ago
  I don't think that is the case at all... I think it depends on how high level you get... when you are building simple libraries in JS, that are abstractions on top of abstractions, MIT makes more sense because you can use it much more broadly. When you develop an operating system or driver, GPL makes far more sense because it won't lock things away... the closer you are to the hardware, the more GPL makes sense. The Apache-style licenses make a bit of sense for the stuff in between.
  - quadrangle 12y ago
    Actually, the GPL makes total sense for end-user software. In fact, lots of people argue that it makes the most sense for downstream software since it protects user freedom and won't be used in a way where compatibility is an issue. But you're right it makes sense for the OS too. I guess the GPL just makes sense, period.
    - tracker1 12y ago
      Maybe it's just a matter of a complex system, vs something more simple... a JS module can be used much more broadly as MIT/BSD/ISC than with GPL... and for the most part, because JS is typically open (though obfuscated as an artifact of minification)... where something like a complete application, or OS would have a greater desire for those safeguards... A client library to an application, less so.
- Aldo_MX 12y ago
  It really depends on the scope of your project, if you are writing a library (for example), GPL is a bad choice because you limit your audience to strictly GPL grounds (unless you really want that). Many libraries have changed their licenses from GPL/LGPL to MIT because GPL/LGPL have proved to be troublesome for specific platforms (ex. Mobile Devices). There are many political views involved, but the reality is that users are the ones who suffer the consequences.
belorn 12y ago
Remember that the statistics need to be read in the context where it was gathered from. The data looks completely different if you look at packages in distributions like Debian and derivatives, Redhat, and so on.

eliotfowler 12y ago

I'd like to see them do some analysis and attempt to include licenses in READMEs. That seems to be VERY common amount projects on GitHub.

logn 12y ago
Also in my license file I always list licenses of dependencies. I glanced at the source of Licensee and it doesn't seem to weight the license that appears first which would help in this case.
reiz 12y ago
I wrote once a license crawler for VersionEye which recognises the most common licenses in README files on GitHub. But I didn't crawl whole GitHub! Only projects which are submitted in package managers and did not provide a license info on the package manager. I'm using it for example to complete license infos about RubyGem projects without a license on RubyGems.

reiz 12y ago

Very interesting blog post. I wouldn't have thought that so less projects on GitHub provide a proper license! I'm working on https://www.versioneye.com https://www.versioneye.com and we track currently more than 500K open source projects in package managers. I just did a quick lookup in our database about Ruby licenses. Currently we have licenses for 56803 Ruby projects (RubyGems) and 49842 of them are MIT! That means 87% of all Ruby projects who provide a license at all, provide an MIT license! I will do a couple more queries and write a blog post to this!

frik 12y ago

It's good to see MIT and GPLv2 in the top 3, with BSD* and LGPL* in the top 10. The MIT license is also known as the X11 License: https://www.gnu.org/licenses/license-list.en.html#X11License https://www.gnu.org/licenses/license-list.en.html#X11License In the age secure boot functionality of UEFI (BIOS replacement) to hinder or outright prevent the installation of alternative operating systems and locked firmwares on common smartphone and tablet hardware. The source code license has a strategic value, especially with high profile open source projects like operating systems. Examples: Android based on GPLv2 Linux, OSX/iOS and many routers based *BSD operating system source code that ship on a closed down hardware.

andrewguenther 12y ago

Just a friendly reminder about what it means to not have a license in your repository. You can read about it here: http://choosealicense.com/no-license/ http://choosealicense.com/no-license/ Essentially, by not including a license, you default to standard copyright protections and "you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work." However, GitHub's ToS say that "by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."[1] If you go into the glossary you can see that the definition for fork "allow[s] you to freely make changes to a project without affecting the original."[2] Since I'm not a lawyer, I'm not going to do any deeper analysis other than direct quotation here, but I can say that I personally like to submit pull requests with the MIT license to projects I wish to use which do not include a license, as well as a link to http://choosealicense.com/ http://choosealicense.com/ before I will use them in my own project. [1] https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership https://help.github.com/articles/github-terms-of-service/#f-... [2] https://help.github.com/articles/github-glossary/#fork https://help.github.com/articles/github-glossary/#fork

zanny 12y ago
I have to expect that the TOS of Github supersedes default copyright, since you are intentionally uploading your files to the service. You have to agree to that TOS to do so, and that TOS forfeits presumed copyright assumptions for public repositories.
- justincormack 12y ago
  No, it cannot legally do that.
  - zanny 12y ago
    You cannot willingly transfer information to a second party and agree to terms that make you partially forfeit copyright so they can enable others to see or modify the information you gave them? Then what the hell is every Facebook post ever that the company mines for personal information? Thats in their TOS, and you agree to it by posting to their service.

agwa 12y ago

> To detect what license, if any, a project is licensed under, we used an open source Ruby gem called Licensee to compare the repository's LICENSE file to a short list of known licenses They should also look in COPYING, which is the conventional place to declare that a project is licensed under the GPL. The GPL percentage would likely get a boost if they did this.

JoshTriplett 12y ago
I checked Licensee, and it does look in COPYING: https://github.com/benbalter/licensee/blob/master/lib/licensee/project.rb https://github.com/benbalter/licensee/blob/master/lib/licens...
- rmc 12y ago
  But not LICENCE
  - benbalter 12y ago
    It does! https://github.com/benbalter/licensee/blob/master/lib/licensee/project.rb#L56 https://github.com/benbalter/licensee/blob/master/lib/licens...
  - caf 12y ago
    or COPYRIGHT

JoshTriplett 12y ago

There are several entire communities of projects, such as Ruby or node.js, which by policy put all of their myriad projects on GitHub. Those communities have thousands or tens of thousands of repositories each, which make up a significant part of the 80000 repositories shown in the main graph in this article, and they're almost all MIT. So I'm wondering how much of the huge set of MIT repositories on GitHub all come from that handful of communities, and how much is random contributors. I'd also suggest that there's a significant overlap between people who choose copyleft licenses and people who avoid proprietary hosting services. So while I do think this data is significant, I think it represents the GitHub community, not the broader FOSS community.

arfar 12y ago
>I'd also suggest that there's a significant overlap between people who choose copyleft licenses and people who avoid proprietary hosting services. Very true, I quite like that some have adopted the "Don't Fork Me"[1] flag for the corner of their software pages. Nice cheeky little stab [1] http://librecmc.org/librecmc/wiki?name=github http://librecmc.org/librecmc/wiki?name=github
- ChuckMcM 12y ago
  I think this page: http://librecmc.org/librecmc/wiki?name=Source+Repository http://librecmc.org/librecmc/wiki?name=Source+Repository really spells out the challenge. The librecmc folks are scrambling to find someone who will give away their work for free to host their repository which they give away for free. Except there isn't anyone at the moment[1], and so they are nominally forced to shoulder the costs for that or just evaporate. The "strength" of free software is that you have all the code so you can shoulder that cost. But its really painful to bear the costs of your free software that other folks are benefiting from every day, for free. Github seems like a reasonable compromise in this regard. [1] Well not since the acquisition of Gitorius
- detaro 12y ago
  It is strange to see an argument like "They didn't like our change to the license descriptions to a more political one". You want everything to be copyleft, including your infrastructure, that is fine and consistent. Say so, act accordingly and encourage others to do so, but that is just petty.

pointfree 12y ago

I'm pleasantly surprised to see that AGPLv3 is at least in the 10th spot.

vitno 12y ago

If I start a project on GitHub, I generally put a license in the LICENSE file (at their repo creation). If I don't start it on GitHub and later add it, I generally just put the license in the README(.md, 'cause GitHub). This should definitely crawl the README as well.

HeadlessChild 12y ago

All those Linux "dot-files" and similar stuff take up quite a lot of space on GitHub.

ksk 12y ago

>Here at GitHub, we're big fans of open source, When will GitHub be open sourced?

Xylakant 12y ago
I'd downvote you twice if I could. Open Source is not and never was about not making money and it was never about giving away what makes the core of your business. Github shares a lot of code and projects that are useful to the open source community [1] and at the same time provides a free service that is tremendously useful for a lot of open source projects. I feel like they're doing their part of sharing, attacking them because they're a profitable company is just cheap. [1] see https://github.com/github https://github.com/github, https://github.com/libgit2/libgit2 https://github.com/libgit2/libgit2
- adrusi 12y ago
  Licensing their entire infrastructure would probably not impact their profit. There are already very capable competitors to Github, the also-proprietary Bitbucket, and the Free Gitlab most notably. It's not so much their technology that keeps them the market leader, their tech isn't really anything special (not saying it's poor quality or trivial). It's their network momentum that makes them the perennial favorite. If they released their entire source code under GPLv3 and started accepting pull requests, they would almost certainly be fine. Bitbucket couldn't make much use of their code unless Atlassian followed suit and released their source under the terms of GPLv3 as well. They also of course sell a self-hosted version of github to enterprise customers, who now could give them the finger and just build the application from source, but if they wanted to do that, they would just use Gitlab. The enterprise customers are paying for the support package that comes with the software. Free software isn't about not making money. It is about "giving away" the core of your business. Not because we want to run ourselves out of business, but because we have an ethical obligation to preserve our users' freedoms to run the software however they want, to study and modify its implementation, and to redistribute it regardless of whether it was modified. Or at least many of use believe we do. Part of the reason the GPL exists is to help your users without endangering your business.

rmc 12y ago

Seems to look for the file "LICENSE". Some people spell it "LICENCE"

benbalter 12y ago
It does! https://github.com/benbalter/licensee/blob/master/lib/licensee/project.rb#L56 https://github.com/benbalter/licensee/blob/master/lib/licens...
- rmc 12y ago
  Yes, turns out I was mistaken!

tracker1 12y ago

I prefer the shorter ISC license to BSD or MIT... It's the default from npm's init, and just feels better than putting more verbiage than what's really needed.

igravious 12y ago

Well. Thanks for the reminder. I always mean for the code I put on Github to be shared but I rarely seem to plonk a license file in the project root folder. (Does that mean I subconscious _don't_ want to share???) I just GPLv2'd https://github.com/igravious/clearsilver_ruby https://github.com/igravious/clearsilver_ruby and https://github.com/igravious/clearsilver_ebuild https://github.com/igravious/clearsilver_ebuild Nothing earth-shattering but it's a start I hope...

__david__ 12y ago
> Does that mean I subconscious _don't_ want to share??? No, it's just a reminder that releasing software is kind of a pain. You have to write docs, you have to choose a license, you have to organize things, tag your repo, maybe make a .tar file if your project is big enough (or it's expected by your audience). > Nothing earth-shattering but it's a start I hope... Everyone has to start somewhere! Nice job.
- igravious 12y ago
  Thanks :)

kibwen 12y ago

I was curious how this handled repositories that use are offered under more than one license, so I tried this out on the Rust repository: "license": { "key": "apache-2.0", "name": "Apache License 2.0", "url": "https://api.github.com/licenses/apache-2.0" } Rust is offered under both MIT and Apache 2, and has corresponding LICENSE-MIT and LICENSE-APACHE files in its root directory. I'm assuming that Github simply searches alphabetically for all files that begin with LICEN[CS]E and eagerly terminates upon finding a single match.

yaeger 12y ago
That would be very bad for projects that not only use dual licenses but especially if one of them is a commercial license. If you just checked there and found the apache and think "Great, I can put that into my closed source tool" you might be in for a surprise when the author contacts you and tells you that the apache is only for non commercial use and there is a second, paid license for commercial use available that you should have taken.
- delsalk 12y ago
  Surely doing that would require them to rewrite the Apache license (thus making it no longer the apache license) otherwise there's no legal way of enforcing the non-commercial use?

fiatjaf 12y ago

Ok, I just added a lot of LICENSEs from the web interface to a lot of repos and I'm not ashamed.

quadrangle 12y ago

Too bad that choosealicense.com is so carefully designed to maintain neutral appearance while actively discouraging copyleft licenses (relegate GPL to last option, describe it as only about sharing rather than about preserving freedom, make it outdated GPLv2 — since they like GPLv2 loopholes better than closing the loopholes etc.)

seth_gillette 12y ago

So some intern put together a list of all the licenses?

XiZhao 12y ago

For another alternative: https://tldrlegal.com/api/license https://tldrlegal.com/api/license is available w/ default REST pagination/query params for content on TLDRLegal

kijin 12y ago

Is there any way to select a license for an existing GitHub repository, without adding or modifying any file at a particular location in the tree? Also, it's difficult to find out the license for any given repository while casually browsing or searching. I'm often looking for things that come with (or without) a particular license, e.g. "I can't use any GPL components in my current project." It would be really nice if the license was displayed prominently, just like the programming language used.