Coffee|Code : Dan Scott

As an academic librarian, software developer, and occasional author, I would like to state my opposition to the proposals contained in the TPP text that would extend the term of copyright in Canada.

Specifically, in Chapter 18: Intellectual Property, Article 18.63: Term of Protection for Copyright and Related Rights proposes a harmonized term of "the life of the author and 70 years after the author’s death" for works, performances, and phonograms. This represents an additional 20 years of copyright for most works.

Should this extension be imposed upon Canadians, the number of works that will be added to the common wealth of the public domain will be reduced dramatically for our current generation of children, and significant harm will be done to the Canadian public's ability to learn from, enjoy, and build upon these works.

With the proposed 70 years of copyright protection after the creator's death, the intended beneficiaries are obviously not the creator's potential children: a term of life + 25 years would be more than sufficient for providing for children well into adulthood, even those who might have been conceived moments before the creator's death. Instead, those who will benefit are the publishers and agents who have acquired the rights to that creator's works.

As an academic librarian, the most egregious examples I see are scholarly articles which faculty have written and then assigned their copyright to publishers, who then charge individuals and institutions alike for the right to access those articles. Our society, which has been attempting to transform itself from a resource-based to a knowledge-based economy, already suffers from these barriers with our existing copyright terms.

If we truly want to encourage increased knowledge, creativity, and innovation in Canada by Canadians, we should be reducing, not extending, terms of copyright. I therefore urge you to withdraw Canada's participation in the effort to harmonize and extend our terms of copyright through the TPP.

Sincerely,
Dan Scott

For libraries, proxying user requests is how we provide authenticated access--and some level of anonymized access--to almost all of our licensed resources. Proxying Google Scholar in the past would direct traffic through a campus IP address, which prompted Scholar to automatically include links to the licensed content that we had told it about. It seemed like a win-win situation: we would drive traffic en masse to Google Scholar, while anonymizing our user's individual queries, and enabling them swift access to our library's licensed content as well as all the open access content that Google knows about.

However, in the past few months things changed. Now when Google Scholar detects proxied access it tries to throw up a Recaptcha test--which would be an okay-ish speed bump, except it uses a key for a domain (google.ca of course) which doesn't match the proxied domain and thus dies with a JS exception, preventing any access. That doesn't help our users at all, and it hurts Google too because those users don't get to search and generate anonymized academic search data for them.

Folks on the EZProxy mailing list have tried a few different recipes to try to evade the Recaptcha but that seems doomed to failure.

If we don't proxy these requests, then every user would need to set their preferred library(via the Library Links setting) to include convenient access to all of our licensed content. But that setting can be hard to find, and relies on cookies, so behaviour can be inconsistent as they move from browser to browser (as happens in universities with computer labs and loaner laptops). And then the whole privacy thing is lost.

On the bright side, I think a link like https://scholar.google.ca/scholar_setprefs?instq=Laurentian+University+Get+full+text&inst=15149000113179683052 makes it a tiny bit easier to help users set their preferred library in the unproxied world. So we can include that in our documentation about Google Scholar and get our users a little closer to off-campus functionality.

But I really wish that Google would either fix their Recaptcha API key domain-based authentication so it could handle proxied requests, or recognize that the proxy is part of the same set of campus IP addresses that we've identified as having access to our licensed resources in Library Links and just turn off the Recaptcha altogether.

Yesterday, just one day before the anniversary of the 1.1.2 release, I published the 1.1.3 release of the PEAR File_MARC library. The only change is the addition of a convenience method for fields called getContents() that simply concatenates all of the subfields together in order, with an optional separator string. Many thanks to Carsten Klee for contributing the code!

You can install File_MARC through the usual channels: PEAR or composer. Have fun!

On Friday, June 10th I gave a short talk at the OLITA Digital Odyssey 2016 conference, which had a theme this year of privacy and security. My talk addressed the evolution of our public and loaner laptops over the past decade, from bare Windows XP, to Linux, Windows XP with the addition of Deep Freeze, to the decision two years ago to move to Chromebooks.

Given that Snowden made it clear that multinationals such as Google, Apple, and Facebook co-operate with government agencies to make user data available, we did not make the decision to adopt a product that emphasizes cloud storage and thus potentially compromises the privacy of our users lightly. Rather, we made that decision in the context of a resource-constrained institution that had already adopted Google Apps for Education for its student population--and with a reflection on the vulnerabilities to which our particular implementation of Windows 7 + Deep Freeze was exposing our users.

I've made the presentation, with the speaker notes surfaced as callouts, available, and embedded it below. I'd love to hear your thoughts.