Open source license usage on GitHub | Hacker News Reader

Open source license usage on GitHub

github.com

129 pointshodgesmr92 comments

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/

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/ before I will use them in my own project.

[1] https://help.github.com/articles/github-terms-of-service/#f-...

[2] https://help.github.com/articles/github-glossary/#fork

I might be in the odd camp here, but I think Github/Bitbucket et al should force the user to pick a license when creating a new repo.

Even if there's an option that says "proprietary", I'm OK with that...

It would get rid of all the ambiguity of stumbling upon a very wonderful project but being unsure if you can use it due to no explicit license.

I wrote a paper on this in grad school. A few of these services (I cannot recall which and I don't have a copy of the paper handy) actually state in their ToS that you must include an OSI approved license in your repo.

Google Code has always been exclusively for open source projects. From https://code.google.com/p/support/wiki/FAQ#Hosting_Your_Open...

> Can I use Google Code to host projects that aren't open source?

> Nope. Open source projects only.

Propriatory means you can't download it form Github, or fork it. Which would defeat the point.

Well, no, If you publicly release the source code to your proprietary software, people can download it and tinker with it, so long as they don't distribute it whether it's modified or not.

Unreal Engine, for example, has its entire source available free of charge online, but it's proprietary software and you can't make changes or use it to make a game unless you obtain a license from Epic Games (which is now free of charge in many cases, but you still have to go through the process of getting it).

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.

No, it cannot legally do that.

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.

Do you have some support for that statement or are do we just have to trust you?

The right to fork is not the same as the right to sell derivatives.

This was actually a question I had. I'd love to know: If a company uploads a project minus a license, and I fork that project, do I have free use of that project? If so, would it be point-in-time of the fork?

See also djb's counterargument: http://cr.yp.to/softwarelaw.html

There are various issues with djb's counterargument, the most striking one is that the argument may hold water in the US, but it's certainly not applicable to the EU [1] or other parts of the world while a real license is. If you want to share your work, give it a license so that people know under which terms they can use it.

[1] the EU directive cited requires you to lawfully acquire the program and does not cover redistribution.

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.

>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

I think this page: 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

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.

The license description at choosealicense.com actually misrepresents the GPL. The GPL doesn't actually require that the source of modified versions be released to the original author. It requires that the source be released to the users who get the software. It is a downstream license designed for the freedom of the users and only incidentally works incompletely as a license to promote sharing the code back.

Everything about the design of the GPL including the very wording of the license is explicitly about blocking software from becoming proprietary. The choosealicense.com description is intentionally designed to avoid giving any acknowledgement of the GPL's actual design and intention because they don't want people to value the things the GPL is about.

> The license description at choosealicense.com actually misrepresents the GPL. The GPL doesn't actually require that the source of modified versions be released to the original author.

Where are you seeing a description that says sources must go to the author? I only see

> requires anyone who distributes your code or a derivative work to make the source available under the same terms

and

> When distributing derived works, the source code of the work must be made available under the same license.

Those both seem accurate, if maybe a little less clear than they might be.

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.

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.

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?

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

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.

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

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

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 and https://github.com/igravious/clearsilver_ebuild Nothing earth-shattering but it's a start I hope...

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

Thanks :)

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

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.

I encourage you to look at the ISC license. Same thing, but shorter.

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

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

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.

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

[2] http://opensource.org/licenses/fair

Terser still, WTFPL: http://www.wtfpl.net/about/

WTFPL has come in for some stick about the lack of a warranty clause, so last time I had to choose a licence, I perverted it into the FTWPL: https://github.com/systemed/tagmangle/blob/master/LICENCE.tx...

The Fair License is shorter. The WTFPL is about the same size as the Toybox license and has the same intent, but is far more legally ambiguous. I wouldn't use it for anything beyond toys.

Why do you prefer it over Apache 2.0? Apache discusses patents and contributors and can allow for more complex attribution requirements.

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_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_Distribu... (ZFS and DTrace cannot be included in Linux source)

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.

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.

I like ISC for similar reasons... just a little bit shorter.

Code that doesn't have patent protection isn't very useful to people who live in countries with oppressive patent laws.

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?

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.

