Open source simply isn't open source without a proper license. Unless you've explicitly told others that they can modify and reuse your work, you've only showed others your code; you haven't shared it. Here at GitHub, we're big fans of open source, so we set out to better understand how our users approached licensing their code by looking at license usage across public, non-forked repositories, in hopes of encouraging more users to share their work with others.

If you look at this graph of licensed repositories over time, you'll notice that the percentage of licensed repositories has been decreasing, hovering around 20% throughout GitHub's history (about 30% if you include forked repositories). The sharp spike in mid-2013 represents our first pass at making open source licensing on GitHub easier by launching choosealicense.com to demystify license choices, and introducing the license picker to encourage users to license their projects.

Breakdown of license usage

We also wanted to look at the relative breakdown of the most popular open source licenses. You can see their popularity expressed below as a percentage of licensed projects on GitHub.com:

Unsurprisingly, MIT, Apache, and GPL are the clear front runners, with some 15% of licensed projects opting for a non-standard license or standard license not among those listed on choosealicense.com.

Last, we looked at how license usage has changed over time. Again, you see a swift uptick of the three featured license (MIT, Apache, GPL) in mid-2013, with the relative percentages remaining otherwise steady over the past six years.

Developers use GitHub because they want to share their code with the world, and the data suggests that when the tools we use make it a little bit easier, developers do just that. When presented with the option, they choose to license, and they license very permissively.

Under the hood

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. However, it's important to note that this approach doesn't count a project as licensed if the README indicates a specific license or if individual project files contain a named license in the code comments.

The licenses API

We want to make it easier for open source developers to license their code, and for open source consumers to verify that they are using open source projects under an appropriate license. To that end, we're launching the Licenses API preview to retrieve information about a particular project's license file, as well as metadata about open source licenses in general.

When you pass the appropriate preview media type, API requests for a particular repository will now include the project's license, if any, represented by its SPDX-compliant and human-readable names:

{
  ...
  "license": {
    "key": "mit",
    "name": "MIT License",
    "url":  "https://api.github.com/licenses/mit"
  }
  ...
}

The individual license endpoints (e.g., /licenses/mit) return additional information about the license, including what you can and can't do with the software, and the full license body. For more information, see the developer documentation.

Share your code

If you haven't already, we encourage you to add a LICENSE file to your project. To make things a bit easier, if you begin to create a file named LICENSE via the web interface, we'll even provide you with a list of common license templates to choose from.

This is just the start. Look forward to a more in depth analysis over the coming weeks as to how license usage affects project success, as we delve deeper into the numbers. Of course, in the mean time, we encourage you to explore license usage on GitHub using the Licenses API.

Happy open source licensing!

Join @jatoben and me (@elizabethn) for a meetup in awesome Kalamazoo on March 14! If you'll be in town for Kalamazoo X, or just in the area anyway, we'd love to share some with you and our friends at Bell's Brewery. As always, there will be many stickers available, just for you.

Everyone is welcome!

The Facts:

• Saturday, March 14, 7 pm
• Bell's Brewery, 355 E. Kalamazoo Ave., Kalamazoo, Michigan

GitHub has been selected to participate as a mentoring organization for Google Summer of Code, a program where students receive a stipend to contribute to open source projects.

If you want to work with a GitHubber on an open source project, check out our list of project ideas, featuring opportunities to contribute to the Atom Editor and the Homebrew package manager for OS X. If you have an idea for a project that we haven't suggested yet, browse GitHub's open source projects and open a new issue on the github/gsoc repository to suggest other ideas or ask questions about participating in the program.

Applications can be submitted to the Google Summer of Code website between March 16 and March 27.

Just like our Mac client, you can now use GitHub for Windows to submit pull requests to GitHub or GitHub Enterprise, right from your desktop.

We didn't forget forks, either! If you fork a repository and then want to contribute changes to the upstream repository, GitHub for Windows will keep track of upstream branches. This means less hassle when you're ready to contribute your changes back.

