• General CC help
• CC technology (ccREL and software projects)
• Where and how to publish CC works
• Where and how to find CC works
• CC in education and science

If you’d like to help out and educate others about using CC licenses and tools, you can sign up on the wiki page.

After some digging we arrived at Issue 308. The problem occurs when a non-compliant OpenID-enabled site asks for the OpenID URL and the user supplies something that should work, but isn’t canonical. For example, my CC Network profile is at https://creativecommons.net/nathan/. I should be able to use any of the following as my OpenID and have the site get to the canonical version:

• creativecommons.net/nathan
• http://creativecommons.net/nathan
• http://creativecommons.net/nathan/
• https://creativecommons.net/nathan

The process of getting from one of these to the canonical version is called normalization.

So if an OpenID enabled site (such as, say, sourceforge.net or intensedebate.com) doesn’t do normalization, the user ends up asking to be validated for some URL other than their own canonical identity. And our server kicks that back as an invalid OpenID URL. Intense Debate seems to be aware of the issue; someone already reported it on their Get Satisfaction forum.

We briefly considered working around this bug (and it is a bug) but ultimately decided against it. It didn’t “smell” right and after some thought we realized that it could cause users more problems down the road. For example, if we implemented the proposed fix (making the trailing slash optional, which would have fixed it in most cases, it appears), a user could end up logging in at a broken site with the URL https://creativecommons.net/foo. If that site later fixed their code to correctly perform normalization, the user would suddenly be asking to validate a different URL — https://creativecommons.net/foo/. I suppose a site that has this bug and needs to fix it could normalize all the OpenID URLs stored in their database before pushing out the patch.

Instead we went ahead and added an error screen so that instead of the completely frustrating never-ending login loop, you at least get a hint that something’s wrong (and how to fix it).

The moral of the story? If you run into a problem logging into an OpenID-enabled site, first make sure you’re using your “real” URL (and if you still have a problem, at least with your CC Network ID, please report it).

I just pushed an update to the development version of the API that adds <description> elements to the individual <enum> elements. These map to the help pop-ups we use on the main license chooser. If all seems well we’ll push this down to 1.5 as well.

I should also note that this update includes two new, very nice (for me) improvements:

• I finally landed Frank’s test suite work from last summer. We had intended to replace the whole API with a leaner version, but that’s still in the works. So in the interim, we have a test suite and I’m not afraid of change anymore (on this project at least).
• I’ve updated the documentation to use Sphinx. ReStructured Text is the secret weapon of many a Python project; Sphinx makes it even more powerful, providing a set of directives and tools to generate something that looks, well, at least decent.

Eek.

LicenseChooser.js 0.96, as you can see at http://labs.creativecommons.org/demos/jswidget/tags/0.96/example_web_app/, fixes this problem.

(click for larger version)

Search based on the license of a song/album with direct support of displaying CC license logos!

More details available on Gabriel’s blog post.

This feature is slated to be in Banshee 1.6 but you can play with Gabriel’s development branch which has this feature thanks to the beauty of git.

git clone http://banshee-project.org/~gburt/banshee.git

Technical notes of the feature: Gabriel wrote his own parser for extracting the license information from the files. That was needed because there is currently not a Mono port of liblicense, a library which reads and writes license metadata to a wide variety of files. But now if anyone wants to help out and do the port to Mono you have an example of how to access this information via Mono.

Lets keep this ball rolling and get license read/write support in more applications!

Hugo’s work was a success; he announced in August 2008 a test version of the validator. He built on top of the work of others: the new validator uses the Pylons web framework, html5lib for HTML parsing and tokenizing, and RDFlib for working with RDF. He shared his source code under the recent free software license built for network services, AGPLv3.

So I am happy to announce that the test period is complete, and we are now running the new code at http://validator.creativecommons.org/. Our thanks go out to Hugo, and we look forward to the new validator gaining some use as well as hearing your feedback. If you want to contribute to the validator’s development or check it out for any reason, take a look at the documentation on the CC wiki.

Subversion and git in particular seem to cause long-duration high disk load, which causes Nathan Kinkade to get paged when e.g. wiki.creativecommons.org takes too long to load. We have found that using ionice to set background activities to “idle” priority is very useful in avoiding sending text messages to NK.

