Simon Phipps, director of the Open Source Initiative, pointed out a problem late in 2012 with GitHub, the popular open-source development community site. Most of the GitHub-hosted projects did not have any license. By default, that made the programs subject to copyright protection with all rights reserved exclusively for the author. This means it's not open source at all! Months later, GitHub's executives have finally addressed this glaring problem by adopting a new policy to encourage developers to use proper open-source licenses.
The first move GitHub made to make their site more truly open-source friendly was to reset the site. Now when you start up a new project with the Git distributed version control system (VCS) file repository you're given a choice to add an open-source license to your project immediately.
If you can't tell the differences among the patent-aware Apache License, the anything goes MIT License, or the restrictive GPLv3 license, worry not. GitHub now has a simple site, ChooseALicense that gives you some direction.
Of course, if you have hopes for your project to go commercial you'll need more legal guidance than this site provides, but still it's a good start.
If you choose to create a new public repository and not to use a license be aware that you're going to be waiving some of your copyright rights. Specifically, according to GitHub's new Terms of Service, Section F, "By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."
The key word is "fork." Unless you want to share your work without having any control over what happens to it next, you're going to run to either keep your GitHub project private or put it under an appropriate open-source license.
It's a good thing that GitHub is doing this because its users' various project licensing was actually far messier than anyone knew.
Black Duck Software, the leading open-source legal software and consulting company, turned out its new Black Duck Suite 6.5 with its Deep License Data feature on GitHub and other public open-source file repositories. This version can examine source code for embedded licenses that exist within projects having no declared license.
Black Duck did this because “The lack of a declared license for an open source project can cause an enterprise to steer clear of it, limiting the projects organizations can use,” explained Mark Driver, Gartner's VP and Research Director in a statement. “The ability to access embedded license information and obligations up-front during the code selection process opens a sizable opportunity for enterprises and could have significant impact on their bottom line.”
What Black Duck found was distributing for anyone who planned on using many GitHub projects. Black Duck found "that 77 percent of projects on GitHub have no declared license, compared to only 7 percent of projects from all other open-source forges."
Worse still, "Further analysis from Black Duck’s Deep License Data shows that of this 77-percent, 42-percent of GitHub projects actually have embedded licenses that carry specific obligations for use. Providing up-front visibility into embedded licenses and their associated obligations gives organizations the insight needed to make informed decisions about using such projects, and dramatically expands the open-source adoption opportunity."
What all this means for developers is that, if you want your code to be used by anyone else than you and your buddies, you must check to see if the code you've borrowed from elsewhere already has a license attached to it. In short, you must pay attention to open-source licenses. If you get your licensing ducks all in a row, it will make it much more attractive to other developers and businesses.
For enterprises considering using open-source programs from GitHub, or other public sites, Black Duck President and CEO, Tim Yeaton thinks using Black Duck Suite to find licensing problems before they can bite you only makes sense.
“We’ve analyzed one million projects for embedded license information so our customers can access it at the beginning, and also throughout, the development process," said Yeaton in a statement. "As a result, more projects can be considered for use during the code selection stage of development – enabling developers to make informed component choices, and allowing enterprises to build better software faster, confident from the start that they can meet the code’s license obligations for use."