It seemed so long ago – last week at this time, LDH was logging back into the online world only to find yelling. Lots of yelling. Why were so many people yelling in our timeline? What did someone in the library world do this time to set people off?

It turns out that the source of the outrage wasn’t located in the library world but instead in the open source community. Users of the popular audio editor Audacity loudly objected to the recently updated privacy policy, claiming that the new language in the policy violates the existing license of the software and turns Audacity into spyware. Even after clarification about the new language from Audacity, several users took the current Audacity code to start their own Audacity-like software projects that wouldn’t be subject to the new policy language. This created its own issues – one project maintainer was attacked after a targeted harassment campaign after they objected to the offensive name of another project.

The Audacity debacle continues; nevertheless, are a couple of lessons that libraries can take away from this mess.

Privacy Notices and Your Patrons

We will start at the privacy notice. In the privacy world, a privacy notice differs from a privacy policy. The latter is an internal document, and the former being a document published to the public. In part, a privacy notice informs the public about your privacy policies/practices and what rights the public has regarding their privacy. The language changes to the privacy notice carry several possible points of failure, which we encountered with the Audacity example. A comment thread in the language clarification post identifies some of the significant issues with how Audacity went about the changes:

“I think what a lot of people are also taking issue with… is that these major, scary-sounding changes are popping up seemingly out of nowhere without any sense of community consultation. Right now, I think people feel caught off-guard yet again and are frustrated that the maintainers aren’t demonstrating that they care about what the broader community thinks of their decisions.”

What can libraries take away from this?

• Write for your audience – Privacy notices are notoriously riddled with legal language that many in the general public are not equipped to navigate or interpret. Your privacy notice can’t skip the vetting process by your legal staff, but you can avoid confusion by using language that is appropriate for your audience. This includes limiting library and legal jargon or creating summaries or explanations for specific points in the notice to understand more detailed or longer sections of the notice. Twitter’s use of summaries and lists in their privacy notice is one example of writing to the audience. In addition, don’t forget to write the notice in the major languages of your audience. Everyone in your community deserves to know what’s going on with their privacy at the library.
• Involve your audience – The earlier quote from an Audacity community member demonstrates what can happen when key stakeholders are left out of critical decision-making processes. How is your library working with patrons in the creation and review of the privacy notice? Asking patrons to review notices is one way to involve patrons, but involving patrons throughout the entire process of creating and reviewing a privacy notice can reveal hidden or overlooked privacy issues and considerations at the library.
• Communicate to your audience – What do you do when you publish a change in the privacy notice? Your patrons should not be caught off guard with a significant change to the notice. Luckily, your library already has many of the tools needed to tell your patrons about important updates, from your library’s news blog or newsletter to in-library physical signage and flyers. Website alerts are also an option if used judiciously and designed well – a website popup, while tempting, can be easily clicked away without reading the popup text.

Open Source Software and Privacy Expectations

We’ll go ahead and get this out of the way – open source software is not inherently more private and secure than its proprietary counterparts. OSS can be private and secure, but not all OSS is designed with high privacy and security standards by default. One of the primary reasons why so many in the Audacity community were upset with the changes is their assumption that OSS would not engage in data collection and tracking. However, several other popular OSS projects engage in collecting some level of user data, such as collecting data for crash reporting. Having other major OSS players collect user data doesn’t automatically make this practice okay. Instead, the practice reminds those who make software decisions for their libraries that OSS projects should be subject to the same rigorous data privacy and security review as proprietary products.

A strength of OSS is the increased level of control users have over the data in the software – libraries who have the in-house skills and knowledge can modify OSS to increase the level of privacy and security of patron data in those systems. The library OSS community can provide privacy-preserving options for libraries. Other libraries have already shared their experiences adopting privacy-preserving OSS at the library, such as Matomo Analytics and Tor. Ultimately, libraries who want to protect patron privacy must choose any software that might touch patron data with care and with the same level of scrutiny regardless of software licensing status.