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." 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."
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.
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.
> Can I use Google Code to host projects that aren't open source?
> Nope. Open source projects only.
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).
 the EU directive cited requires you to lawfully acquire the program and does not cover redistribution.
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.
Very true, I quite like that some have adopted the "Don't Fork Me" flag for the corner of their software pages. Nice cheeky little stab
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.
 Well not since the acquisition of Gitorius
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.
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
> 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.
"name": "Apache License 2.0",
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 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...
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.
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
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.
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.
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...
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.
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)
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.
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.
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.
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.
Speaking from experience here.
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.
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.
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.
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.
There's simply no way that MIT-licensed software is superior from a user's perspective.
Users care if they have to sideload an app because of a conflict between the App Store and a license's "additional restrictions" clause.
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 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.
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.
This should definitely crawl the README as well.
When will GitHub be open sourced?
 see https://github.com/github, https://github.com/libgit2/libgit2
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.
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.
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.
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
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.
is available w/ default REST pagination/query params for content on TLDRLegal