Coding period of GSoC 2010 officially ended 16th. I was able to release the new stable version of the OpenOffice Plug-in on that day. So it’s time to have a look back on what I did for the past 4+ months and discuss about the issues I met.
The proposal for the development had following tasks.
- Supporting OpenOffice.org 3.0 – 3.1.
- Adding support for CC0.
- Adding support for Draw.
- User Interface Improvements.
- Adding references to important pages like FAQ and About.
- Provide help around what each option means (“what is Share Alike”).
- Display license information when opening CC licensed documents.
- Other improvements for the UI.
- Speed up the first time license insertion process.
- Support for Internationalization.
I started working on the project since mid April. Moving the code base to OpenOffice.org 3.1 SDK was easy. I also updated the other libraries to their newest version. Then I tried to implement the Draw support. I found that implementation for Draw should be same as the implementation for Impress. So adding Draw support was fairly easy, but I had some problem with the page sizes. The available code did not conceder about the page sizes and the margins. The next problem was; the visible license notice was added to the master page of the Draw/Impress document like a background of an Impress document. Therefore the user can not arrange the notice as he wants.
While I fixing those issues, Nathan asked me to have a look at the Flickr Image Re-Use plug-in. Then I started look at it and integrating its functionality to the CC plug-in. I had to update the API wrappers for the Flickr plug-in to make it working. Then I started using that code to add image reuse support for Open Clip Art. I also improved the loading time of the Flickr dialog.
Then I started RDF adding RDF Metadata in the document. Currently this works only in Writer documents, because OpenOffice.org currently supports adding RDF only for writer documents. Then I get back to improve the image insertion I added Wikimedia Commons and Picasa for that. So the users can now add images using four well known image sharing sites; Flickr, Picasa, Wikimedia Commons and Open Clip Art.
The next thing I did is the UI improvement and adding public domain tools. Those two things were carried in parallel. After discussing with my mentors Nathan and Christopher we decided to use a tabbed window. This will make the licensing less confusing and easy to use.
Next was the internationalization phase. I used the existing i18n repository to add some translations to the licensing dialog, but still there are new strings available in the dialog that should be added to Transifex. Hope those new strings will added in the future. These translations files (.po files) need to be converted to Java resource bundles (internationalization method used in Java). The source folder includes a script for this, and the instructions can be found in the README.
For the last few weeks I was testing and trying to find out the issues related to the plug-in.
Though the new version released as a stable release, there are some problems which actually out of our control. This plug-in will not work in Mac OS Leopard where Java 64bit is the default; this is a known issue in OpenOffice.org. In additions to that, Mac OS X also have a problem in displaying AWT windows (issue 92926). I am still trying to see whether there is anything I can do.
The next issue is with Linux. We tested the plug-in in Debian and Ubuntu, in both cases if the plug-in is installed through the extension manager, the menus either become gray or they will not be available at all. This issue is most probably a problem in 9.10 and 10.04 because the plug-in worked well in Ubuntu 9.04 and Windows. I am glad to say that I have found a workaround for this. If the plug-in installed using the terminal there will not be any problem. Users can use both CLI and GUI versions of the unopkg (Extension manager).
To use the CLI version run
/usr/lib/openoffice/program/unopkg -f ccooo.oxt
and for the GUI version use
/usr/lib/openoffice/program/unopkg gui -f ccooo.oxt
Actually this is not an issue of the plug-in itself it should be a problem with Ubuntu. Similar plug-ins likeOoo2GDand Open Cards are also affected by this problem.
I tested this plug-in in Windows and Linux in both x86 and x86-64 versions and it work without any problem (in Linux with the workaround).
Windows users can simply install it by double clicking the plug-in. Ubuntu (may be other Linux users also) need to install it trough the terminal using
/usr/lib/openoffice/program/unopkg gui -f ccooo.oxt
/usr/lib/openoffice/program/unopkg -f ccooo.oxt
The source code of the plug-in can be found at http://code.creativecommons.org/viewsvn/ccooo/branches/akila-gsoc-2010/
Comments and Feedbacks
While I was searching the Internet to find more issues related to the plug-in, I found some blog posts and comments about the plug-in. I have listed them below.
All of these feedbacks were good, except the Mac OS X issue. I am trying to fix it as soon as possible.
To add new feedbacks, users can use the extension page at extension repository. Still there can be issues related to the plug-in. Those issues and feature requests can be added to the CC issues list.
Nathan suggested a feature for Flickr; to extract add images from a given URL. So users can copy and paste the URL to OpenOffice.org and the plug-in will automatically download the image and add licensing data also. This can be used for others services also.
In addition to that localization should be completed.
This is time time to thank all the people who helped me in achieving this. I should thank the following people specially for helping me;
- Nathan Yergler: for helping me with good suggestions in the pre GSoC period and in the community bonding period.
- Christopher Allan Webber: for mentoring me in this process and for all the good suggestions he gave.
- Nathan Kinkade: for helping with the SVN issues (yes I had some :)).
- Alex Roberts and Greg Grossmeier: for their valuable suggestions in making the GUI.
Now it is the time to rip off the “test” part from the plug-in name “Creative Commons Licensing (test)” :). The plug-in was released for beta testing since May 2010 and it was downloaded more than 400 times. But making a perfect program is impossible thing. So I appreciate if the users can report any issues and suggestions as I mentioned in the Feedback section. I will always try to fix/implement them.
More information about the plug-in and the screen shots are available in the wiki page.6 Comments »
I’m greatly pleased to announce liblicense 0.8.1. Steren and Greg found a number of major issues (Greg found a consistent crasher on amd64, and Steren found a consistent crasher in the Python bindings). These issues, among
some others, are fixed by the wondrous liblicense 0.8.1. I mentioned to Nathan Y. that liblicense is officially “no longer ghetto.”
The best way enjoy liblicense is from our Ubuntu and Debian package repository, at http://mirrors.creativecommons.org/packages/. More information on what liblicense does is available on our wiki page about liblicense. You can also get them in fresh Fedora 11 packages. And the source tarball is available for download from sourceforge.net.
P.S. MERRY CHRISTMAS!
The full ChangeLog snippet goes like this:
liblicense 0.8.1 (2008-12-24):
* Cleanups in the test suite: test_predicate_rw’s path joiner finally works
* Tarball now includes data_empty.png
* Dynamic tests and static tests treat $HOME the same way
* Fix a major issue with requesting localized informational strings, namely that the first match would be returned rather than all matches (e.g., only the first license of a number of matching licenses). This fixes the Python bindings, which use localized strings.
* Add a cooked PDF example that actually works with exempi; explain why that is not a general solution (not all PDFs have XMP packets, and the XMP packet cannot be resized by libexempi)
* Add a test for writing license information to the XMP in a PNG
* Fix a typo in exempi.c
* Add basic support for storing LL_CREATOR in exempi.c
* In the case that the system locale is unset (therefore, is of value “C”), assume English
* Fix a bug with the TagLib module: some lists were not NULL-terminated
* Use calloc() instead of malloc()+memset() in read_license.c; this improves efficiency and closes a crasher on amd64
* Improve chooser_test.c so that it is not strict as to the *order* the results come back so long as they are the right licenses.
* To help diagnose possible xdg_mime errors, if we detect the hopeless application/octet-stream MIME type, fprintf a warning to stderr.
* Test that searching for unknown file types returns a NULL result rather than a segfault.
Google Summer of Code 2008 approaches its end, as less than forty-eight hours are left to submit the code that will then be evaluated by mentors, therefore it is fitting to pause for a moment and sum up the work that has been done with regard to the license-oriented metadata validator and viewer and to confront it with the original proposal for the project.
A Web application capable of parsing and displaying license information embedded in both well-formed and ill-formed Web pages has been developed. It supports the following means of embedding license information: Dublin Core metadata, RDFa, RDF/XML linked externally or embedded (utilising the data URL scheme) using the link and a elements, and RDF/XML embedded in a comment or as an element (the last two being deprecated). This functionality has been proven by unit testing. The source code of a Web page can be uploaded or pasted by a user, there is also a possibility to provide a URI for the Web application to analyse it. The software has been written in Python and uses the Pylons Web Framework and the Genshi toolkit. Should you be willing to test this Lynx-friendly application, please visit its Web site.
The Web application itself uses a library called “libvalidator”, which in turn is powered by cc.license (a library developed by Creative Commons that returns information about a given license), pyRdfa (a distiller that generates the RDF triples from an (X)HTML+RDFa file), html5lib (an HTML parser/tokenizer), and RDFLib (a library for working with RDF). The choice of this set of tools has not been obvious and the library had undergone several redesigns, which included removing the code that employed encutils, XML canonicalization, µTidylib, and the BeautifulSoup. The idea of using librdf, librdfa, rdfadict has been abandoned. The source code of both the Web application (licensed under the GNU Affero General Public License version 3 or newer) and its core library (licensed under the GNU Lesser General Public License version 3 or newer) is available through the Git repositories of Creative Commons.
In contrast to the contents of the original proposal, the following goals have not been met: traversal of special links, syndication feeds parsing, statistics, and cloning the layout of the Creative Commons Web site. However, these were never mandatory requirements for the Web application. It is also worth noting that the software has been written from scratch, although a now-defunct metadata validator existed. Nevertheless, the development does not end with Google Summer of Code — these and several new features (such as validation of multimedia files via liblicense and support for different language versions) are planned to be added, albeit at a slower pace.
After the test period, the validator will be available under http://validator.creativecommons.org/.1 Comment »
The source code is located in two dedicated git repositories. The first being validator, which contains the source code of the Web application based on Pylons and Genshi. The second repository is libvalidator, which hosts the files that constitute the core library that the project will utilise. This is the component that the development focuses on right now.
The purpose of the aforementioned library is to parse input files, scan them for relevant license information, and output the results in a machine-readable fashion. More precisely, its workflow is the following: parse the file and associated RDF information so that a complete set of RDF data is available, filter the results with regard to license information (not only related to the document itself, but also to other objects described within it), and return the results in a manner preferable for the usage by the Web application.
pyRdfa seems to be the best tool for the parsing stage so far. It handles the current recommendation for embedding license metadata (namely RDFa) as well as other non-deprecated methods: linking to an external or embedded (using the “data” URL scheme) RDF files and utilising the Dublin Core. The significant lacking is handling of the invalid direct embedding of RDF/XML within the HTML/XHTML source code (as an element or in a comment) and this is resolved by first capturing all such instances using a regular expression and then parsing the data just as external RDF/XML files.
Once the RDF triples are extracted, one can use SPARQL to narrow the results just to the triples related to the licensed objects. Both librdf and rdflib support this language. Moreover, the RDF/XML related to the license must be parsed, so that its conditions (permissions, requirements, and restrictions) are then presented to the user.
The library takes advantage of standard Python tools such as Buildout and nose. When it is completed, the project will be all about writing a Web application that will serve as an interface to libvalidator.No Comments »
Creative Commons participates in Google Summer of Code™ and has accepted a proposal (see the abstract) of Hugo Dworak based on its description of a task to rewrite its now-defunct metadata validator. Asheesh Laroia has been assigned as the mentor of the project. The work began on May 26th, 2008 as per the project timeline. It is expected to be completed in twelve weeks. More details will be provided in the dedicated CC Wiki article and the progress will be weekly featured on this blog.
The project focuses on developing an on-line tool — free software written in Python — to validate digitally embedded Creative Commons licenses within files of different types. Files will be pasted directly to a form, identified by a URL, or uploaded by a user. The application will present the results in a human?readable fashion and notify the user if the means used to express the license terms are deprecated.1 Comment »
updates of the version 0.0.2:
* Creative Commons menu became visible in Calc and Impress
Although it’s is not working properly yet, the addin is now supporting the other ooo applications.
* License Image bug fixed
Now the addin is retrieving the licenses images perfectly!
* Display dialog when opening licensed documents
A simple dialog box is shown when a CC licensed document is opened.
* Checks if the document is already licensed and warns the user
Something like “You have chosen a different license, do you want to proceed anyway?”
… serveral other minor-updates were made in the addin.
Take a look at the screen shots!
Want to try? Just download the ccooo.oxt file and install it from Extension Manager in OpenOffice.Org!
I’ve been asked, as a tech intern here at Creative Commons, to create a way of locally tracking file licenses on a system. A while back Jon wrote down his ideas about system-wide license tracking on the Creative Commons wiki. The purpose of this system would be to provide an interface for developers to access the available licenses on a system. Additionally, like the existing online license chooser, this library, called libLicense, will feature a way to choose a license through toggling certain flags available for a family of licenses. Naturally, the first family available will be the Creative Commons licenses. The larger goal for the summer is to utilize this library in a few initial systems. Currently, I’m looking at integration into Gnome and Sugar (from the One Laptop Per Child project). This further work will occur after libLicense is working.
To run libLicense the data of all the licenses will need to be stored in some sort of fashion. My initial thought is this:
- All data will be stored in a directory. On Linux this directory would be /usr/share/licenses . (This is borrowed from Jon’s thoughts.)
- Families of licenses will be stored in a subdirectory of the licenses directory. For example, the Creative Commons licenses would be stored within creative_commons.
- Within these family directories each specific license will be stored in a file with the naming scheme <bitcode>-<short name>-<jurisdiction>-<locale>.license . These files will store the license uri, name, status (active or retired), description and legal text. How this will be stored is up in the air. My intial thoughts include separating each attribute on a line or having a format similar to .desktop files.
- In addition to storing license data, some family information must be stored, namely the family bit flags. In the case of the Creative Commons licenses, the bit flags would be Attribution, Share-Alike, Non-Commercial and No Derivatives. They would combine to create the bitcode present in the license filename. These bit flags would be the heart of the license chooser logic. If the combination does not exist, the flags are incompatible.
The library would potentially have these functions:
get_jurisdiction(uri) - returns the jurisdiction for the given license.
get_jurisdictions(short or bitcode) - returns the available jurisdiction for the given short name or bitcode.
get_locale(uri) – returns the locale for the given license.
get_locales(jurisdiction, short or bitcode) – returns the available locales for the given jurisdiction and short name or bitcode.
get_name(uri) – returns the name of the license.
get_version(uri) – returns the version of the license.
get_versions(short, jurisdiction) - returns the available versions for the given short name or bitcode and jurisdiction.
get_short(uri) - returns the short name for the given uri.
has_flag(attribute,uri) – returns if the flag is set for the given uri.
family_flags(family) - returns the flags available for a given family.
family(uri) – returns the family the given uri belongs to.
get_notification(uri[,url]) - returns the notification string for the given url with an option to provide a verification url.
verify_uri(uri) - returns whether or not the given uri is recognized by the system.
get_license(family,flags, jurisdiction,locale) – returns the uri which satisfies the given attributes.
get_all_licenses() - returns all general licenses available.
get_general_licenses(family) - returns all general licenses in a family.
get_families() – returns a list of available families.
Did I miss something? Does something not make sense? Please post a comment.2 Comments »
Although the previous Adobe open source license is quite open, we decided that is was best to use a standard open source license that is respected in the open source community. Opensource.org was invaluable in reviewing the many different open source licenses that are available.
The 4.1.1 XMP release is significant because it include the source code for developers to read, write and update XMP in popular image, document and video file formats including JPEG, PSD, TIFF, AVI, WAV, MPEG, MP3, MOV, INDD, PS, EPS and PNG.
Also, please help digg this so more can find out about it!No Comments »