[cc-devel] CCTools Metadata and Liblicense
Nathan R. Yergler
nathan at yergler.net
Tue Jul 17 12:44:37 EDT 2007
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
>
More information about the cc-devel
mailing list