Developer discussion for Creative Commons technology and tools

[Jason Kivlighn <jkivlighn AT gmail.com>]

We're looking at various different use-cases, all of which should be
handled separately.  I want to be sure we're clear on which use-cases
we're dealing with and discussing here.  All cases should be handled,
and handling one case shouldn't interfere with another.

1) Selecting a license for a file from within a file manager (i.e.
Dolphin or Nautilus).  We could be dealing with any type of content --
source code, content/media, etc -- so being able to select the right
class of license based on the file type makes sense.

2) Selecting a license from within a specific application, i.e.
KOffice.  When KOffice offers the user a choice of licenses, we can
safely assume that we want to offer content licenses (like CC).  We
don't need to offer the GPL  or other source code license as a choice. 
No automation based on file type is required.

3) In the case of using liblicense with KNewStuff, a license is
potentially selected for a collection of files.  This is the case where
what is being fetched is a tarball or zip.  We can't go by the file
type, since the tarball may be a collection of CC-licensed photos, or an
application licensed under the Artistic License.  The user should
explicitly specify whether it's content, source code, or something else.

I like the idea of extending the license metadata (the RDF) to include a
"class" element which specifies whether it's a license recommended for
source code, content, or some other class.  This is the most generic
solution.  An application could ask for licenses from a particular
class.  Or if appropriate, it could determine for itself which license
class to choose from based on a mime-type.  Liblicense could even
include a set of known file type to license class mappings to ease in
the frontend implementation.

Given all of the above, I think liblicense should make it easy to create
two types of license choosers: 1) a frontend license chooser that is
content-based, like we currently ship.  And 2) It should also make it
easy to create a general license chooser that covers source code
licensing and everything else.  This could simply present a list of
licenses to choose from, while providing additional info describing each
license.  One might consider an attribute-based license chooser, like
the current one for content, that would be used to license source code
-- but given the intricacies among source code licenses, it just doesn't
make sense and couldn't possibly be accurate.  Choosing between the two
types would be up to the application to decide -- an application can do
what makes sense for the current context (i.e. the 3 contexts above).

Okay, enough rambling.  I'm just throwing out bottled-up, random,
thoughts.  Maybe I'm over-complicating things.

Cheers,
Jason

> Hi all,
>
>   
>> Possible, yes... I just want to point out that we'd first have to extend
>> the API and license RDF to specify "classes" of licenses.  That way
>> liblicense knows which license is which class (content, source code,
>> documentation, etc.).
>>     
>
> I suggest somehow that the allowed licenses are determined
> automatically by the system. Well, KDE knows what kind of file it is.
> Why put a radio button or a combo if it can be done automatically ?
>
> There should be a "database" that says for each filetype what licenses
> are supported.
>
>
> Bye,
> Rafael Fernández López.
>