The new software hygiene: Declare a license or risk losing participation

No readers like this yet.
User experience vs. design
Image by:

Opensource.com

I had the privilege of working with David Tilbrook almost 25 years ago. He was the first person with whom I ever worked that clearly articulated proper software construction discipline for collaborative endeavours and captured a summary of it under the title, Washing Behind Your Ears: Principles of Software Hygiene.

David articulated these practices pre-World Wide Web. We weren't yet living in a world where the Web had so completely removed the friction of time and space from sharing and collaborating on software that even the early Internet enabled.

The open source definition hadn't yet been coined. The forges hadn't yet been built.

The world has progressed and there's a new sort of software hygiene that's now required. I first learned back in May 2012 that one of the most popular software collaboration forges, Github, doesn't require a project creator to choose a license for their software. On September 17th, 2012, James Governor (@monkchips) reminded me of this madness when he tweeted:

younger devs today are about POSS - post open source software. f### the license and governance, just commit to github

I (@stephenrwalli) replied:

Governance implies community but promiscuous sharing w/out a license leads to software transmitted diseases

Pretty soon, a lively discussion was off and running with @nearyd, @mmilinkov, @webmink, @dberkholz, and @tieguy joining in.

Here's the problem: governments protect software creations using copyright law. Different governments have different views of how it applies and slightly different terminology. Some countries worry about author's moral rights. Others don't. Countries also have different opinions on what the public domain means and how it can (or can't) be applied with respect to software. Essentially, as with all things in the software legal space, it's a mess.

Disclaimer: This is probably a good time to remind the reader that I am not a lawyer.

Living in a proprietary software world, it was relatively "easy". Companies asserted their copyrights as protection for their software products. As software publication and collaboration became ubiquitous, we saw the rise of free and open source software licenses. These were used as statements of sharing intent and expectation by authors on their works. If a collaborative community arose around the project, these licenses were often the initial declaration of the social contract long before the community ever evolved to statements of governance and codes of conduct.

So here's the problem. If you share software on the Internet without using a license, the software is protected by your copyright and all rights revert to you. You have made no statement about how it might be used, or what you would agree to, now or in the future. If you share on a promiscuous site like Github, where forking is encouraged, and you make no such sharing statement, and start accepting change requests from other developers without licenses, then you're collectively creating a copyright mess that will eventually hurt people using your software.

By not caring, or naively believing it doesn't matter because you think "people can do whatever they want with my software," or worse using others' unlicensed software in your own means, you will eventually hit a point where you stifle the growth of your software.