However, ionice can only be run by root, meaning regular users can’t even request the system be more gentle. So I wrote a simple tool, “ionicer,” that is a setuid-root C tool that sets its parent process’s IO priority to idle.

You can check it out in my gitweb.

I then used dpkg-divert to replace /usr/bin/svnserve and /usr/bin/git with simple shell wrappers that call ionicer before calling the real binaries.  So the call path goes:

• user connects with svn+ssh to code.creativecommons.org
• user logs in with an SSH key and executes “svnserve.”
• svnserve is really a shell script. /bin/bash runs a script which does two things:
  1. Runs ionicer, which changes the shell to I/O priority class idle, and
  2. Executes svnserve.real with the same arguments as were passed into the wrapper.

Ta-da!

For a few months, I had been working on a replacement for Pootle that better-fit our needs. Mozilla, as it happens, has similar issues, and when I recently investigated, I found that they were working on improvements to Pootle. So enough working alone; we’ll work with them! Their project to improve Pootle is called “Verbatim,” and I encourage all interested in web-based translation software to read more at that link.

Nathan Yergler and I sent an email to our international affiliates email list, and since I have a lot to do before tomorrow, I’ll let it speak for itself:

A bit more than a month ago we hinted we were working a new web-based translation tool.  We’re committed to making translation easier and more productive for all of our affiliates.  To that end, improving the tools is one of Asheesh Laroia’s current focuses.  This message should be considered as coming from both of us.

BRIEF SUMMARY

Things are going to look prettier on http://translate.creativecommons.org once we flip the switch into a
newer version of the software on Wednesday morning, Nov. 26 Pacific time.  We’re making things easier to use by joining forces with Mozilla and the Pootle developers on improving Pootle.

DETAILS

So we’ve joined forces with the Mozilla project on an overhaul to Pootle.  They’ve decided to make improvements to Pootle to make it suitable for their translation efforts and in true open source fashion
we’re benefiting from their changes and contributing our own.  Mozilla has already improved the user interface quite a bit, so we’d like to share that with all of you.  There’s a long series of Pootle
improvements coming down this pipe, we expect; this is just the opening.

From our end, we’re also going to make the process more streamlined for translators.  Here is some feedback we’ve gotten, and how we plan to address it:

Issue: “It takes too long to see the translations on the web, either on the staging site or the main site”

Response: (Done) For all admins of a language, there is now a link labeled “Commit” you can do in Pootle.  When you do this, the latest translations go live on staging.creativecommons.org.  (I think this is
pretty cool. Try it!)

Issue: “It’s hard to understand how to use Pootle”

Response: (In progress) In the next few days, I’ll be publishing a video of basic Pootle usage that slowly shows how to be sure you are using it effectively.  I’m happy to answer other questions about how
to use it.

Issue: “It’s hard to keep up”

Response: (In progress) We’ll start emailing statistics to the CCi list showing which languages are in need of work.  The new Pootle calculates how many words need translation rather than how many messages, which is much more accurate.

Other changes we have or will be making:

• We’ve gone through and made all existing translators for the website into admins which means you can now deputize others without our intervention.  Documentation managing your translators will be part of the documentation/screencasts that Asheesh works on.
• Pootle will be likely migrating from its old “jToolkit” backend to the more modern Django.  This will make it faster and more reliable in the long run
• We’ll run a nighly script that makes sure that if we add a new string to translate, it shows up in Pootle within a day.
• I’ve [Asheesh] enriched the PO files with some extra “context”information saying what the string is used for; for example, you will see not only the language name “Korean” but our internal code for it, “lang.kr”. This probably won’t be interesting to most contributors but if you’re trying to re-use our templates, etc for your own site it’ll help you connect the dots.

Again, this is just the first stage of the Pootle upgrade coming down the pipe thanks to our working with Mozilla.  We were working on an independent replacement for Pootle called “Herder,” but when we
discovered all this activity by Mozilla we realized it would be most beneficial if we joined forces with them.

We’re planning to flip the switch Wednesday morning Pacific time. There may be up to one hour of downtime, but we think the downtime should be limited to about a period of five minutes.

Thanks for your contributions to date and all your feedback.  If you have additional feedback, gripes, suggestions, we’d love to hear them.  Also, please feel free to email us offlist with questions regarding
your account.