Download GitHub for Windows and start sending pull requests now!

We recently caught up with some of our friends at Epic Games in Cary, NC a few weeks ago to talk about the latest developments with Unreal Engine and Unreal Tournament. Since opening up the engine source code on GitHub a year ago, they've released seven major updates that incorporate an array of contributions from the community such as @SRombauts' git plugin and much improved Linux support.

Our latest OctoTale captured some of Epic Games' stories and some of the amazing work that's going on in their passionate vibrant community. We think you'll enjoy it.

And finally, some more exciting news for fans of the Unreal Engine: as of this week, developers can enjoy free access to Unreal Engine 4!

This Summer, CodeConf will return for the first time since 2011.

Join us in downtown Nashville on June 25 & 26 for the third installment of the CodeConf series, where the community will come together to continue the conversation around open source, best practices, documentation, and collaboration at a two-day, single-track conference at the beautiful Bell Tower.

Come to CodeConf to hear new talks from thought-provoking speakers, connect with the open source community, and to participate in workshops with expert instructors. Hear all the latest from GitHub and open source project maintainers, and enjoy local food and music with developers from all over the world.

Come with an open mind, leave a better programmer.

Check out the website to sign up for updates, and follow along with @codeconf on Twitter.

The GitHub Game Off, our very own game jam is returning next week! We've had some great games submitted in previous years and can't wait to see what you come up with this year.

We'll announce the theme and the details on the blog on March 13th at 9am PDT, so please stay tuned. We may even have a twist in store!

The official Twitter hashtag for the Game Off is #ggo15.

Patchwork Ann Arbor

We're excited to announce that our next Patchwork hack night will be on Thursday, March 12 2015, and co-hosted with our friends at Nutshell in Ann Arbor, Michigan.

No coding experience needed

Patchwork is a hands-on workshop for learning Git and GitHub. Join us for a night of hacking and snacking and make some new friends while you're at it!

Forks you don't eat with? Branches not made of wood?

Newcomers to Git and GitHub: you'll leave with a merged Pull Request, a square on your contributions graph, and confidence to get more involved in the open source community.

Mentors: if you've ever had a Pull Request merged, now is your chance to share the love and help someone else create magic.

Learning is better together

@jatoben and I, along with local community mentors, will be on hand to walk you through the Hello World tutorial, answer your questions, help you create your first open source project and achieve your first merged Pull Request.

We'll begin with a story about getting started in programming, spend time on the tutorial in small groups, and then close things out with a lightning talk from our friend Julie Cameron from Girl Develop It (@jewlofthelotus).

Details:

• For: Git and GitHub beginners.
• When? Thursday, March 12, 2015 6:30-9:30 pm
• Where? Nutshell, 212 South Fifth Ave, Ann Arbor, MI 48104
• RSVP:
  • Want to learn Git and Github? RSVP as an attendee.
  • Want to help guide future open source maintainers and contributors? RSVP as a mentor.

Once registered, you'll receive an email the day before the event with details about the tutorial.

Food and refreshments will be provided. This facility is wheelchair friendly.

Gather your Ruby and Perl and get your ship ready to set sail into the Sea Es Es with the new Piratocat Shirt.

Watch out for that Octokraken!!!

Available in the GitHub Shop

The Game Developers Conference (GDC) is just a couple of weeks away, and we're giving away 20 expo passes so you can get in on the fun!

In addition to the expo itself, these passes give you access to all the gaming goodness you can handle, including the Game Career Seminar, the Independent Games Festival, and the Game Developers Choice Awards. For more information, please see the GDC passes page.

If you'd like to enter the contest, simply fill out the following short form and tell us about your favorite gamedev-related GitHub repository before Tuesday February 24th 11pm PST. GitHub employees will pick their favorite 20 submissions, and the winners will be contacted via email the following day. All winners will be responsible for their own accommodation and transportation.

Photo credit: Official GDC, CC BY 2.0

Don't forget to swing by the GitHub booth and say hi if you're there!

