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. 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. 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!

Community Management is a Career, Not a Job

The Power of the Open Source Periphery