Developer discussion for Creative Commons technology and tools

["Nathan R. Yergler" <nathan AT yergler.net>]

Comments inline...

On 7/14/07, Jason Kivlighn <jkivlighn AT gmail.com> wrote:
> I'm looking through Subversion for modules relating to metadata and came
> across these three: xmp, cctagutils, and cli_tools.  These all appear to
> do some subset of what the embedding/extracting aspect of liblicense[1]
> does, so I want to pose the question:  Can we work towards removing them
> in favor of liblicense?
>
>  * xmp - An embedding GUI frontend for liblicense could replace
> pdf_license_manager
>              PHP bindings for liblicense could replace jpeg-php,
> although we'd have to figure out handling of arbitrary metadata in
> liblicense.

Sounds like we need PHP bindings, and then we can think about it.  I
haven't looked @ pdf_license_manager in a while, so I can't comment on
it directly.  The arbitrary metadata handling will be needed in
general if we want to replace cctagutils, etc (since they handle
things like title, author, etc).

>  * cctagutils - Liblicense can embed licenses in all formats supported
> by cctagutils.  The liblicense python bindings make it an easy
> replacement for cctagutils.  Liblicense doesn't do other metadata that
> cctagutils handles, but it already links against the libraries that
> would easily allow this.

This would be great -- we need the following:

* Windows/Mac OS/Linux builds all working.  IIRC there may be a
wrinkle or two with needing Visual Studio for Windows, but we can
cross that bridge when we come to it.
* Handling for arbitrary metadata, as mentioned above.

>  * cli_tools - 1) I couldn't get it to run (name 'validateOptions' is
> not defined) and 2) from the README, it looks like it extracts/embeds
> licenses from MP3's.  That's exactly what liblicense can do, except in
> it's in python.  Again, the liblicense python bindings cover that.

Agreed; see above.

> On a larger scale, consolidating metadata handling could really help
> towards clear metadata standards and easy metadata embedding relating to
> licenses.  During my research for a Google SoC project, I came across
> several CC/non-CC applications/libraries dealing with metadata and
> frankly didn't know what to make of them.  I wondered if what I was
> looking at was obsolete or an out-dated way of handling metadata.  The
> tools' methods of handling metadata I found and what I found on the Wiki
> contradicted one-another.  Several tools worked at one point, and looks
> like they have since become neglected and broken.

I don't see us making ccLookup/ccPublisher (which both use cctagutils)
revisions a priority in the near future, but having the ability to
consolidate those libraries would be a definite benefit.

NRY


> I think that consolidating license embedding and extracting into
> liblicense can help towards a definitive metadata standard for
> licenses.  CC could point to liblicense and say: "This is how licenses
> should be embedded in format X".  Already, Liblicense reads and writes
> licenses to avi, mov, jpeg, png, tiff, wav, vorbis, mp3, flac, musepack,
> svg, pdf, and smil.
>
> Liblicense is portable.  It will (eventually) work on all OS'es; the
> libraries required for embedding/extracting licenses are all
> platform-independent.  And it's in C so bindings, IMHO, are trivial to
> write. (I hear we've just picked up Ruby bindings)
>
> Liblicense doesn't yet do everything it needs to for my proposal, but
> I've got (at least) the rest of the summer to work on it.  Let me know
> what needs to be done, and I can get on it.  And if anyone else would
> like to jump in, liblicense is in an early state, making it a great time
> to step up and get involved.
>
> Cheers,
> Jason
>
> [1] http://wiki.creativecommons.org/Liblicense
>
> _______________________________________________
> cc-devel mailing list
> cc-devel AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/cc-devel