|
|
| (2 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | [[Category:Developer]] | + | #REDIRECT [[Liblicense]] |
| − | [[Category:Technology]]
| |
| − | | |
| − | {{incomplete}}
| |
| − | | |
| − | A library for managing metadata, in particular CC licensing information.
| |
| − | | |
| − | The idea of this library started out on the [[IRC]] channel, in a
| |
| − | discussion on how to best help boost the community of software
| |
| − | developers working with things related to CC - mostly the metadata
| |
| − | format.
| |
| − | | |
| − | Basically, the idea is to write a portable C library that manages
| |
| − | metadata for CC licenses, and a bunch of other licenses of interest to
| |
| − | the community. It will not do the actual
| |
| − | embedding of the metadata, but instead be a help to developers adding
| |
| − | metadata support to other libraries and applications, such as libogg,
| |
| − | libsndfile, ImageMagick and ccpublisher.
| |
| − | | |
| − | The library will produce licensing information based on the
| |
| − | specifications of calling libraries and programs. In addition to generating text for specific licenses, it will also allow an application to enumerate which licenses are currently available and provide descriptive text for each license, and for license features. It should also provide an easy way to specify "verify at" URLs.
| |
| − | | |
| − | The benefit of this library is that applications linking to it can correctly offer licensing choices, and these choices can be transparently updated as license versions are updated.
| |
| − | Human readable descriptions will also be internationalized, preferably using the same .po files used by the CC web site.
| |
| − | Hence libcclicense will take advantage of software updating and i18n systems to allow applications to always provide c
| |
| − | current and correct licensing choices and license text.
| |
| − | | |
| − | Part of the project is also to provide wrappers for the library for
| |
| − | other languages, and to help external developers add metadata support to
| |
| − | their projects. A good start will probably be to wrap the library for
| |
| − | Python, and use it for ccpublisher.
| |
| − | | |
| − | We might also find that we also need to maintain libraries to embed and
| |
| − | extract metadata in/from common formats where adding support to existing
| |
| − | libraries isn't possible, or isn't enough. There seems to be people
| |
| − | working on something like this already ([http://gnunet.org/libextractor/
| |
| − | libextractor]).
| |
| − | | |
| − | As libcclicense itself deals only with text strings, we can also make GUI libraries to provide dialogs which present these strings to the user in desktop or web applications. This layering ensures that such dialogs present consistent licensing choices.
| |
| − | | |
| − | == Gnome Summit ==
| |
| − | | |
| − | At the Gnome Summit we explored adding CC licensing to various Gnome applications. Application developers appeared to have a few needs:
| |
| − | | |
| − | * They want to display the appropriate icon (or other) for a particular license. For instance, AbiWord could display a small icon representing license status in the tool bar. Music players could display the icon in the controls area. A music streaming app might want to play a 5 second "Now entering the Creative Commons" chime (much like radio station identification, but for licenses).
| |
| − | * They want to allow the user to easily select a license. This would probably be a wizard that asks the user questions and tries to select the most appropriate license from all that it knows about. Much like a file selection dialog, but navigating licenses instead of your file system.
| |
| − | | |
| − | Most of the needed information is stored in the current [http://api.creativecommons.org RESTful API]. A low-level libcc could talk directly ot this, handling all the HTTP traffic and XML parsing required. It would allow the client to determine the questions that need to be asked to select a license, and to download any icons, blurbs, etc for all known license types.
| |
| − | | |
| − | The low-level library solves the first problem above, but not the second. It's still too difficult to ask the user to select a license. Layered on top of the low-level library would be any number of high level libraries that would convert the textual questions into GUI widgets and present them using the appropriate toolkit (GTK+ / KDE / Cocoa / Win32 / etc). This way, adding license awareness to an application should be as easy as "license=SFGetLicense(); saveDocument(license)".
| |
| − | | |
| − | An initial stab at the interface for the low-level library was stubbed out: [http://rinspin.com/bronson/stuff/cc/cc.c.txt cc.c] [http://rinspin.com/bronson/stuff/cc/cc.h.txt cc.h]. The most important question, how the low-level lib would present the questions to the clients, was not solved yet.
| |
| − | | |
| − | ==== The Showstopper ====
| |
| − | | |
| − | The biggest problem we found was that application developers hate having more dependencies. It's difficult to convince them that the benefits of being able to display and select CC licenses offsets adding more dependencies to already large projects. The dependency problem becomes even more accute when you realize that, to deal with the REST API, you need to pull in an XML parser. libxml2 doesn't come cheap. Expat might be a good choice but it's relatively unknown and doesn't include an HTTP component (making libcurl yet another dependency).
| |
| − | | |
| − | There were other, smaller problems, but nothing that couldn't be worked out. (offline usage, caching, ...)
| |
| − | | |
| − | ==== Alternate Proposal ====
| |
| − | | |
| − | Perhaps the way to move forward for now is to provide a package of standard icons and some example code that shows how to use them. This would allow applications to easily and simply display CC info.
| |
