GPO’s report (GPO LOCKSS Pilot: Final Analysis, Government Printing Office, April 12, 2007), which analyzes the LOCKSS technology and announces GPO’s findings and “future recommendations” on using LOCKSS, refers repeatedly to use of IP Authentication*. The document does not, however, discuss the need for IP authentication either in the pilot or in possible future implementations of LOCKSS for government information.
Since LOCKSS does not require IP Authentication, this raises interesting questions.
While it is reasonable to assume that GPO wanted to limit access to the documents it was using for the LOCKSS pilot project to those who were participating in the project, it is not clear why GPO would consider IP Authentication necessary for a live implementation of LOCKSS. But the report clearly states as an “Outstanding Issue”:
IP authentication for over 1260 depositories would be cumbersome, and may not be cost effective in relation to the benefit received. (page 6)
And, later, the report stresses the costs of IP Authentication:
LOCKSS technology in itself appears to be relatively cost efficient as a distribution mechanism. Costs appear to be a bigger issue in relation to staff time required to … administer IP authentication. (page 11)
Since the report does not explain why it would want to use IP Authentication for LOCKSS, we can only speculate why it includes it as a cost. Here are my speculations. I pose them as questions and would welcome answers from GPO.
- Is GPO planning to set up a special distribution system for depository libraries only?
This would make sense if GPO wants to use this special distribution channel to meet its commitment to “free and ready public access to” government information “in partnership with Federal Depository libraries” while maintaining a separate, fee-based channel to meet its commitment to “distribute, on a cost recovery basis, copies of printed and electronic documents and other government information products to the general public,” [emphasis added] (A strategic vision for the 21st century).
For this to work, GPO would have to restrict what FDLP libraries can do with the content they receive, either through technological locks or limitations, or licensing restrictions. We have already seen a precursor to the use of licensing restricitions with the Library of Congress Subject Headings (See: GPO details onerous restrictions on digital materials).
This seems to me the most likely reason for the inclusion of IP authentication in the report because it fits in well with the contradictory missions noted above of providing information for free and for a fee and with GPO’s previous experience with this very contradiction. (Years ago, when GPO tried to charge for GPO Access, it tried to limit free use of it to those physically inside depository libraries. When that failed because libraries made the same content available on the net, GPO was forced to go to a model of making “it free to the general public.” But, as Bruce James said, “This cannot continue.” [See Summary, 2003 Fall Meeting Depository Library Council.])
The new model seems clear: “Free” to depository libraries, but with limitations on use, location, and so forth; and “Fee” to the general public.
- Is GPO planning a separate, FDLP-only distribution channel as a way of providing “authentication” of content?
This would fit in well with GPO’s consistently stated intention of being a “single authoritative resource” for digital Federal documents (A Strategic Vision).
Information distributed through such a limited access channel could come with a special cachet of “being deposited” and FDLP libraries and no one else would be able to claim a special authenticity to such distribution. I do not think that it would be either necessary or wise to limit “authenticity” in this way, but, perhaps someone at GPO is thinking along those lines?
- Did those who wrote the report fail to consult policy makers within GPO and make a faulty assumption that GPO wants IP Authentication?
This would indicate either that the report is incomplete or badly done.
- Did those who wrote the report fail to understand the technology they were describing and think IP Authentication was necessary to implement LOCKSS?
This would also indicate that the report, and perhaps the entire evaluation process, was flawed badly.
- Is IP Authentication just a red-herring intended to confuse the issue, raise the theoretical costs of implementation, and provide evidence for GPO’s conclusion that LOCKSS won’t work for GPO?
This would indicate that GPO, which in its own words only took on the pilot project after receiving “requests from research institutions, universities, depository libraries, and other Federal Government agencies to investigate using LOCKSS”, never considered LOCKSS as a viable alternative. Indeed the report makes this fairly clear when it says that it “agreed” to the pilot project to test the LOCKSS technology “…as a potential precursor to GPOâ€™s Future Digital System (FDsys).” [emphasis added]
None of these speculations are encouraging. They lead me to conclusions that do not augur well for free public access to public information. Again, I would welcome a response from GPO.
* In a library environment, “IP Authentication” normally refers to a process that allows access to licensed content. For example, the library subscribes to a journal collection or database and pays the vendor fees that allow certain computers (e.g. all those on a campus) to have access to that content. The library sends the addresses of those computers (“IP addresses”) to the publisher. The publisher maintains a service that allows any request from one of those machines to get content. For more information, see Offering remote access to restricted resources by Marshall Breeding, Information Today, Volume 18 Number 18 (May 2001) p52-53.
Depository libraries can use IP Authentication to allow two and only two machines to have access to STAT-USA. (See “STAT-USA Offers Depositories IP Authentication Access” in Administrative Notes Newsletter of the Federal Depository Library Program Vol. 27, no. 03-04 GP 3.16/3-2:27/03-04 March 15/April 15, 2006.)