[ckan-dev] AGPL as applied to CKAN extensions that interact with external services

Wed Mar 14 02:31:33 UTC 2018

Re: "my question remains whether there are any obligations
on source to any APIs provided by other servers that the extension
interacts with as part of its operation?"

I would say not, particularly as CKAN is designed to link through to API
endpoints as a typical use case. A resource can be defined via a URL to an
external API endpoint, for example.

I'd also just say that such matters should be checked by your own council
to be sure.

Cheers,
Steven

*STEVEN DE COSTA *|
*EXECUTIVE DIRECTOR*www.linkdigital.com.au

On 14 March 2018 at 12:18, Adam Eijdenberg <adam.eijdenberg at digital.gov.au>
wrote:

> Hi ckan-dev,
>
> We are exploring writing an extension to CKAN that provides an
> integration with another system that we host that may allow us to add
> some interesting additional features to some of our datasets.
>
> We note that CKAN is licensed under AGPL. As I understand it, the
> source for a CKAN extension that is hosted ("conveyed"?) on the same
> server as CKAN must also be released under AGPL.
>
> If that extension provides services by interacting with an API on
> another server, are there any obligations on the license under which
> the source for the component on the other server is offered, if at
> all?
>
> Looking around I note the existence of other extensions such as:
>
> - Active Directory authentication for CKAN [0]
> - Upload resources to AWS S3 [1]
>
> (and, while not an extension, a dependency by CKAN on Postgresql)
>
> where neither AWS S3, Active Directory, nor Postgresql are licensed
> under AGPL, so my assumption is that this kind of usage is both
> contemplated and within the spirit of the AGPL, however in attempting
> to address this area the AGPL FAQ states [2]:
>
> > If some network client software is released under AGPLv3, does it have
> > to be able to provide source to the servers it interacts with?
> >
> > AGPLv3 requires a program to offer source code to "all users interacting
> > with it remotely through a computer network." It doesn't matter if you
> > call the program a “client” or a “server,” the question you need to ask
> > is whether or not there is a reasonable expectation that a person will
> > be interacting with the program remotely over a network.
>
> In this case, I would see the CKAN extension being a network client
> (of the API hosted elsewhere) but also being remotely interacted with
> in the context of a user interacting with CKAN. As such my first
> thoughts are that we would be obligated to release the CKAN extension
> under AGPL, but my question remains whether there are any obligations
> on source to any APIs provided by other servers that the extension
> interacts with as part of its operation?
>
> Many thanks,
>
> Cheers, Adam
>
> [0] http://extensions.ckan.org/extension/adfs/
> [1] http://extensions.ckan.org/extension/s3-resources/
> [2] https://www.gnu.org/licenses/gpl-faq.html#AGPLv3ServerAsUser
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20180314/e800441b/attachment-0003.html>