The license issue with embeddable content

A debate has recently been going on in the swedish blogosphere regarding one of the newspapers in southern Sweden’s decision to embed a Flickr slideshow of the latest photos from Haiti in one of their articles. The slideshow included all kinds of images – both creative commons licensed and others – which some people in the blogosphere reacted negatively upon.

It’s an interesting issue. Flickr’s terms and guidelines clearly states that such a use isn’t permitted – especially not for a commercial newspaper. Flickr however fails to clearly communicate that limitation in connection to their copy and pasteable embed code giving people the impression that Flickr has secured the necessary rights to allow such an embed – which it in contrast to eg. YouTube and Twitter hasn’t.

Flickr’s default license is for everything to be “All rights reserved” – but what that means isn’t clearly communicated. In their terms they only secure the rights to use images on other public Yahoo sites. That a Creative Commons license allows more than that is described by linking the license to a Creative Commons deed – but the “All rights reserved” has no description at all. Big sites like Flickr shouldn’t force people to read long terms to understand what they’re allowed to do – Flickr should describe that up front and especially so when they’re implying that it’s allowed by showing embed codes.

Figuring out how content can be used becomes even harder with new technical standards where the websites themselves handles the content instead of you. One example is the OEmbed standard which allows for easy embedding of content, which WordPress 2.9 support and which I have created a Drupal module for, doesn’t contain any way of identifying the license of embeddable content – still both sites like Flickr and YouTube supports it. I’m always allowed to embed a YouTube video – but I have no way to determine whether I’m allowed to embed the Flickr image or not, which makes automatic embeds upon discovery very tricky from a legal perspective.

Creative Commons and the Microformats community has both done a good work of creating standards and API:s for websites to be able to identify the license of content themselves – but I think the adoption of it has been somewhat limited among content creators.

I’ve suggested on the OEmbed mailing list that a license attribute similar to the rel-license microformat should be added to the OEmbed standard – that would solve the situation for OEmbed. For manual embeds copy and pasted from the embed providers the providers has to be more clear with what rights you have to use that embed – something similar to Creative Commons deeds perhaps?

Image is licensed under Creative Commons Attribution-Share Alike and created by qthomasbower on Flickr.

On the uselessness of array_merge_recursive()

I guess that most people have run afoul of the monstrosity that is array_merge_recursive(). In short a merge of array('a'=>2, 'b'=>3) and array('b'=>4) gives you array('a'=>2,'b'=>array(3,4)) which isn't the result that one would expect.

So, as usual, I've created a gist that outlines the problem and gives a more sensible alternative.

http://gist.github.com/271920

Talk on Services at Drupalcamp Stockholm 2009

I just held a presentation about services and my plans for services 3.x at Drupalcamp in Stockholm. Everything went well except that I was so nervous about running out of time that I teared through the presentation in 20 minutes. But here are the slides if you missed something.

Check out the english version over at slideshare too

Check out my previous blog post A future for Services - 3.x? for more in-depth information about my views on the future of services.

Attached files: 

Slides in swedish

Slides in english

A future for Services - 3.x?

Services is a module that makes it easy to provide web services using Drupal. What services doesn't do is to allow the definition of separate API:s. This is something we need to fix if we want to turn services into a real web-service framework.

Consider the following: Today all installed services are always available on all installed servers and they all have to use the same authentication method.

This is what makes services practically useless as a building block for other modules, and what makes is nigh on impossible for API:s to coexist in one Drupal install. This worked fine when services only was used for integration with a single Flash/Js/external application; when it was installed by the developer/admin to solve one specific task.

Now we're nearing a point where both blog api and pingback implementors are looking to leverage services for their modules. This is great, as our goal must be that everybody implementing any kind of web service should look to services (core inclusion on the far horizon). Unfortunately it's not possible with the way services is constructed today.

The proposed solution

What I propose, and have gotten quite far with implementing, is to introduce the concept of separate endpoints. Endpoints allows modules and administrators to define separate API:s. By this I mean that each endpoint will provide the following information:

• which services should be exposed
• with what server and on which path they should be exposed
• how should the clients authenticate themselves

The endpoints can be customized completely independently of each other. Endpoints can also be created directly through the administrative interface. The plan is to use ctools for the endpoint information, which will give us exportables for API:s, correct handling of loading of definitions from code and database, overrides et.c.

I'm really exited about the possibilities that this provides, and how it ties in with features. I see it as absolutely essential for services continued development, and not as a good-to-have extra. That is not to say that it needs to be implemented exactly as I've done it. But we need the core functionality.

The current state of 3.x

I'll illustrate with some screenshots from a site running the endpoints-branch from github:

This is the new (when say new throughout the post I mean "my proposed new") first-page for services admin. It lists the services endpoints in the installation and some brief info about the path, server and authentication module that's used, and it lists the active services for the endpoint. The services that are listed may be fully or partially enabled.

