Shouldn’t digital preservation tools be released under the GNU General Public License?

For me, this is a first foray into understanding software licensing…

Licensing bores me. If I’ve written code and it is somewhere out there in public view and I haven’t licensed it, you can take it from me that you can pretty much do what you want with it – but please try to be fair in your attribution.

I’ve met the people who are most likely to have an aneurysm over whether a piece of software is licensed correctly for their own use and I’m not going to lose sleep over them, and as for passive aggressive open source developers who complain: “Oh, look, it’s another github/bitbucket project without an open source license. That means, friends, it is not to be used…” – write an email to the developer, ask them for their terms and to update their source code – it’s not that difficult! (N.B: The irony of my approach in the last two sentences is not lost on me.)

Yep. This stuff bores me. I write this with two licenses in my GitHub repositories – Beerware and zlib – and that probably says more about ego (or low self-esteem!) than anything. More accurately, I’m quite aware that I simply haven’t written anything particularly innovative or useful that warrants more complicated licensing documentation.

The digital preservation community, however, might have! And that’s the crux of my question.

Shouldn’t digital preservation tools be released under the GNU General Public License?

In researching the license used by a tool, similar in nature to the one I am currently working on, I notice that it is licensed under the GNU Lesser General Public License – LGPL. I have no qualms about that. I simply noticed the GNU’s link: ‘Why you shouldn’t use the Lesser GPL for your next library‘.

If you’re not familiar with the text, you should take a look. The GNU make some interesting arguments:

If we amass a collection of powerful GPL-covered libraries that have no parallel available to proprietary software, they will provide a range of useful modules to serve as building blocks in new free programs. This will be a significant advantage for further free software development, and some projects will decide to make software free in order to use these libraries. University projects can easily be influenced; nowadays, as companies begin to consider making software free, even some commercial projects can be influenced in this way.

And:

“We free software developers should support one another. By releasing libraries that are limited to free software only, we can help each other’s free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition.”

Given that the tools we will write in our field will nearly almost always be unique and have an edge over proprietary alternatives it leads me to ask: Shouldn’t we release all of our tools to be used only in free software?

The benefits seem clear:

  • GPL digital preservation software could only be used in free digital preservation systems. 
  • Current, free digital preservation solutions would be given a competitive advantage.
  • New systems may appear – creating more competition and therefore innovation.
  • It would give all institutions using free systems the opportunity to use the most advanced and up-to-date tools. 
  • Greater breadth of contributions to digital archive software across key sectors: public, private, research and education.
  • The wheel is not reinvented to seek a way around license limitations.
  • Tools could be evaluated, improved and accepted quicker by a larger user base.
  • A true, free, digital preservation software community could arise – putting the discussion of tools and approaches on a completely level playing field.

After all, archives should be open and democratic – why not the software?

Perhaps more relaxed licenses are required to wrap institutionally built tools because too many organizations are supported by, and bound to, proprietary products that enable them to do their work?

It is interesting to think what the digital preservation landscape might look like in a few years if developers unanimously adopted a GPL-style approach. But these are just some foetal thoughts in my first proper attempt at understanding software licensing. The GNU model might not be appropriate at all. I’m not sure…

What license should we be releasing open source digital preservation tools under?

Addendum: I really do like CC-BY-SA but it’s not considered suitable for licensing software. I think it’s a good middle ground that at the very least sees code improvements fed back into the open source community. Does anyone want to take up the challenge of creating a digital preservation version that applies to software?

Loading

