Feature extension / plugin options and licensing options

Development
1

Hello

I am trying to get a grip on the options for extending/enhancing an Open Ed X based platform, and the licencing implications. I found this page:

https://openedx.atlassian.net/wiki/spaces/AC/pages/30965856/How+to+add+a+new+feature+to+LMS+or+Studio

which lists 5 (XBlock, IDA, Django App (standalone), Django app (EdX repo), direct code modifications.

However I’m not clear if this guidance is really relevant / up-to-date as I think the docs under https://openedx.atlassian.net/wiki/spaces/DOC/overview are largely superseded by those at: https://docs.edx.org/

Looking at the developer guidance: https://edx.readthedocs.io/projects/edx-developer-docs/en/latest/

I see a ’ [Open edX Extensions and APIs]’ menu option which points to : https://open.edx.org/extending-edx but redirects to quite general https://open.edx.org/community/customization/

Following the doc menus here : https://open.edx.org/community/documentation/
I see various guides mentioned under Developers section but none are linked to actual docs (which assumed should be).

BTW I’ve tried to report these document issues where there is an option to do so…

So I feel like I’m going round in circles a bit. Can anyone advice if:

  1. This overview is still valid: https://openedx.atlassian.net/wiki/spaces/AC/pages/30965856/How+to+add+a+new+feature+to+LMS+or+Studio
    or is there a more up to date guidance?

  2. Assuming the 5 options listed still are relevant, what are the various licensing implications (if you understand them) on the code you create/modify.

My view would be:

A: XBlock - Apache licence separation, so no requirement to publish
B: IDA via Open Ed X APIs. Debatable - see below
C: Django App (standalone) - probably AGPL or even ‘GPL’ depending on how connected
D: Django app (EdX repo) - AGPL (really GPL)
E: Direct code modifications - AGPL (really GPL)

Use case B - IDAs via the Open Ed X is the use case I’m most interested in. This seems to be a grey area or certainly there are debates about if building an extension on a published API is creating a ‘derivative’ work or not. It seems would depend on:

  • If the API was part of the core licences package, and under what licence
  • If you’ve modified / extended the API itself
  • The intent of the group/team using the licence.

See here for a endless discussions:
https://www.google.com/search?safe=strict&ei=eItGX8fEAcOIrwTinZLYCA&q=REST+API+Derivative+Work+AGPL&oq=REST+API+Derivative+Work+AGPL

Like everyone I’m not a lawyer so I’m not looking for legal guidance but more a view on what is the recommended approach to building feature extensions, the docs describing this and licences, and any indication of the ‘intent’ of the wider team/community.

Thanks

Richard

2

I’m not sure how accurate that wiki page is on all the details. The main thing to know is it was written for edX developers, so it omits a possibility: write an LTI component.

As far as licensing goes, you are more knowledgable about it than most devs. We don’t have specific advice about licensing.

1 Like
3

I believe the most up to date document is actually https://github.com/edx/edx-platform/blob/master/docs/guides/extension_points.rst, which I recently wrote. It would be good to consolidate the docs, but I’m not aware of the considerations involved in doing so.

Personal opinion: The Open edX platform is released under AGPL and the spirit of that is if you’re extending the platform itself, you should publish your code under a compatible open source license for the benefit of the community - which usually means AGPL too. We’re getting a lot for free in Open edX and it’s only fair to give back. If you want to adhere to that spirit but object to the AGPL, then you’ll have to determine for yourself if Apache license (or similar) is compatible, based on criteria like you outlined.

1 Like