[okfn-help] Licenses in CKAN

[John Bywater]

Rufus Pollock wrote:
>>
>> Just put an REST interface over the model, like with the CKAN API...
> 
> I take your point but I'm not really sure about whether that is needed
> here. Maintaining a "service" involves a whole extra layer of effort

Not this time. In general, the "whole extra layer of effort" thing goes
away if the work of application service provision is automated, like
with Provide.

http://appropriatesoftware.net/provide/Features.html
http://appropriatesoftware.net/provide/Documentation.html

However, none of that is needed here. A proper Open Knowledge Licenses
REST API need be nothing more than putting the license data in JSON
format, probably in a text file behind an HTTP server. You could even
put the  text file in Subversion, like with the other OKF services.


> and the primary use for this list is integration into other services.

And the obvious pattern for doing that is OPEN HOST SERVICE. Suddenly
you and unknown others can use the exact same license information, and
none of the application service providers need be worried about keeping
up-to-date a data-dominated software package that is unlikely ever to
reach a steady-state.

Open knowledge license data is an object resource. So the OKF should
name the universal resource location for licenses. It's a list of VALUE
OBJECTS, so it's a single resource, which should be presented in an open
data format. Any client service could easily cache the data for
robustness and performance, but so could HTTP infrastructure (REST).

Then it can be used by systems that aren't written in Python. Changing
the license information would be a very simple task. And it would be a
neat Open Software Service.

http://opendefinition.org/ossd

> 
> Of course in the long run we could look to have some "core" license
> information served out via several "interfaces" -- web service, simple
> file download, scm integration etc.
> 

Que? Now you're making it over-complicated. :-)

Best wishes,

John.


> Regards,
> 
> Rufus