Developer discussion for Creative Commons technology and tools

["Nathan Yergler" <nathan AT creativecommons.org>]

On Fri, Oct 24, 2008 at 5:16 AM, Asheesh Laroia
<asheesh AT creativecommons.org> wrote:
> 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.
>

And ccREL is really just a description of our schema/vocabulary along
with a set of recommendations/best practices for how they can be
serialized.  ccREL information can be serialized as RDFa, RDF/XML or
XMP.

>>> 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.

Well if it's RDF the "cascade" problem doesn't exist -- you just name
it by URI.  An agent can then dereference that URI if they want more
information.  You're right about the GPL/LGPL; it's ideal if the
maintainer of the license also publish the RDF and metadata about the
license.  You could argue that we should have done better with this
when we published metadata about the GPL 2, and hopefully we won't
have to publish GPL 3 metadata because the FSF will.

>
>>> 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
>

So the License Info URL would hopefully point to a document on the web
with metadata about this file.  It sounds similar to the  Web
Statement field Adobe defines in their XMP Rights schema.

> 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.

This reinforces the need to improve our support for "classes" in
liblicense so you could ask for licenses that apply to software or
fonts, etc.

I guess I'm not clear what the next steps are.  Are you going to begin
publishing ccREL-compatible metadata for the OFL? I'm happy to help
vet your RDF if you need help with that.

Nathan


>
>> 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
> _______________________________________________
> cc-devel mailing list
> cc-devel AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/cc-devel
>