Less legalese, I'm here to write code, not interpret law. That's why I prefer the MIT license.

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

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.

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

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

That’s interesting indeed! I get the feeling that the GPL has lost a lot of mindshare over the last fifteen years or so.

As open source software itself has gained mindshare, more people have become aware that there's more to it than just Linux, er sorry, GNU/Linux, and those parts aren't all GPL. Anybody developing for the web was probably using some combination of perl, php, python, ruby, node, etc. and those parts, i.e., the parts they're directly exposed to, aren't GPL.

Good point. And also, the type of software will influence the choice of license. E.g. when Facebook released the React library under the BSD license they most probably decided that the potential loss in competetive advantage would be unimportant. They could have gone with the GPL and then be able to offer a commercial license as well, but that would likely just be a distraction from Facebook’s core business. For a company’s main product offering it’s a different equation.

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.

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.

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.

The best overview of the situation: https://www.youtube.com/watch?v=-ItFjEG3LaA

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.

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

Hence the existence of the LGPL. The initial L initially (heh) stood for 'Library,' although it now stands for 'Lesser.'

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

How so, other than the fact that it can be difficult for users to install code that they've compiled themselves?

> There are many political views involved, but the reality is that users are the ones who suffer the consequences.

They certainly do, when they are unable to access, read, alter and deploy the code to the software they use.

> How so, other than the fact that it can be difficult for users to install code that they've compiled themselves?

That's the point precisely, it increases the difficulty of anything related with the distribution of a project outside of GPL's grounds. An increased difficulty often translates in extra effort and lost resources (time, developers, money, etc.).

The fact that many software authors are relicensing their work from GPL and similar licenses to MIT is because they're more interested in reducing to their users the hassle that the intricacies of the GPL family of licenses bring to them.

But using MIT doesn't make it any easier for my users to install custom software on their devices. Any problems which exist compiling GPLed software apply to compile MIT-licensed software.

There's simply no way that MIT-licensed software is superior from a user's perspective.

Sure, here's how: https://github.com/WhisperSystems/TextSecure-iOS/issues/65

Users care if they have to sideload an app because of a conflict between the App Store and a license's "additional restrictions" clause.

Users wanting to install custom software can always root/jailbreak their devices and "get their freedom back", including the freedom of screwing their device if they don't know what they're doing.

But what about users who exclusively care about USING the software? This group of users is broader by a great margin.

The ability to use MIT Software is a better option for this kind of users than telling them "sorry guy, no software for you because of <legal yadda yadda>".

There are several reasons why a distribution channel would prefer to deprive users from certain types of rights (ex. their right to install malware), and the chances of a company to change their policies to comply with the GPL's requirements is effectively zero.

The root of this issue is merely ideological and both sides of the coin (the FSF and the companies who control distribution channels) are known for NOT ceding, so this issue is effectively unsolvable.

> Users wanting to install custom software can always root/jailbreak their devices and "get their freedom back", including the freedom of screwing their device if they don't know what they're doing.

Users of Android devices just say, 'I want to install what I want to install.'

> The ability to use MIT Software is a better option

The ability to use MIT-licensed software is better for users who wish to restrict their own rights, yes.

It turns out that I was wrong, and that Apple have chosen to forbid GPLed applications outright. Yet another reason not to use Apple devices.

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

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

I checked Licensee, and it does look in COPYING: https://github.com/benbalter/licensee/blob/master/lib/licens...

But not LICENCE

It does! https://github.com/benbalter/licensee/blob/master/lib/licens...

or COPYRIGHT

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.

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.

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.

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.

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.

>Here at GitHub, we're big fans of open source,

When will GitHub be open sourced?

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/libgit2/libgit2

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.

Thanks for mentioning GitLab! Giving away the core of your business is harder than giving away the fringes. At GitLab we would love to have only one free version. But we need an open-core business model (with a proprietary Enterprise Edition) so that the enterprises pay for licensing. Making money only on support is very hard, especially when you ship a stable and easy-to-use product.

Please don't take this as criticism, because I don't mean it that way. I just want to point out the possibility that the situation you find yourself in is based on your choices, not necessarily on an inability to create a free software business model. I have not looked at GitLab specifically, if the following does not apply to how you do business, then I apologize. But for interest sake, consider the following.

