Open Source, Software Hygiene and STDs

Sep 17

Written by: Stephen Walli
9/17/2012 9:51 AM  RssIcon

 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 of “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.  Today, James Governor reminded me of this madness when he tweeted:

I replied:

Pretty soon, a lively discussion was off and running with @nearyd, @mmilinkov, @webmink, @dberkholz, and @tieguy joining in.  (Well as lively as Twitter can get.)

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

Not caring, or naively believing it doesn’t matter because you believe “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 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 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.


3 comment(s) so far...


Re: Open Source, Software Hygiene and STDs

Great article.

I have some experience on this matter. I initially published iText under the MPL/LGPL with the motto 'no money, no worries'. My naive idea: if I don't ask money for my software, I won't have any worries.

Boy, was I ever wrong! iText was almost killed because of its popularity. My 'wishlist' was buried under my 'TODO' list. I needed my dayjob to make a living, and I needed my free time to answer questions from the community. I didn't have any time to do core development anymore. I didn't have a life anymore.

After doing a thorough IP review (throwing away all code of which the ownership wasn't clear), we switched from the MPL/LGPL to the AGPL. That was an unseen move: people really hated me for that. Little did they know that the decision was made with great care, after almost a year of trying out different business models and making a detailed SWOT analysis.

Now we've been 'in business' for almost 4 years. I funded my first company with the Royalties from my first book. I created my fourth company with the revenue from my second company. It's a long story, but I've bootstrapped a group of companies and the global turnover has been growing for 11 quarters in a row. We're using that money to invest in the development of new software: I can finally afford a technical staff to handle my TODO list; I can hire developers to help me with my wishlist. All of this wouldn't have been possible if I had kept the MPL/LGPL. I would still have my dayjob, and iText would have faced a slow death.

I really doubt if licenses that are too liberal are healthy for innovation. Liberal licenses are fine when you're starting something new; they're OK when you're a really big player. But they don't get you anywhere when you're playing in the middlefield. Just ask yourself this: "Why would a developer create software that can be used by anyone, but that is valued by no one?"

If your answer is "To become a famous developer", I have to disappoint you: I've been there, and done that. At some point half the world was sending me mails saying "Hi Lowagie, I have question. U need to help me! Is urgent!"

Is that really the way you want to treat a passionate developer?

By Bruno Lowagie on   9/19/2012 10:57 PM

Re: Open Source, Software Hygiene and STDs

Unfortunately, even with a license, it often stays a mess. Many teams still consider the "free as in free beer" above the "free as in freedom". I am not saying this is necessarily a problem, just an observation.
While having a license is very important to indicate allowed use of software, this is also a choice which is often taken too lightly. Few developers I have met have a clear idea about the differences between licenses and the various consequences these differences have. This large set of often incompatible open source licenses limits the "free as in freedom" aspect quite a lot. I think there should be a move to inform people better and to urge them to limit their choice to a small list of existing licenses.

By Joachim Van der Auwera on   9/20/2012 10:52 AM

Re: Open Source, Software Hygiene and STDs

Joachim, I understand your point of view as a user of F/OSS, and I know you've been working for a company that has developed a business model selling SLAs for a F/OSS project that was developed in-house. I liked your blog explaining the differences between some of the most important licenses.
I have an addition to this "Don't publish software without a license blog". My message: "Don't publish software without knowing your business model." I was a developer before I became an entrepreneur. I've made many mistakes, and I have learned from those mistakes: :

By Bruno Lowagie on   9/21/2012 12:52 AM

Your name:
Gravatar Preview
Your email:
(Optional) Email used only to show Gravatar.
Your website:
Security Code
Enter the code shown above in the box below
Add Comment   Cancel 

Blog Roll

Indent Example
Sam Ramji
Thoughts from the President of the Board of Directors
Indent Example
Paula Hunter
On the business of OSS and Non Profit Foundations
Indent Example
Stephen Walli
Guest Blogger
Indent Example
Phil Haack
Project leader: NuGet
Indent Example
Bradley Millington
News from the ASP.NET Gallery Manager
Indent Example
Bradley Bartz
WebsitePanel Project Leader
Indent Example
Guest Blogger
Posts from Guest contributors
Indent Example
Posts from DLSI Gallery Manager
Indent Example
Rob Mensching
WiX Project Leader
Indent Example
Eric Schultz
Developer Advocate
Indent Example
Bertrand Le Roy
Orchard project updates and news
Indent Example
Posts from Outercurve Staff