Skip to Content.
Sympa Menu

cc-devel - Re: [cc-devel] Adding OFL support to XMP/liblicense

cc-devel AT lists.ibiblio.org

Subject: Developer discussion for Creative Commons technology and tools

List archive

Chronological Thread  
  • From: Asheesh Laroia <asheesh AT creativecommons.org>
  • To: Nicolas Spalinger <nicolas_spalinger AT sil.org>
  • Cc: CC-devel <cc-devel AT lists.ibiblio.org>
  • Subject: Re: [cc-devel] Adding OFL support to XMP/liblicense
  • Date: Fri, 24 Oct 2008 08:16:14 -0400 (EDT)

On Wed, 22 Oct 2008, Nicolas Spalinger wrote:

The description of the license is here: http://scripts.sil.org/OFL

It's a community-recognized license for fonts:
http://unifont.org/go_for_ofl/

With the corresponding human-readable representation here: http://scripts.sil.org/OFL#9ccf5052

I'm attaching a draft rdf snippet of the machine-readable code.

I put that on the web for people joining us late: http://labs.creativecommons.org/~paulproteus/draft-scripts.sil.org_licenses_OLF_1.1_.rdf


Apparently the given sample isn't quite valid XML nor RDF, but I have a sense of what it means.

Oops, must have forgotten to run it through a validator. I'm very willing to improve the current draft with your suggestions?

Well, for one thing, you redefine the cc: namespace as being a reference to your domain. You should pr

AFAICT ccREL encompasses RDF and XMP... How does XMP fit in?

XMP is a way to store RDF in a bunch of file types.

I noticed you created your own terms that mean "Derivatives" and "Distribution" and "Notice" and a few others. Do you intend to use a different vocabulary?

We intend to reuse the terms which are well-established in the CC community and add the ones needed to express the specificity of the particular license (the OFL is FSF and DFSG-validated BTW).

Okay, so you should probably undo the changes where you use a non-CC term (in RDF, a term is a URI) for those two.

It's a question of hosting I guess, isn't it?

It's a sense of who is responsible for those terms, since in RDF terms are named by their URIs. Those URIs for terms don't have to point to web pages that exist; it's more of a conceptual hosting than literal hosting.

I'm not yet sure how a set of rights expressed by a particular license definition and hosted by the maintainer of that particular license should cascade to include other definitions hosted somewhere else...

The OFL cc-like expression is not officially recognized/affiliated with CC. For example shouldn't the GPL/LGPL expressions point back to FSF/GNU as the author/maintainer of the license directly? CC has links to the FSF but what about the other licenses? How do we extend the liblicense framework to take into account the MIT/X11 license for example?

I agree that this is confusing; I'd love to hear Nathan Yergler's or Mike Linksvayer's thoughts on this.

Also, I'm not really sure what we would do with the RDF file.

There are various formats used for fonts and font sources which could usefully be flagged. One very useful scenario would be that such font and font sources containing OFL-related metadata would show up with a OFL emblem/ human-readable representation of the RDF in nautilus (via liblicense-gnome) and provide clickable links from the fields with URLs.

Oh, that is sensible!

At this stage the RDF can be part of an SVG rights expression (via Inkscape).

That makes sense.

Can font files store embedded metadata about the license they are under? (That's a serious question!)

Yes, there are already fields in the OpenType spec to hold such information: http://partners.adobe.com/public/developer/opentype/index_name.html

The NAME table has the following fields: Copyright notice, Trademark,
Manufacturer Name, Designer, Description; URL Vendor, URL Designer,
License Description, License Info URL

Interesting. Can I ask how OpenType relates (if at all) to TrueTypeFonts that I know about?

I don't think it makes sense in the GUI chooser we bundle with liblicense to let people chose the OFL.

Font designers would like to be able to visually tag extended font sources (with may not have metadata fields as such) to differentiate them from other sources.

Okay, so probably in font saving apps, there should be something like:

( ) No license
(X) Open Font License
Sharing of this font is permitted under the terms of the Open Font
License

(all the OFL icons with clickable info)

but only in font saving apps, since it makes no sense to me to right-click a JPG and save it under the OFL.

Also in the font viewer/manager we're planning we'd like to be able to
know and sort which fonts (and font sources) are open/are from that
designer/foundry and so on based on such metadata would be extremely
useful for users. For the font formats without existing metadata fields
RDF/XMP sounds like the ideal solution.

Yes! Is there more than one of these open font licenses?

-- Asheesh.

--
Saint: A dead sinner revised and edited.
-- Ambrose Bierce




Archive powered by MHonArc 2.6.24.

Top of Page