When is Open Source not Open Source? - When it is not shared
It was remiss of me not to mention,Talking with Talis interviewee, Mark Leggott’s announcement that the University of Prince Edward Island had become one of the first academic libraries to migrate to the open source library system Evergreen. Their appropriately named Island Pines OPAC can be checked out here.
This was news in itself but the fact that the move from SirsiDynix Unicorn to Evergreen only took them a month, was even more impressive. A hat tip to Mark and his colleagues.
I was reminded of my omission by this post from Dan Scott. Dan assisted Mark and his team by creating a utility script that should be of assistance to SirsiDynix Unicorn or Symphony sites who are interested in exploring the possibilities offered by other library systems. These scripts use the Unicorn/Symphony API.
Mark Leggott insisted that Dan retained copyright over the scripts created during the UPEI migration, allowing him to share those scripts in the appropriate avenues. To that end Dan has shared them under a GPL v2 license.
You would think that the scripts are now available to all, but you would be wrong. As Dan says:
I am sadly (to the best of my knowledge) not free to simply share the script with anyone. Therefore, to gain access to the script you must be an API-certified Unicorn or Symphony customer.
So if you are an API-certified Unicorn or Symphony customer, you can download Dan’s work from the Unicorn API repository - the first .org for which I have ever needed a username and password to login, before I get to see anything.
This put me in mind of the old riddle - When is a door not a door? - When it is ajar! - When is Open Source not Open Source - when you need an account with a vendor to get at it.
Presumably Dan can’t share his work with the world so as to stop unscrupulous people from getting to know the secret sauce of the Unicorn API, and thus being able to export data from their SirsiDynix API. Of course if you are a Unicorn customer, with access to your ILS API, you will be able to login to sirsiapi.org and use Dan’s scripts to export your data. So that is all secure then - isn’t it?
Reading that last paragraph again, I’m still not clear who is protecting what from whom so that they couldn’t misuse the information to extract data from their own ILS in a way that would be detrimental to anyone. If anyone can enlighten me, I would greatly appreciate it.
Door ajar picture from Éamonn on Flikr
June 18th, 2008 at 11:07 pm
Richard, I think you’re confusing open source (that is, the ability to see and change the source code) with the distribution of that open source. My interpretation of information at the GPL web site is that the scenario you describe above is perfectly fine from the GPL perspective. See, for example, this: http://www.gnu.org/licenses/gpl-faq.html#CompanyGPLCostsMoney . So I would conclude that it is certainly open source, even if it isn’t openly distributed.
June 19th, 2008 at 2:33 am
Hi Richard:
Thanks for opening up (heh) this conversation!
When I placed the code under a GPL v2 license, I knew that it would be an unusual situation for as long as the Unicorn / Symphony API is not truly open. If the API does become open, then all the normal terms of the GPL v2 license apply. Until then, other API-qualified Unicorn/Symphony customers will have to consider the restricted sharing of API code a pertinent obligation under article 7 of the license:
“If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all.”
To be fair, at the recent SirsiDynix SuperConference there was reportedly talk from the executives that the Unicorn / Symphony API would be truly opened up. I hope that this talk leads to action, so that reality matches the words (”open APIs”) at http://sirsidynix.com/Solutions/Products/integratedsystems.php. I believe it can only help Unicorn / Symphony customers if extensions to their ILS were able to draw upon the power of the broader development community. Yes, this might mean that other commercial entities could offer products that compete with SirsiDynix’s own offerings - but they would be built on top of Unicorn / Symphony, and that would be a win for SirsiDynix.
As it stands right now, (at least as I understand the terms of usage for the Unicorn / Symphony API), if I were to write a Drupal module that used the Unicorn / Symphony API to pull related items from the ILS, I would only be able to expose the code to a limited pool of fellow Unicorn / Symphony developers through the sirsiapi.org site. I wouldn’t be able to ask the broader community of Drupal developers for a code review, host the code through the normal Drupal module repository, use the normal Drupal bug trackers, etc.
The rationale that was expressed to me for keeping the Unicorn / Symphony API closed a few years ago when I attended the API training course is that someone who didn’t know what they were doing would be able to do a lot of damage to their ILS data. That patronizing attitude grated on me; the same fear could be expressed for almost any software product that exposes an API, yet in many other industries companies encourage the broader development of skills so that an innovative user community can form around the product. Is the library community so different that customers can’t be trusted to know their own limits and need to be protected from themselves?
June 19th, 2008 at 8:05 am
Thanks Roy. I agree, that under the terms of the GPL License Dan can share his work amongst a very narrow group of people to whom he is allowed to show it. Under the circumstances GPL was the right license to use. The Gnu License is about ‘Free Software’ distribution as the GNU site explains about this fredom:
- The freedom to run the program, for any purpose (freedom 0).
- The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor (freedom 2).
- The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
As these freedom definitions recognise, they depend on access to the code, which Dan is restricted from being open with. So I still contend that it is not really open.
Thanks Dan for your clarification – your example of what you could not do if you had produced a Drupal module is very helpful in understanding the problem.
As to the rational behind the policy, it is exactly this sort of thing that has gained our industry the reputation that in my opinion we have been quite rightly criticised for over too many years. Hopefully there is now a momentum of openness starting in our industry, exemplified by the agreements about the DLF’s ILS API, that will sweep this kind of thing away.
June 20th, 2008 at 2:55 am
There is only one question here: is the code GPL-licensed or not? Richard says yes, Dan replies yes, specifically GPLv2, then adds constraints that are incompatible with that license. That indicates no.
“When I placed the code under a GPL v2 license, I knew that it would be an unusual situation for as long as the Unicorn / Symphony API is not truly open. If the API does become open, then all the normal terms of the GPL v2 license apply.”
Again the root question: either the normal terms apply or they don’t. Either Dan placed it under GPLv2, or did not. As far as intent goes, it seems Dan intended to post proprietary code to a proprietary group with the explicit *possibility* of future release under GPLv2. Without dusting off my sirsiapi login to go check what the code itself says, I’ll let Dan speak for himself on intent.
However, Dan’s real or imagined restrictions under a special-purpose agreement with SirsiDynix do not in any way restrict other users of GPL-licensed work. Specifically, authors of GPL code have no means to restrict others’ sharing of any GPL code (including these migration scripts, if GPL-licensed). If Dan could not endure that eventuality, then then any GPL would indeed be the wrong choice for a license.
So if the code was in fact GPL-licensed, regardless of the original intended audience, the only thing missing is for someone (else) to repost and share it in a reliable, accessible way.
The truly funny thing about all this is Unicorn’s own appropriation of GPL code (later acknowledged).
June 22nd, 2008 at 4:51 pm
Joe, I don’t think the situation boils down to just one question (i.e. “There is only one question here: is the code GPL-licensed or not?): licensing is complicated. More importantly, Dan is not the bad guy here. SirsiDynix should be rebuked for their aggressive anti-collaboration business model which puts all of use, Dan included, at a severe disadvantage.