It's not that you're necessarily creating a provenance mess where "dirty" IP will creep into the mix (although I'm sure some companies will try to provoke that fear to sell you things, or worse sell other people things to "protect them" from your software). It's very possible that you could create a "Software Transmitted Disease", but what you are definitely doing is limiting your project's growth.

Professional developers have a working understanding of software copyright. By professional, I mean developers more knowledgeable than you that can make your project better through contribution. When they see that there's no license on your pool of software, if you're lucky, they will ask you to declare one so they can know if they want to adopt and contribute. If you're not so lucky, then they will simply move on and you will have lost whatever contributions they may have brought to your party.

I'm not talking about Great Knowledgeable Developers who are going to join your project and stay. If you're lucky, you'll attract a few folks to your world that know a few things more about it and share them. That's ultimately the economic strength of a well run open source project. Collectively we're better. Neither am I talking about what you might need to do when Building a Big Community.

I'm simply talking about sharing your software brilliance. Because that's why you published on a site like Github, right? So you could share and learn. If you don't put a license on it, you risk losing knowledgeable participation.

So here are some bumper sticker banners to help remind you of the necessary software hygiene of the new millennium:

  • Github without licenses is like free sex without condoms.
  • Practice safe software on the Internet—use a license.
  • Practice good software hygiene—license your software.
  • Don't fork around without a license.

Collaborative development with liberal open source licenses is one of the best things that has come out of the World Wide Web phenomenon and helps sustain and grow it. Do it wisely.

Originally posted on the Outercurve Foudation Blog. Re-posted with permission.

Tags
Law
Intellectual property
Programming
Licensing
GitHub
Stephen R. Walli
User profile image.
I am a technical executive, a founder, a consultant, a writer, an international business person, a systems developer, a software construction geek, and a standards diplomat. I love to build teams and products that make customers ecstatic. I have worked in the IT industry since 1980 as both customer and vendor.
More about me

4 Comments

Avatar
Richard Fontana | September 27, 2012
No readers like this yet.

To the extent that this is specifically a criticism of GitHub, I think you're exaggerating what is at most a small problem. I spend a fair amount of time perusing GitHub repositories and it is rare that I don't see some global indication of a license (this is the sort of thing I naturally look for first since IAAL).

On the other hand, one does encounter annoying cases of publicly-available software with no clear licensing information (where a vague intent for the software to be 'open source' is likely present) but it is hardly unique to GitHub and may well be less frequently encountered on GitHub.

BTW there are also cases where not including a license is entirely justifiable. I'll give you an example of something I put on GitHub (with helpful fixes from my colleague Brett Lentz), a quickstart for getting a Showoff presentation running on OpenShift:
https://github.com/richardfontana/showoff-openshift-quickstart

I initially included a copy of CC0, but as you can see here
https://github.com/richardfontana/showoff-openshift-quickstart/commit/0a78aaa95044f33f58f9f731a2123830afea8715
I deleted it, deciding it was offensive to even suggest something as trivial as this little quickstart was copyrightable and worthy of the complex license-and-waiver of CC0.

While I'm sure you have more substantial material in mind, I do not believe GitHub should mandate inclusion of an open source license if only because there will be some cases where a license is superfluous at best.

Avatar
hoijui | October 2, 2012
No readers like this yet.

i totally agree with this article!
it is very important to include licensing info, and i do not think it can ever be considered offensive to include a license, no matter how trivial the content.
i would also like to give a good counter example here:
Maven central entrance policies.
Maven is the modern standard for java project management (think of it as a sort of Makefile with a LOT more features).
Maven central is the default package repository for java software, especially libraries. since some time now, to be able to release a software on maven central, it is required to include license info.
this is very good!
but there is still one problem:
the license info consists of a list of one or more entries of licenses, each one consisting of a name and URL. the name is plain text, which means, it might be "GPL", "GNU GPL", "GNU General Public License", "General Public License", ...
which is exactly what happens in practice.

so, whoever works on trying to enforce licenses, please also include some mechanics to standardize at least the common licenses names.

Avatar
Brandon J. Van Every | October 14, 2012
No readers like this yet.

Google Code tried to solve this awhile ago. From 2006..2010, you got a drop down menu of ~7..9 possible license choices. That's it. The End. No license creativity allowed. They wanted to diminish license proliferation, the kind of confusion you talk about above, and also the minor customizations to license that individual authors would get creative about. They published a justification of their policy and it was defensible, whether everyone liked it or not. But the free market of course can choose other things. I bet GitHub can come up with its own justifications if it wants to.

In 2010 Google Code loosened up and allowed a catch-all menu option, "other open source" license. So a project is steered towards 9 common licenses, thus diminishing proliferation, but projects with more specific needs aren't turned away as before. It's a reasonable piece of menu driven social engineering.

Avatar
Brandon J. Van Every | October 14, 2012
No readers like this yet.

"Professional" software developers have other reasons to avoid amateur projects, not just license vagueness. So pitching license vagueness as the big reason "we're not helping you out" is disingenuous. Young people have a zillion things to learn about making an open source project worth something to others, and this is merely one of them.

When assessing a project, "did you actually release something that works?" is much higher up my list of priorities. I'm highly suspicious of any project that lives continuously out of a source repository and never makes official file releases or packages. I'm not interested in seeing if I can build your software! The vast majority of projects with that attitude, that it's my job to build the software, have lousy builds that don't work. I'm not interested in a time and effort barrier to decide whether a project is worth something; if they care that little for my time as a potential consumer or contributor, the project is probably not worth it.

No communication on a mailing list or forum is bad sign, especially if the lack of communication has gone on for years. Huge buckets of communication at the very beginning of the project is a bad sign, the "hey, let's start a mailing list!" phenomenon. Just check back later if they ever shut up and do any real work.

I am far more sympathetic to a culture of "just commit the effin' code" than not. At least it's a culture of getting things done. So it may not result in perfectly usable licenses. Maybe it'll crash and burn. The kiddies gotta learn somehow, and most open source efforts die anyways for all kinds of reasons. They'll either get back up and try again, lessons learned, or they won't.

Over the years I've run into more than a few projects that had a GPL or LGPL slapped on it. If I cared enough about the value of what they were up to, I've asked why they didn't offer a LGPL or MIT / BSD / zlib license instead. Generally I'm not interested in Copyleft restrictions and seek to diminish them, according to whatever seems reasonable for the library to do. I brace myself for a polemical response. But often enough, the developers hadn't put much thought into the license at all, and grabbed the first thing that they found talked about out in open source land.

Related Content

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.