— Art Museum Directors (@MuseumDirectors) July 11, 2014
Much talk, recently, has occured surrounding licensing museum data using a Creative Commons Zero license (CC0). Said license is characterized almost as an anti-license, This license type is popular for its apparent lack of restriction and “simplicity”. The Creative Commons folks describe it as:
Using CC0, you can waive all copyrights and related or neighboring rights that you have over your work, such as your moral rights (to the extent waivable), your publicity or privacy rights, rights you have protecting against unfair competition, and database rights and rights protecting the extraction, dissemination and reuse of data.
Keep in mind that you cannot waive rights to a work that you do not own unless you have permission from the owner. To avoid infringing third party rights, you should consult with your legal advisor if you are unsure whether you have all the rights you need to distribute the work.
Please note that this is not a registration process and Creative Commons does not store or save any of the information you enter. This tool guides you through the process of generating HTML with embedded metadata for marking your work as being available under CC0. Your work will not be associated with CC0 or made available under CC0 until you publish it marked as being so.
This is fine and good in many instances, particularly when posting code snippets online.. if you really are posting it to share it with others, what better way to enable easy and hassle-free use?
CC0 is deceptive. On the surface, it appears to be maximally permissive: anyone can use it for anything at any time for any reason. Sounds awesome! I like Freedom! Let Freedom Ring! We’re museums, organizations that are notorious for
not having resources necessary to serve every audience overstepping copyright boundaries and being big jerks to everyone, particularly an audience of folks who are clamoring for museum data sets and permissively licensed images.
(It should be noted that the estimated number of people clamoring for Museum data has been estimated just north of 12 people this year, an all-time high!)
So, wait, why is CC0 bad? Oh yeah. CC0 is maximally permissive from the perspective of the end-user. For folks that want to use data, this is the best choice, because no one can restrict it, and they are under no obligation to do anything beyond providing the data. The problem comes with respect to the perspective of the data itself.
With Share-Alike licensed data and data-sets, the number of restrictions placed on the data sets are minimally and maximally 1 restriction. The only restriction is that it cannot be restricted. With CC0, there is no obligation to keep data unrestricted, so from first modification onwards, there exists a potential restriction. As one moves across the generations of the data set in the wild, the Share-Alike data set stays at 1 restriction, while the CC0 licensed work succumbs to a wide variety of potential restrictions, rapidly approaching an unmanageable level after only a few short generations.
If museums are truly committing to Open, we need to commit to it in a big way. We need to commit to Open as the principle and contract by which we share our data, particularly because it best benefits our users over the long-term, but also because it benefits our collection. Last I checked, benefitting the collection was also a top priority. It’s our responsibilities to make the best technology choices to support the institution, and I’m loathe to find a scenario where CC0 ends up being a safer, better, more rewarding decision than a simple share-alike license. A SA clause clearly indicates that the spirit of openness with museum content is expected to be maintained through others uses, regardless if they be commercial, educational, personal or whatever.
There will surely be partners (cough, Google) who will balk at the thought of using Share-Alike licensed data. Or there are scenarios where by a share-alike prohibits a specific bit of progress you’re keen to see. When encountering these scenarios, as a rights holder you maintain the right to separately license certain bits of data to certain entities with different rules. Perhaps the value proposition of something like the Google Art Project is too great to ignore. There are still ways of selectively making those deals work while still communicating your obvious intent with respect to collection data and digital surrogates.
So, does easy, hassle-free use trump other factors with Museum data? I would argue: absolutely not. We have a responsibility to our institutions to make the right decisions for them, and that decision is to include and require a share-alike clause in conjunction with providing open data. It is our obligation to make the correct long term decision for the items comprising our collection. Considering the undeniable benefits to object care afforded by cataloging and data, making a strong effort to ensure that data is always as great as it could get. Is it harder to conceptualize? Maybe. Does it have a big enforcement footprint? Not really, you don’t even have to enforce it, as it isn’t a trademark, and therefore requires no enforcement to affect its legal status.
I’m very curious (and frankly, suspicious) of museum professionals that deem Share-Alike licenses to be harmful.. in what scenarios? Are there even any?
Oh, and use this instead: http://opendatacommons.org/licenses/odbl/
Mia Ridge, as she always does, makes a ton of sense out of a few of the major problems museum tech-folks face today in her post Confluence on digital channels; technologists and organisational change? As I’m putting the finishing touches on my proposals for Museums and the Web 2013, I find there’s quite a bit of overlap between the topics I’m interested in writing about and what Mia has written about here. I won’t (yet) comment on the larger themes of the essay, however, I do have a different perspective (coming from the IT side of the house), which I feel differs slightly from Mia’s perspective.
In her post, Mia writes:
In museums there’s often a perception that digital teams are a service department (perhaps because of their roots in IT departments) while digital teams see themselves as creative departments, commissioning content and design, producing innovative experiences and consulting within the museum on digital projects.
Pointing out the tension between the creative side of the house and the IT-rooted technical side of the house is fantastic – this tension is often the 800 pound gorilla in the room. I think the reality of functioning in a modern organization of any variety, particularly museums, is that there are few (if any) departments who truly have final, absolute say in content and delivery, and for good reason. If there are any departments like that in your organization, they better be curatorial (put down your pitchforks, open authority folks ;)).
Tech folks can generally all agree, though, that content folks and other stakeholders have traditionally been, and are still today, too close to website implementation; the contract between web teams and stakeholders is too low-level. As it stands, most work orders sound something like this:
Stakeholder: On the About The Museum Page, we need to bulk up the section on our trustees. Add a new page under the about menu with a grid of headshots and then the names, and after the names put what committee they are on.
Whereas ideally, the contract would be higher up, and focused more on goals, not on tasks, like so:
Stakeholder: One of the trustees was unhappy about the amount of coverage the board gets on the about page. We would like there to be more information about the trustees on the about section, particularly their names, faces, and committees. What can be done about that, and how can we show this trustee that the page is doing an appropriate job in educating visitors about the board?
Bingo. This is what we want. We get to use our formidable expertise in Problem Solving, SEO, Information Architecture, Page Design, etc. Stakeholder gets an awesome solution, backed by metrics that directly measure the results. If it underperforms, we can start split testing different versions until we start getting to one that meets all the requirements.
It seems a surprising percentage of web folks actually believe in their heart of hearts that stakeholders come with strong ideas for implementation to spite them.
Mostly, I reckon it’s because page design is fun. Many people that make requests for creative development don’t get to do very much of it, and the website in almost every institution was a wild west (where this level of buy-in was encouraged!). As such, it’s very difficult to move that boundary back from task-centric to goal-centric, and to basically tell people to not bother you with their ideas.. it’s a difficult situation for technologists because, well, most of us are better at talking to computers than people.
IT departments generally solve it with process: change requests processes, procedural review of requests by an information architect, and all the hoops and trappings of IT-dom. This technique can be effective, but result in poor customer satisfaction, and it invites stakeholders to be just interested enough to cover the basics, not interested enough in building the best solution. Who likes dealing with tech-reaucracy?
The same demoralizing effect can be felt through mandate by executive order. This can also lead to rebellion: marketing trying to out-source micro sites or other small web things, development angling to get their ‘own’ website, etc. Particularly in small institutions, these types of behaviors can quickly fracture a cohesive web strategy, and it seems to occur all too often utilizing the mandate approach.
The secret, as it turns out, is held by graphic designers (go figure).
A lot of client conflicts arise from a lack of knowledge. Sometimes the client just doesn’t understand what we do as creative professionals, and this accounts for many of their crazy requests. Our job as designers is to help them with their particular goals. They always have a target in sight; they just don’t know how to hit it. Communication is all-important. You have to understand what the client wants, and the client has to know what you need to do to make it happen.
Every client is different, and each has to be handled a different way. You’ll have to be attentive to some; others will require a standoff-ish approach. The important thing is finding a way to draw clear lines of communication, so that both parties know exactly what they’re getting out of the business transaction. Hopefully, the client will educate you as much as you do them.
Wait, what? Every client is different? There’s not a magic solution? The good news is, as a department, we will deal with the same [2,6,10,20,40] stakeholders time and time again. That makes it at least a little bit easier. The ideal solution should leverage stakeholder’s enthusiasm, and utilize our privileged position as web experts to educate, explain and collaborate.
To enable handling a wide-variety of customers, web teams need customer service staff. In some institutions this staff can be project management staff, or a central coordinator in smaller institutions. Some customers will want to be present for the web design process, or at least for regular status updates, some will be content with giving you goals and expecting great delivery.
- Provide clear guidance through a series of steps intended to reach an agreed-upon end result.
- Always follow this pattern: allow for divergence of opinion, permit participants to explore those opinions within constraints, and then force ideas to converge.
- Provide a real-time representation of what’s going on during the meeting where people can see it.
- Keep in mind that everyone in the room, no matter what they say, believes that their recommended action equates to doing the right thing.