CiviCRM Community Forums (archive)

I know everyone *loves* getting into the details of open source licensing, so I'll try to keep this conversation very focussed.  Also, I'm not a lawyer.  These are just my opinions based on several years of working with open source licenses and advice that's been given to several projects from the Free Software Foundation.

Drupal core is licensed at GPLv2 or later.  The Drupal Association considers modules to be derivative works of Drupal core and requires them to be distributed with the same license as core when being distributed on Drupal.org.

https://drupal.org/licensing/faq/#q7

For Drupal modules, it is the act of committing the code to Drupal's git repo that adds the GPLv2+ license.  GitHub doesn't have the same licensing requirements so you can write a module that's maintained on GitHub using an MIT license and distributed it on Drupal.org with a GPLv2 license because the MIT license allows that. 

During the recent DC CiviCamp, the team working on CiviVolunteer clarified that it would be maintained as an extension and that all extensions developed by that team would be licensed as AGPLv3, but we didn't continue the conversation to address whether extensions are consider derivate works of CiviCRM and require an AGPLv3 license or whether developers are free to choose alternative licenses. 

Clarifying this at the policy level before extensions grow too much further is really important for a number of reasons.

CiviCRM uses the AGPLv3 license which closes the SaaS loophole that exists in GPLv2 and GPLv3.

First, the "loophole" isn't necessarily a bad thing.  In Drupal's case, the contributions to the project from companies  that have locked up features and functionality that improve Drupal in a SaaS offering in many case contribute far more code back to the project than companies that share everything.  As more improvements are made to CiviCRM at the extension level and an AGPLv3 license isn't required, the SaaS loophole is opened UNLESS the extension is distributed.  Someone could host a version of CiviCRM improved by extensions and not be required to share those improvements.  That may be OK or it may not, but it should be clear.

I'm not sure if http://civicrm.org/what/licensing was written before extensions, but this sentence is troubling...

The following guidelines cover project guidelines for licensing and copyright for patches and code contributions to be accepted into the core codebase.

Because the guidelines specifically target patches and code contributions for CiviCRM core, this would imply that these guidelines do not apply to extensions.  If the goal is that all improvements made to CiviCRM will always be available to everyone, the AGPLv3 license needs to required for extensions. 

CiviCRM doesn't require use of a specific repository where a license is automatically applied so licenses must be manually added by the developer creating inconstancies in the approach.

While most extensions are including a license in their info.xml file, not all do...

https://github.com/sciencegalleryderek/com.sciencegallery.mailchimp/blob/master/info.xml#L12
https://github.com/osseed/com.osseed.eventcalendar/blob/master/info.xml

I really have no idea what license the event calendar extension is using.  I'm assuming it's open source because it includes the FullCalendar javascript library which is licensed as MIT, but shouldn't have to assume.  Regardless of the policy, extensions listed at http://civicrm.org/extensions/ should be required to have a license. 

I have other questions about extensions that are related to licensing, but those are more geared more towards developer workflows and promoting collaboration over forking.  I'll post that in another thread.

Stick to public APIs, and you can license however you want without provoking a conflict.

So would the use of hooks trigger the need for APLv3?

My (still not a lawyer) understanding is code that uses APIs or even queries the tables of an AGPL project directly using PHP on the same LAMP stack and wouldn't be considered a derivative work, but when the code is executed by the "parent" project it is considered an improvement or derivative.  It seems like extensions fit that description. 

That being said, there is so little case law regarding this that most projects are simply using a mix of the FSF guidelines and their own policies (which may or may not be 100% legally enforceable).  My views are also largely influenced by how the Drupal community interprets this which may or may not end up being the correct interpretation.