This is a shot of the edit endpoint page. Here you can choose the path for the endpoint and which server and authentication module that should be used in the endpoint. Here you can see that the oauth module has gotten a new configuration which is OAuth context, described pretty well in the form: "The OAuth contexts provides a scope for consumers and authorizations and have their own authorization levels. Different services endpoints may share OAuth contexts and thereby allow the use of consumers and tokens across the services endpoint boundraries."

This page allows you to select which services and controllers will be exposed at the endpoint, and allows the authentication module to supply options for each controller.

What I like the most is the ability to define a services endpoints in code. Here we have the conglomerate module that I'm currently working on that defines it's own endpoint. This way modules can expose their own API:s and own authentication settings without disrupting each other.

The same goes for oauth_common, where modules now can define their own oauth contexts. Both these are perfect candidates for chaos tools integration, and ties in perfectly with the features-way of thinking.

Endpoint branches:

• Services
• REST Server
• OAuth Common
• Services OAuth

Co-Maintainers Wanted!

The list of modules that I maintain has become quite long, and in the beginning of next year I'll have a little daughter (if the nurse guessed right on the gender). So the time that I have for being a good maintainer will be very limited.

If you feel that you'd like to help maintain any of the following modules, I would be very grateful!

• Cobalt
• Node form columns
• OAuth Common
• Services OAuth
• Simple Geo
• JSONRPC Server
• Query builder

Modules not on DO

• Services OOP
• CSS DRY

Experience of using git, or the willingness to learn, is kind of a requirement, as all my development is done with git. The alternative is a patch-based workflow.

Copying Ubuntu VM:s and eth0

Note to self: when copying virtual Ubuntu servers between machines the MAC address will be changed and a eth1 device will be added with the new MAC address. But it won’t be properly configured. Edit `/etc/udev/rules.d/70-persistent-net.rules` and remove the old `eth0` device and rename the `eth1` device to `eth0`. Then reboot and everything should be fine.

If you’re running a local bind9 server, remember to update the zone file so that the A-records match your new IP-address (For me that was `/etc/bind/db.vmdev`) and restart bind: `sudo /etc/init.d/bind9 restart`.

Dynamic vhost configuration

I've recently tried out a new way define my virtual hosts on my development machine. I've always had a configuration file in my home dir (that gets included from httpd.conf) that looks something like this:

Ensuring that values are in an array

I've run across situations where I want to ensure that some values exist in a non-associative array (without getting duplicates). The way I've usually solved it is:

if (!in_array('nid', $fields)) {
  $fields[] = 'nid';
}
if (!in_array('title', $fields)) {
  $fields[] = 'title';
}

This is kind of ugly, and the more values you want to add the uglier it becomes, so it evolved to:

$ensure = array('nid','title');
foreach ($ensure as $f) {
  if (!in_array($f, $fields)) {
    $fields[] = $f;
  }
}

This is great if you have a known array of values that always should exists. But if you have third party code that could have requirements for certain fields to be there, or logic that's more spread out that determines the fields that needs to be ensured, this is the way I've settled for:

$fields = array_fill_keys($fields, TRUE);

// Add a required field
$fields['nid'] = TRUE;

// Add a set of required fields
$fields += array_fill_keys(array('title', 'created'), TRUE);

// Add another set of required fields
$fields += array('modified' => TRUE, 'teaser' => TRUE);

$fields = array_keys($fields, $ensure);

This way we get away with not using loops or conditions by first turning the values into keys in a associative array, modifying them, and then turning the keys into an array again. I guess this is a matter of personal preferences, and this last approach might have the drawback that it's not immediately obvious what's going on for the uninitiated. The other two approaches are more readable.

Convenience scripts for Solr

This is a set of convenience scripts for daily drupal use of solr in a dev environment. When you use the apachesolr module in many projects it becomes somewhat boring to set up solr again and again. And when you have a whole team doing the same thing, this script becomes a time-saver.

This little project lives at github (as usual): http://github.com/hugowetterberg/solr_nightly. Clone or download and execute get-nightly from the terminal (when inside the solr_nightly directory) to download the latest nightly and set it up with the drupal-specific configuration files.

$ ./get-nightly

Then execute start to get solr up and running.

$ ./start

Now your drupal install should be able to use solr through the apachesolr module. Press ctrl+c to quit solr. If you want to clear out all files that's been created for the search index and other runtime files (to use it with another drupal install, or just to start over), run:

$ ./reset

Remember to delete the index from the drupal admin when you have a site that expects that there is a index. Otherwise your nodes won't be re-added.

Re-run the get-nightly script if you want to download the nightly again.

Code lost

If you're anything like me you probably misplace some code every once in a while. I have a drupal module that I work on in both spare and work time, and I use it in many projects. I sat down just now and started coding on a feature when I realized that I've already done it somewhere else - but where? Somehow I had to find it, and being a programmer, doing it manually isn't an option. So here follows a quick, osx only, tip on how to sift through folders by combining spotlight searches with your own logic.