Most software companies work on a "push" based model. They have BAs/PGMs who decide what work needs to be done, make plans and get development in motion. The developers implement the features and after a certain period of time, the features are finished. The business then sells licenses to the software based on the features that exist in the product.

In this kind of business model, you have many problems. First, you have a fairly large up front investment which you need to recover. The initial software development is paid for by the company and you need to find someone who is willing to reimburse those costs. Selling support is untenable because if the product requires a lot of support (meaning that the cost of the support contract is worth it), nobody will use the product. So instead the company must restrict the use of the product to paying customers. In this system, the no-cost, open source version is a loss leader that brings new customers. Such a system may actually be antithetical to free software developers because there is a huge incentive for the company to introduce vendor lock-in so as to push people to the paying version.

However, "push" models are not the only model you could use for development. While they are comparatively rare, "pull" models also exist. In a "pull" model, you avoid doing work unless someone pays you to do it. While it might be bug fixes, it is more likely features. Organizations are willing to pay for specific features because they get a defined benefit for an single up front cost. As long as there are several customers who are willing to pay for development, the cost is shared across those customers.

In such a system, it is the company's actions rather than their IP which is valuable. In fact it would be detrimental to restrict people from getting access to all the features because you lose potential customers. Also in such an environment, it is very important that nobody makes a proprietary version of the software to unfairly compete with you, so licenses like the GPL are incredibly useful.

As I said, examples of this type of model are few and far between. It is unfortunate because I think there is a lot of potential. If you got this far and are interested in one example of a successful "pull" model business, I highly recommend reading: http://www.oreilly.com/openbook/opensources/book/tiemans.htm...

Cygnus was eventually acquired by Red Hat for about $700 million in Red Hat stock. I can't find numbers to back this up, but from memory I believe they had sales of over $100 million per quarter at the time (the best place to look for how Cygnus impacted Red Had after the acquisition is to look at the quarterly reports from the year 2000 on).

I hope that proves interesting. Whether or not GitLab could transition to such a business model is obviously a different question. It is a completely different way of doing business and I don't think you could just tell people to change overnight. However, if you are really serious about exploring options for moving to a more free software oriented approach, I hope the above offers some clues for how to start.

Thanks for the advise, it was interesting reading about Cygnus, I was not aware of their story. At GitLab we already use both the pull and the push model. Since we started there have been people contributing to GitLab (more than 700!) and we encourage more contributions: http://feedback.gitlab.com/forums/176466-general/status/7964...

We also do sponsored development were organizations pay for adding new features.

People and organizations love contributing and sponsoring new user facing features. But other work is not contributed. Release management, dependency updates, security investigations and design updates don't receive much love. Few people want to do the work and few organizations want to sponsor it.

I don't say pull driven software can't be secure (FreeBSD) or that it can't be well designed. But with GitLab we were not happy with the rate of progress on these fronts. So we adopted an open core model to pay people to help with this. This meant our free software (that has the same design and security as the proprietary one) advanced at a much more rapid pace.

We're sure that staying 100% pull driven would not have created such as quality product as GitLab is today. We respect other organizations working with other models (Linux, Rails, etc.) but we're very happy with the choice we made for GitLab.

Your absurd and patently false assumptions about me convinced me to not give a substantive reply to a dishonest person like you.

I don't think it's good to downvote you for asking an interesting question. Github seems to really like open source, they just don't feel they can afford to open source their core product. That's a valid decision. I think nobody can honestly say that Github isn't helping the open source community.

Unfortunately, downvoting dissenting ideas/questions/opinions has become pretty much the norm on HN.

Anyway, our positions are not far off. I don't see the world as black and white. I can see the benefits of GitHub. It just struck me as odd that a software company that makes money from its proprietary software would say they're 'big fans' of open source since a major part of open source is the open source development model. I guess I have a different idea in mind when I hear "we're great fans of X" than others. /shrug

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.

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

It does! https://github.com/benbalter/licensee/blob/master/lib/licens...

Yes, turns out I was mistaken!

For another alternative:

https://tldrlegal.com/api/license

is available w/ default REST pagination/query params for content on TLDRLegal

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

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

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

Reply on news.ycombinator.com