:balance_scale: Licenses, UX iteration 4, English

Video:

Prototype:

Hi Filip, Thanks for sharing the updated prototype. It seems like your conversation with Chalmers fits in with the earlier documentation and needs originally put forth by the RM SIG. As a reminder, we shared some documentation in the Google drive folder on licensing. The documentation in there shares how we had originally conceived of license linking within the former Kuali OLE software and how NC State shows relationships of licenses to other ERM entities. @Kristen_Wilson supplied the NC State example.

One thing to consider is how active a license is. For a variety of resources, library will want to keep historical licenses, have an active current license, and may even have a license that is not yet active, but has a start date. So from a workflow perspective, it will be important to know the status of a license and make sure that the governing terms to be displayed to users come from the active license. Suggested statuses could be:

• Historical
• Current (Controlling)
• Future

Last week, on April 18, the ERM subgroup had an interesting meeting where @ostephens put forth the concept of an “agreement” as being at the heart of E-Resource Management. The “agreement” is not simply a legal Agreement (license) but encompasses the content, business terms, legal terms, and time period for which and library and vendor agree upon access. It is an interesting idea and could provide a lot of flexibility from a management perspective. I’m not entirely clear how the License app would relate to the “agreement” but want to make sure we consider these in tandem as we move forward. Chalmers is on the ERM subgroup, but I think may have missed this meeting.

Thank you for your comments, Kristin! @kmarti

I think those are very good points. The people who work on the details of these apps should make sure the vision is coherent across the concepts of Platforms, Licenses, Agreements, etc. At this point in time, I am not sure who will be designing the details of this, and building it. I encourage that Chalmers, the ERM subgroup and the RM SIG all stay in close contact to make sure the concepts move in the same direction.

The material I have shared above is mainly useful as an illustration of the specific needs of Chalmers, as it might manifest in the framework of FOLIO at this point in time.

Something semi-related, that maybe should be (or is already) considered as a “helper app” across FOLIO: being able to store/link documents to records. This came up in the Acq small group last week, and seems it would be relevant to licenses as well, if you want to keep track of iterations or the exact document before distilling into the specific terms. Some examples that we brainstormed in the Acq small group - not at all an exhaustive list:

• Auburn fills out a disclosure statement for any $5K+ transactions – might need to attach/link that document to individual license agreements, invoices, and/or transactions
• License agreements
• Vendor contracts, SOWs, SLAs
• PDFs of individual invoices. Colorado-Boulder scans & stores every invoice
• Customs forms
• Special collections donor agreements
• Vendor tax certificates

Note that this would raise a number of permissions questions, even for view-only, particularly if documents included financial terms or any confidential info.

Related to my comment on the most recent UX iteration for Platforms, I think we should make sure that we know what we’re talking about when we say “Vendor”. For example, on a license agreement, it makes more sense to talk about a “Licensor”, which might be the organization that publishes the licensed content, but it could also be an organization that hosts and sells the licensed materials for a third party, or perhaps something else. Some organizations may have just one role in relation to a library (e.g. a publisher that does not sell or host its own content but does so only through a third party), but they could also have many of them (e.g. EBSCO is a publisher, a vendor, an agent, a platform provider, and a licensor).

On another note, it might be useful to have additional metadata options for attached documents. A single agreement may have dozens of amendments which cover different products and different time periods (with the core agreement remaining the same), so it would be helpful to have additional information that could be associated with the documents to identify which are which and whether they have any terms that differ from the original, main agreement.

Hi Virginia,

I completely agree about the need to be able to distinguish different types of organizations: vendor (for the $$ relationship, unless folks can think of a better word), licensor, access provider, publisher. One example might be Oxford eBooks, where a library might have the vendor as GOBI Library Solutions, the licensor and access provider is Oxford, and the publisher may be Oxford or may be a number of other UPs that Oxford hosts on their platform. And within a single access provider, there may be multiple actual platforms that need to be distinguished - for example, perhaps separate platforms/interfaces for eBooks vs eJournals vs databases. Patrons don’t necessarily need to understand all these details and interrelationships as long as they can click a link and get to what they need, but these details seem critical for ERM and Acquisitions staff.

@kmarti,
I agree that the “activeness” part of a license is very important. Keeping track of historical data is one of the major responsibilities of the (E)RM in my opinion.

I think the license app makes very much sense in the context of the Agreement. I think the agreement should connect both resource(s) and License, and perhaps be the hub that connects the two together.