We’ve just redesigned GitHub for Mac’s Changes tab to make it even easier to review lots of changes, and to see what will be shared before clicking Sync:

This means that you can focus solely on what’s most important to you: your changes.

We’ve also simplified and improved the process for fixing up a commit you’ve just made. Just click the “Undo” button in the pane that appears:

And if you don’t want to worry about manually syncing your changes after committing, you can enable “Automatically Sync after Committing” from the Edit menu:

This is yet another step toward our grand vision for GitHub for Mac, with plenty more to come, so give it a shot! If you already have GitHub for Mac installed, it will update itself to the latest version automatically.

As always, we’d love to know what you think. If you have any comments, questions or bug reports, please let us know.

Git Merge 2015 is heading to Paris April 8-9, and tickets are now on sale! Join us at the beautiful La Gaîté Lyrique for two days of Git festivities.

Tickets are $99 USD, and all proceeds will be donated to the Software Freedom Conservancy. Check out the schedule breakdown below:

April 8th: The Warm Up

On Wednesday, we've lined two options for you to choose from:

If you're looking for some serious skills, sign up for advanced Git training from 11am-3pm. Become a Git expert as you learn from some of the best trainers in the world in a casual workshop setting.

If you're looking for an adventure, join your fellow Git Merge attendees for guided tours of Paris, specially curated for you. Explore and enjoy Parisian food and culture before the conference gets underway.

By invitation only, we will also be holding a Git Contributors Summit on Wednesday for contributors and maintainers of core implementations. Email us at events@github.com if you're a Git contributor who would like to attend.

April 9th: The Main Event

Registration will open at 9am and the main event kicks off at 10am. We've assembled a group of speakers doing amazing things with Git, like:

• Junio Hamano, Google
• Rick Olson, GitHub
• Angelos Evripiotis, Bloomberg
• Emma Jane Hogbin Westby, author of Git for Teams
• John Garcia, Atlassian
• Dirk Lehmann, SAP
• Wilhelm Bierbaum, Twitter
• Edward Thomson, Microsoft

There will also be plenty of opportunities to discuss, learn, and collaborate on the future of Git with everyone in attendance. And of course we'll wrap up the evening with a Git birthday party that you won't want to miss.

We hope you'll join us in Paris to celebrate 10 years of Git and the future of things to come. Check out the full site for more details, and to purchase your ticket.

Our newest shirt comes in two colors and makes it socially acceptable to write on your clothing with your GitHub username or project name.

Available in the GitHub Shop.

The Git developers have just released a major new version of the Git command-line utility, Git 2.3.0.

As usual, this release contains many improvements, performance enhancements, and bug fixes. Full details about what's included can be found in the Git 2.3.0 release notes, but here's a look at what we consider to be the coolest new features in this release.

Push to deploy

One way to deploy a Git-based web project is to keep a checked-out working copy on your server. When a new version is ready, you log into the server and run git pull to fetch and deploy the new changes. While this technique has some disadvantages (see below), it is very easy to set up and use, especially if your project consists mostly of static content.

With Git 2.3, this technique has become even more convenient. Now you can push changes directly to the repository on your server. Provided no local modifications have been made on the server, any changes to the server's current branch will be checked out automatically. Instant deploy!

To use this feature, you have to first enable it in the Git repository on your server by running

$ git config receive.denyCurrentBranch updateInstead

When shouldn't you use push-to-deploy?

Deploying by pushing to a Git repository is quick and convenient, but it is not for everybody. For example:

• Your server will contain a .git directory containing the entire history of your project. You probably want to make extra sure that it cannot be served to users!
• During deploys, it will be possible for users momentarily to encounter the site in an inconsistent state, with some files at the old version and others at the new version, or even half-written files. If this is a problem for your project, push-to-deploy is probably not for you.
• If your project needs a "build" step, then you will have to set that up explicitly, perhaps via githooks.

See how this feature was implemented

Faster cloning by borrowing objects from existing clones