10 thoughts on “Shouldn’t digital preservation tools be released under the GNU General Public License?

  1. Beerware – http://en.wikipedia.org/wiki/Beerware

    In all seriousness though, I have no particular objection to anybody attempting to monetize their work. If it’s crap it will /hopefully/ quickly die.

    That said, any work I do officially is paid for by the public purse, so therefore should be as open as possible. I assume you’ve probably seen TNA’s software licensing guidance for UK government: http://www.nationalarchives.gov.uk/information-management/government-licensing/licensing-software.htm – it also provides a link to ‘approved’ OS licenses that UK gov depts can release under – http://opensource.org/licenses/index.html

  2. Ross,

    This topic doesn’t hugely grab me either, but like you I realise it’s important stuff! While my heart says support open source as much as we can, I feel a need to act as devils advocate and make the case for some pragmatism here…

    You say that “free digital preservation solutions would be given a competitive advantage”. But which solutions exactly. There aren’t very many. Can we afford to disadvantage the commercial ones? Wouldn’t libraries and archives actually like to see more (and better) commercial solutions in this space?

    Some of the relevant issues get touched on in this slightly broader discussion:
    http://blogs.ch.cam.ac.uk/pmr/2010/12/17/why-i-and-you-should-avoid-nc-licences/

    1. That’s an extremely good link Paul. I’m certainly drawn to CC-BY type licenses. I do like the point in the comments that by allowing commercial entities to use the work you aren’t /preventing/ your work from being shared freely. I guess the final point in that same comment (http://blogs.ch.cam.ac.uk/pmr/2010/12/17/why-i-and-you-should-avoid-nc-licences/#comment-81883) is that commercial entities are part of the ‘open’ ecosystem. A rather important point if commercial vendors are able to make high value contributions to improve their own product. As I fall back to in my blog post in the addendum, I do like CC-BY-SA. This should provide a greater guarantee that those using your work, commercial or non-commercial contribute back.

      If I continue playing devils advocate myself on the GPL path and consider how commercial entities might not be disadvantaged and still operate happily is in the case where they would sell support instead of the product. Support costs might go up – a disadvantage to those using the system maybe but then there will be a greater emphasis on support which brings its own advantages.

      Thanks for the comments, I’ve definitely got a few more things to think about!

  3. Hi Ross,

    As you’re using jpylyzer as an example: when I decided to release jpylyzer under a lesser GPL I was well aware of GNU advising against it. The reason for picking this license anyway was simply that I realised that this software would only be of interest to a very restricted niche group of users. In order to promote adoption I wanted as few restrictions on its use as possible, which ultimately led to the lesser GPL. Of course this means that any commercial vendors that would like to incorporate jpylyzer in their products are free to do so, but in this case I have no problems with that. For projects with a larger (potential) user base I would probably be more inclined towards a regular GPL.

    Johan

    1. Thanks for the extra clarification Johan. I guess we might not be at that stage in the discipline where demand is great enough to dictate such terms for the tools we create? – Interesting thought.

  4. Free software isn’t free in terms of all costs. The Archivematica people compare free open source to a free puppy or kitten: no cost to acquire, but always some expense to manage over time. http://blogs.loc.gov/digitalpreservation/2012/10/archivematica-and-the-open-source-mindset-for-digital-preservation-systems/ In principle, I totally support open source digital preservation tools, but there is definitely a role for proprietary solutions; the latter might even be easier for some institutions to implement and manage. The key is an open architecture that permits movement to another platform when that’s necessary in the future.

    Having said that, open source licensing is important for multiple reasons. Perhaps the most basic is the ability to publicize and share code. Decisions about licensing are usually demanded by institutions and their lawyers before letting anyone else see it.

    1. Bill, that’s a fantastic article, thanks for sharing. I really like the analogy free as in puppies/kittens. The rationale behind Archivematica open sourcing their work is really interesting too. It makes very good sense that way around. I can appreciate the point of proprietary software (I use plenty of it daily). As you say, the most important thing is for proprietary software to adopt open-architectures / non-proprietary standards. That way compatibility and future-proofing of components is at a a maximum – I think that’s an important point.

  5. I am probably one of those people that you refer to who take software licensing too seriously.

    However, have you considered that GPL limits adoption? GPL is a viral license, whilst it stands for freedom it explicitly imposes its concept of freedom on any code that links GPL code.I could not link for example a BSD licenced project to a GPL licenced project without GPL being applied to the original project.

    Personally I prefer a free and open licence which declares my free intentions hut does not impose them on others.

    1. Adam – the impact, or implications rather, about how one interacts with other open source licesnes is of course a concern. If I interpret the GNU view of GPL correctly then there is a certain amount of if you start using it, others will adopt it, and eventually there is little impact on open source developers. The impact for commercial developers remains. There’s a trade-off but I hadn’t considered how un-democratic that might actually be, it’s a good point. Thanks for the comment.

Leave a Reply

Your email address will not be published. Required fields are marked *

Follow

Get every new post delivered to your Inbox

Join other followers: