This issue has been covered in different degrees in various places around the net. One of the most cogent observers has been Jonathan Bailey, in his articles ‘Is Flickr Letting Down its Users?’ and ‘Why Flickr Licensing Fails’.
The basic problem is this: some third-party websites and applications have been using the Flickr API or feeds to publish photographer’s images in ways those photographers did not intend or allow. Photographers familiar with the relatively clear licensing interface of the Flickr.com website have been surprised to learn there is a ‘back door’ into their carefully-licensed images.
Some photographers reacted by stating that they did not intend their photo to appear in any form other than the original: in the HTML pages of the Flickr.com website. A few feel their only choice is to quit Flickr, or even quit the public Internet, moving their images to private domains they believe to be safer for their property. These drastic, reactionary moves are unfortunate, but understandable. The technical situation is complex and facts are few.
As a photographer, developer, and Flickr user, I decided to investigate the problem from a technical point of view. (Jonathan Bailey and others have already put forth good arguments for more ‘soft’ improvements in Flickr’s licensing model.)
I have worked with the Flickr API and syndication feeds for several years, and am familiar with Flickr’s architecture, as well as their technical documentation. (I do not work for Flickr, or have any other sort of professional affliation with them.) By reading the API documentation, testing the API using simple programs, and examining the syndication feeds’ data, I was able to determine the actual licensing information provided by the Flickr service, as well as the extent, if any, of Flickr’s enforcement methods or policy.
What I found was that the problems are serious, but not fatal. By making a few technical changes and by improving their documentation, Flickr could mitigate the worst of the problems.
I realize that many people interested in this problem may not be familiar with the technology behind APIs and feeds. I’ll do my best to explain how the system currently works, hopefully in a way that explains the necessary details, but is still understandable to nonprogrammers.
Flickr is a platform
Flickr isn’t really a website. Most people use the website to upload and browse images, but the website can be thought of as separate program which interacts with the core Flickr platform. The platform contains all the images and their metadata — tags, descriptions, license type, camera-generated EXIF data — stored in a large distributed database and managed by several servers.
Besides the website itself, many other programs interact with the Flickr platform: Aperture and Lightroom plugins, screensavers that display Flickr images, desktop uploaders, iPhone browsers, etc. The syndication feeds can be seen as just another program that interacts with the platform, although one that’s linked more tightly with the website.
All of these programs interact with the Flickr platform using Flickr’s application programming interface (API). You can think of the API a bit like searching on Google: You type in a query (a request), and you get back a list of results (a response). However, the API isn’t intended for use by humans, but rather by computer programs. It is the utilitarian face of the Flickr platform, a special-purpose website that is designed to take requests from programs, and give back responses that the programs can use.
(I’m not certain that Flickr’s own website and feeds use their API. However, I’ve heard rumors of this, and in my experience in designing systems that had APIs, it’s a good design and so a reasonable assumption.)
For example, on the Flickr website, every user has a photostream — a list of the most recently uploaded photos by that user. In the API, the photostream can be accessed by requesting a resource called flickr.photos.getRecent. Doing that has same result as looking at the photostream on the website, but the photostream is intended for a human and the other for a computer program. That flickr.photos.getRecent name is called a method; a programmer uses particular methods to do particular things in the API. As you can see, the name of the method is indicative of what the method does.
Flickr’s API has dozens of methods, each one doing something different with the Flickr platform. The API is extensive: pretty much anything you can do on the Flickr website, you can do using the API. The methods are clearly documented (at least compared to many APIs I’ve worked with; if you’re interested, check out the full list of the methods supported by the Flickr API.)
When a person interacts with the Flickr website, they get back HTML pages that look good in your web browser; when a program interacts with the API, it gets back a carefully coded outline of the information being asked for. (Technically, the API returns XML or JSON.) Unlike the HTML page, the API responses are designed to be examined and interpreted by the program doing the request.
A subtle but important fact to know is that the Flickr API itself does not return the actual image data — that is, the JPEG file uploaded by the photographer. The API (as well as the syndication feeds) is really just a way of searching and accessing (and sometimes modifying) the metadata that Flickr stores about each image. Image metadata includes items like its title or description, as well as links to the image data. But once a program knows those image data links, it accesses the images outside the API, in the same way a regular web browser can (by URL, usually specified in a
img HTML element).
I point this out because I think it’s important to understand that all Flickr images are available as individual web resources, accessible to anyone, independent of the API. While some photographers argue whether this should be the case, it’s part of the reality of the current technology of the web. Once someone knows the link to an image stored on Flickr, it’s just as accessible (and copyable) as any other image on the web.
When a program requests a Flickr image’s metadata, that program may display some of the metadata directly to the user — like the title or description. It may use the metadata to determine how to display an image — like using the size of the image to leave enough space for it in a window. It may use the metadata to determine whether to display the image — like the license.
And here we arrive at the gist of the problem.
Flickr has a reasonable set of available licenses, and requires that every photograph on their system have a license. The current licenses (as obtained by the flickr.photos.licenses.getInfo API method) are:
|0||All Rights Reserved|
(The ‘code’ is important, but I’ll talk about it later.)
Flickr does a good thing here, and defaults to ‘All rights reserved’ (code 0); a photographer is free to change this, either on a particular image or for all new uploads.
‘All rights reserved’ is such a common part of today’s fine print that most of us gloss over the phrase. But to a working photographer, this means something specific: rights to this image have been granted for use in a particular instance, in a particular medium, sometimes in a particular location; any other uses have to be requested (and negotiated) separately and explicitly.
But who looks at the license?
The Flickr website does a reasonable job at describing photographers’ licensing terms. It’s right there on every image page, under ‘Additional information’; most images say ‘All rights reserved.’ If you’re the owner of the image, you’ll see an ‘edit’ link, where you can select the license you desire. Although Flickr doesn’t explicitly enforce the license, they arguably make the information clear enough that only the most blatant image thief would assume the image was freely available.
However, the license data returned by the syndication feeds and the API aren’t as obvious.
Looking through the API documentation, I found around a dozen different methods that obtain information about a photo; these API methods relate to various Flickr features like sets, pools, geo-tagging, favorites, and so on.
The Flickr API documentation is quite good at describing the parameters needed to make a request to an API method. However, it’s quite bad at describing the parts of the response being returned. Flickr basically leaves it to an example, showing the XML output of an arbitrary request to the method.
For example, flickr.photos.getInfo is one of the main methods in the Flickr API, and returns all the metadata for a given image, as well as information on how to retrieve the actual image data. Here is an excerpt from the response example in the method’s documentation:
<photo id="2733" secret="123456" server="12" isfavorite="0" license="3" rotation="90" originalsecret="1bc09ce34a" originalformat="png">
See the license? No? Look again. Second line, second attribute. It’s the part that says
license="3". If we look up ‘3’ in the table of license terms earlier in this post, we get ‘Attribution-NonCommercial-NoDerivs License.’
I could find no documentation that suggested how the license code should be interpreted. Nothing I found even said to use the flickr.photos.licenses.getInfo method to look up more information about the license code. Most likely, programmers who familiarized themselves with the API would eventually find the method to look up the license information. But the fact that there is no guidance in the documentation is worrying.
Further, it appears that flickr.photos.getInfo is the only method that returns the license code by default. Here are the other methods that return information about specific Flickr images:
None of these methods return the license information by default. A programmer must ask for the image’s license explicitly (by setting the
extras parameter to include the keyword ‘license’); once this is done, the methods will return the license code just like the flickr.photos.getInfo method does by default. There is no explicit documentation about this parameter, either — a programmer must infer that requesting this ‘extra’ will actually return the license code in the same way that flickr.photos.getInfo does.
The API itself does no actual enforcement. If I write a program that uses the API to show images, there’s nothing stopping me from pulling over any image that might be licensed ‘All rights reserved.’ That license’s code (0) will be returned — if I remember to set the optional parameter in the request. It’s up to me as a programmer to inspect the license status and determine whether it’s one that allows for republication.
While the various licenses are described on your Flickr account’s Set a default license page, the only place where the license code is described is in the response from the flickr.photos.licenses.getInfo API method. And that response only lists the code, the license name, and the website where the license terms themselves can be obtained.
It’s unclear how and how often Flickr might change those licenses, so to play it safe, a developer might decide to call the flickr.photos.licenses.getInfo method every time a group of photos is fetched, or at least each time the application connects to the Flickr platform.
So we have ourselves here a situation:
- The API itself does not enforce the licensing specified by the owner.
- The API does not return licensing information unless explicitly requested (except for one method).
- The license information returned for an image is coded as an arbitrary number, whose meaning may change over time.
- The license code must be looked up using a second API method to determine the actual license.
- The license information is not sufficient to determine whether a given use is allowed.
Do all programs use the API?
Although the Flickr API is well-designed, it’s still complicated. Because the API works over the network, it depends on an infrastructure and knowledge that many desktop or web programmers lack.
In response to this, modules of code have been developed to act as ‘middleware’ between the actual Flickr API and the application. Programmers call these ‘libraries’ or ‘frameworks’; Flickr calls them ‘API kits.’ These kits (most of which have been developed by independent developers, not Flickr) are available in all major programming languages and systems, and many applications do use them instead of programming directly to the Flickr API. Flickr publishes a list of most of the API kits available on their Flickr Service page.
Because the Flickr API is considered to be conceptually well designed, most API kits simply mirror the native API calls, adapting to the peculiarities of a language or operating system where necessary. So most programmers end up consulting the Flickr API documentation anyway, even when they aren’t directly using the API. Some API kits provide a simpler view of the Flickr API by abstracting or generalizing the methods.
Any third-party application, whether it uses the Flickr API natively or one of these API kits, has to apply to obtain a ‘key’ that allows access to the API; this key is included in every request for an API method. As part of the application process, Flickr requires an email address. Flickr therefore knows in theory who to contact about the usage of any particular application that uses the API, either directly or indirectly.
The problem raised by API kits is that another level of (mis)understanding and (mis)interpretation has been invented. If Flickr itself has not provided sufficient tools or documentation to interpret the license of a particular image, the developer of an API kit can hardly be expected do better. And that developer could do worse, if a poorly designed API kit obscured or removed the licensing information.
What about the feeds?
Flickr offers several different kinds of syndication feeds. They’re quite useful; I monitor many photographers’ photos using these feeds, and then browse their newest images in my news reader.
While Flickr publishes in all the major feed formats — Atom, RSS, RSS2, and RDF — the only one that contains any licensing information at all is Atom. And it is only this sad, broken line found in each image’s feed entry:
< link rel="license" type="text/html" href="deed.en"/ >
While this is a valid Atom idiom (see Specifying a License at the Creative Commons’ wiki pages), it’s not specified correctly: the ‘deed.en’ link should either point to a full address (perhaps http://creativecommons.org/licenses/by/2.0/deed.en_US), or be a valid path relative the feed’s base address. It’s neither of those, which make the license information completely invalid. Not to mention that it’s even more difficult than in the API example to determine what rights granted actually are.
So, effectively, Flickr is offering no licensing information with their syndication feeds.
Why are they doing this?
The choice of Flickr’s founders to open up so much of the platform in a relatively public way has made the Flickr community stronger and far more interesting than a more static, centrally-designed website. However, their decision to treat licensing terms as just more (optional) metadata shows a disconnect between data accessibility and respect for property.
I don’t believe Flickr is being malicious. I think they care about copyright; their support of the Creative Commons licenses was groundbreaking, and they do make it relatively easy for their users to select a license. And the fact that they default to an ‘All rights reserved’ license says a great deal about their attitude.
Comply with any requirements or restrictions imposed on usage of the photos by their respective owners. Remember, Flickr doesn’t own the images — Flickr users do. Although the Flickr APIs can be used to provide you with access to Flickr user photos, neither Flickr’s provision of the Flickr APIs to you nor your use of the Flickr APIs override the photo owners’ requirements and restrictions, which may include “all rights reserved” notices (attached to each photo by default when uploaded to Flickr), Creative Commons licenses or other terms and conditions that may be agreed upon between you and the owners. In ALL cases, you are solely responsible for making use of Flickr photos in compliance with the photo owners’ requirements or restrictions. If you use Flickr photos for a commercial purpose, the photos must be marked with a Creative Commons license that allows for such use, unless otherwise agreed upon between you and the owner. You can read more about this here: http://www.creativecommons.org or http://www.flickr.com/creativecommons.
But this legalese, however well it’s written, coupled with the associated lack of technical advice about applying the license on a given image, leads to the situation like Arthur Dent faced in The Hitchhiker’s Guide to the Universe: licensing terms for images are ‘on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “Beware of the Leopard.” ’
Most programmers I know develop software by experience, not by specification. We play, experiment, poke at a system and see what comes back. If a piece of that data looks interesting, we’ll look at it closer. If it seems unimportant or optional, we may never examine it closely.
To tell you the truth, I never noticed that
license="3" sitting there in the response, either. But I would have noticed if Flickr’s documentation had a big box saying: ‘You must always examine the license value, and only transfer or display the image if you can comply with its assigned license.’
By making the request for licensing terms optional, or at best obscure, Flickr is effectively saying that following the terms is also optional.
How Flickr could improve the situation
Flickr could rectify this situation, and reduce the confusion and misinformed reaction, by making a few simple technical changes to its API, and minimally reaching out to its community of photographers, viewers, and developers.
Return licensing status by default in the API, and include additional attributes for license name and link, avoiding a second method call.
Document and emphasize this change in the documentation.
Publicize this change to developers of API kits, as well as developers of applications that use Flickr APIs.
Correct the broken syndication feeds and include licensing information and links wherever possible.
Clarify the permissions settings page so photographers understand the rights they are granting or releasing.
Flickr may understandably want to avoid this. After all, their default license is ‘All rights reserved.’ If most of their users (whether naive or advanced) keep that license, and they advocate for third-party applications only fetching Creative Commons-licensed images, the result may be little of Flickr’s content being legally available to the applications. This would diminish Flickr’s goal of ‘Share your photos. / Watch the world.’
Some have posited that Flickr’s passivity about enforcement comes from an attitude of being a something like a common carrier: Flickr may feel they would be liable if they actually examined and judged the usage of Flickr content in terms of copyright and license. However, by making licensing status obscure and unobvious, Flickr is certainly not helping, and arguably could be accused of contributing to copyright violations through negligence.
Flickr has an opportunity here to educate its community about the benefits of copyright. Like its pioneering effort in offering the Creative Commons licensing model, Flickr could make copyright understandable to photographers, viewers, and developers of applications that use those APIs.