Cloning a remote repository can involve transferring a lot of data over the network. But if you already have another local clone of the same repository, it probably already has most of the history that the new clone will need. Now it is easy to use those local objects rather than transferring them again:

$ git clone --reference ../oldclone --dissociate https://github.com/gitster/git.git

The new --dissociate option tells Git to copy any objects it can from local repository ../oldclone, retrieving the remainder from the remote repository. Afterwards, the two clones remain independent; either one can be deleted without impacting the other (unlike when --reference is used without --dissociate).

See how this feature was implemented

More conservative default behavior for git push

If you run git push without arguments, Git now uses the more conservative simple behavior as the default. This means that Git refuses to push anything unless you have defined an "upstream" branch for your current branch and the upstream branch has the same name as your current branch. For example:

$ git config branch.autosetupmerge true
$ git checkout -b experimental origin/master
Branch experimental set up to track remote branch master from origin.
Switched to a new branch 'experimental'
$ git commit -a -m 'Experimental changes'
[experimental 43ca356] Experimental changes
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:master

To push to the branch of the same name on the remote, use

    git push origin experimental

$

The new default behavior is meant to help users avoid pushing changes to the wrong branch by accident. In the case above, the experimental branch started out tracking master, but the user probably wanted to push the experimental branch to a new remote branch called experimental. So the correct command would be git push origin experimental.

The default behavior can be changed by configuring push.default. If you want to go back to the version 1.x behavior, set it to matching:

$ git config --global push.default matching

See how this feature was implemented

More flexible ssh invocation

Git knows how to connect to a remote host via the SSH protocol, but sometimes you need to tweak exactly how it makes the connection. If so, you can now use a new shell variable, GIT_SSH_COMMAND, to specify the command (including arguments) or even an arbitrary snippet of Shell code that Git should use to connect to the remote host. For example, if you need to use a different SSH identity file when connecting to a Git server, you could enter

$ GIT_SSH_COMMAND='ssh -i git_id' git clone host:repo.git

See how this feature was implemented

The credential subsystem is now friendlier to scripting

When Git needs a password (e.g., to connect to a remote repository over http), it uses the credential subsystem to query any helpers (like the OS X Keychain helper), and then finally prompts the user on the terminal. When Git is run from an automated process like a cron job, there is usually no terminal available and Git will skip the prompt. However, if there is a terminal available, Git may hang forever, waiting for the user to type something. Scripts which do not expect user input can now set GIT_TERMINAL_PROMPT=0 in the environment to avoid this behavior.

See how this feature was implemented

Other

Some other useful tidbits:

• Now Git is cleverer about not rewriting paths in the working tree unnecessarily when checking out particular commits. This will help reduce the amount of redundant work done during software builds and reduce the time that incomplete files are present on the filesystem (especially helpful if you are using push-to-deploy). See how this feature was implemented
• Now git branch -d supports a --force/-f option, which can be used to delete a branch even if it hasn't been merged yet. Similarly, git branch -m supports --force/-f, which allows a branch to be renamed even if the new name is already in use. This change makes these commands more consistent with the many other Git commands that support --force/-f. See how these features were implemented

Additional resources

• The main Git website
• The book Pro Git (available online); including its chapter about installing Git
• GitHub's Guide to setting up Git and other help articles

Don't forget: an important Git security vulnerability was fixed last December. If you haven't upgraded your Git client since then, we recommend that you do so as soon as possible. The new release, 2.3.0, includes the security fix, as do the maintenance releases 1.8.5.6, 1.9.5, 2.0.5, and 2.1.4, which were released in December.

While making your source code available in a public GitHub repository is awesome, it's important to be sure you don't accidentally commit your passwords, secrets, or anything else that other people shouldn't know.

Starting today you can commit more confidently, knowing that we will email you if you push one of your OAuth Access Tokens to any public repository with a git push command. As an extra bonus, we'll also revoke your token so it can't be used to perform any unauthorized actions on your behalf.

For more tips on keeping your account secure, see "Keeping your SSH keys and application access tokens safe" in GitHub Help.