The Red Herring of Open Source Licensing


There has been a lot of drum beating of late on the topic of the increasing irrelevance of Open Source licensing, & the loudest drummers seem to be Tim O'Reilly & Matt Asay. Matt's recent blog post touches on some great points in this discussion, not the least of which is:

"The real value in open-source software is no longer the software, but rather the resultant services that are delivered over the Web"

This is spot on, and we (the industry) need to move beyond the 'licensing hiccup' that seems to permeate every conversation we have around Open Source (especially in government & enterprise). While I'll preface my statements with the standard disclaimer of 'IANAL', for 'community source', or 'innersourcing' discussions, I think that everyone gets way too wound around the axle on what the license is, and the relative merits of each possible alternative.

I completely agree with Matt's point about the licenses being irrelevant because of the delivery mechanism, however, I'd also add another area where they are less critical is in internal projects behind corporate firewalls. You might be saying, 'Wow, that's a pretty strong statement'. Yes it is, but I think it gets us down to what I hope the really important discussion is - using the collaborative practices of Open Source (the 'Open Community Approach') regardless of whether the license is BSD, GPL, LGPL, or even a custom internal distribution rights clause.

When your application is going to be used for internal purposes (such as what my team at CollabNet is enabling in Forge.mil within the DoD), you should be focusing on how to take advantage of the unique capabilities enabled by the community approach. Before anyone objects too strongly, of course you need to pass all of this by your legal team, but we all need to be advocates for harnessing the key aspects of Open Source, and quite frankly, licensing is not a key differentiator anymore, especially for internally developed & fielded code.

If your system will only ever be delivered within your own firewall, I say, relax, and focus on using the approaches of Open Source (transparent development, open collaboration, meritocratic contribution model) in your projects. The value of innersourcing lies in the ability for project teams to tap into the same kinds of best practices that made projects such as Linux and Apache successful. Increasing the transparency of what is being developed internally also helps break down silos (or at least identifies them so that senior leaders can make informed decisions).

At the end of the day, using Open Source effectively within your organization should be your primary motivator, and if your focus is strictly on risk management or licensing, you are missing the larger, richer part of the Open Source ecosystem.

Comments

  1. AnonymousJuly 6, 2009 at 4:58 PM

    I don't think you and Matt are talking about the same things. I'm pretty sure Matt doesn't even care about "using the approaches of Open Source in [internal] projects": he's on a riff about "Commercial Open Source" development. Conversely, while you do get around to clarifying your area of focus, about mid-post, your lead in, understood from Matt's perspective, claims agreement with something I think you don't actually agree with.

    If I may recast Matt's dictum in other, more widely and recently familiar terms, he might be saying:

    "The real value in sub-prime mortgages is no longer the integrity of the lending institution, but rather the house you buy with it."

    It's true, houses *are* the point of mortgages. But the value of healthy financial institutions, to the borrower and to the country at large, has lately become quite obvious as well.

    FOSS was invented out of the necessity of commercial failures to respect and provide sustaining value. Companies cease to exist if they can't provide sustaining value, if course, and many did over such failures as commercial UNIX. But users also suffered, and the FOSS choice is to avoid that risk.

    Whether you use your FOSS to provide web services, run mobile phones, or just play a good game of Star Trek, you lose if your commercial provider goes under. But you at least have a chance of survival, if you depend on FOSS: someone, perhaps even you, can and may pick it up and run with it.

    And even within a closed ecosystem, this can be valuable. The license isn't so hard to choose, but it still matters, it's still there even if implicitly. If you think projects and subgroups and divisions and sectors of commercial companies or government agencies never fail, you really need to spend more time in those area! And when they fail, the code, history, discussions, bug base, and other related artifacts remain crucial to successful continuation.

    ReplyDelete
  2. Guy MartinJuly 9, 2009 at 6:37 PM

    Excellent points Jack - yes, I didn't make it quite as clear as I would have liked in those first couple of paragraphs.

    I've updated the post to reflect the fact that I think Matt's thoughts are one aspect of why OSS licensing is less of an issue now, with the innersourcing piece I referred to as another reason.

    ReplyDelete

Post a Comment

Popular posts from this blog

Great Panel Discussion!

Thanks to Gwyn Firth Murray , Larry Augustin , and Jeff Luczcz for a very entertaining panel discussion around Open Source at the recent eBig meeting . I was a bit nervous about how this panel would come together since I was the 'rookie,' whereas Gwyn had worked with Larry and Jeff separately before. However, the commonality of the passion for Open Source brought this panel together nicely and there was an excellent exchange of ideas between and amongst the panel (as well as our audience). I think we had someone in the audience comment on the fact that it seemed like we had all known each other a long time! :) The areas we covered during the talk were: licensing, community development, and reasons for using Open Source. I think the panel all agreed on good reasons for using Open Source, with all of us giving cogent examples of what the value proposition for using Open Source is (taking advantage of the huge amount of R&D and work that goes into good Open Source project...
Read more

Community Management is a Career, Not a Job

'Community Management' is a hot topic, & a hot job field , but I think it's important to articulate that it's not a role which should be approached as a 'job'. What do I mean by that? Community Management should NOT be: A role you 'settle' for because you can't do other things Something you do as an ancillary part of your 'real job' Something you get into 'because it's hot right now' A position that you can perform in isolation, without constant upgrading of your skills/knowledge I've talked in the past about what kinds of skill sets I believe are necessary to be an effective community manager, and as I thought about my own career path, I realized that early on in my community management career, I considered myself an engineer doing community management, whereas I now think of myself as a community manager with an engineering background. It is a subtle, yet hugely important difference - one that allows me to draw on a...
Read more

The Power of the Open Source Periphery

Like a lot of people in the tech world, I try to read a variety of publications (both online and physical versions) to keep up with what is going on in the dizzying world of technology. Recently, I read a great article in a recent issue of Wired entitled Accept Defeat: The Neuroscience of Screwing Up . This article explains in some detail, with examples, the problem of 'failure blindness' in scientific research. This phenomenon causes scientists and researchers to ignore anomalies in their results they didn't expect, which are therefore categorized as 'failures'. The article goes on to state that one of the best ways of overcoming this bias is to involve other people from outside of your immediate speciality in discussions about your results. For me, this triggered the thought process of why it's important to encourage participation in your communities (Open Source or internal) from folks on the periphery of your project - non-specialists who have somethin...
Read more