09 June 2009, 21:37

The Mahara project began in mid-2006, as collaborative venture funded by New Zealand's Tertiary Education Commission's e-learning Collaborative Development Fund (eCDF), involving Massey University, Auckland University of Technology, The Open Polytechnic of New Zealand, and Victoria University of Wellington.

Phase II development was managed by Flexible Learning Network with further support from New Zealand's Ministry of Education and the application of Mellon Foundation funds from the Open Polytechnic's winning a 2007 Mellon Award for Technology Collaboration.

Throughout both phases, Catalyst IT has written most of the code for the project and is the maintainers of the Mahara code base. Catalyst manages commits from third parties and ensures that contributions are of a high enough quality to be added to the core.

Significant and ongoing contributions have been made to the project by Catalyst and Flexible Learning outside these initial work phases.

From those foundations, the Mahara project continues to grow in scope and success. We are now starting to see an increase in the number and diversity of code contributions from different parts of the world. This is a sign of a healthy and growing free and open source project.

We are very keen to see this growth sustained but there are certain copyright management and related code management issues that should be discussed with the Mahara community.

Catalyst is committed to keeping its own and other contributions to the project free (as in libre) and willing to make binding commitments to this effect. Similarly, Flexible Learning Network manages the protection of the Mahara trademark and commits to the ongoing future of that trademark being associated with the Mahara free/libre open source project.

The Mahara code is licensed under GNU GPLv3.

As the project grows we need to make sure that:

1. Contributors continue to be attracted to the project and motivated to provide resources to help the project progress. For example, a client of a Mahara Partner may want customisations. Where the code contribution is applicable, we would like a situation where as many organisations as possible feel comfortable and that it is mutually beneficial for them to contribute into the community.
2. Contributors warrant that they are authorised to make the contribution and to licence it. (We need to manage the commit processes to ensure that this is stipulated.)
3. The project needs to be able to assert its rights in the event of blatant Copyright infringement by a third party. This third point is important as it relates to our decision to use the GNU GPL as our preferred licence.

Balancing the requirements of points 1 and 3 could be tricky, as from a legal perspective our advice is that it is easier to bring proceedings in the event of blatant copyright infringement if a single entity were to hold all the copyright. This needs to be weighed against whether this will increase the barriers to community participation.

We therefore need a policy around contributions to the Mahara open source project. There are essentially two options to consider:

Contributor License Agreement (CLA)

A CLA has the following benefits:

(a) It sets out the documentation requirements so that copyright ownership can be proved at a later date if necessary - i.e. a good paper trail.

(b) It provides a warranty from the contributor that they are authorised to make the contribution and licence it (which could be an issue if the contributor is subject to an agreement effectively assigning all intellectual property to another party).

(c) It grants to the project all licences necessary for all possible uses the foundation may wish to make of the derivative code.

(d) It is far less demanding of contributors in terms of process compared to assigning copyright ownership which may be held back by an organisation's lawyers.

A CLA does not assign copyright to the entity. Examples of it in use include Python Software Foundation and MySQL.

Contributor Assignment Agreement (CAA)

In most circumstances, a broad licence in perpetuity (which is often contained in the CLA), will have the same effect as a copyright assignment.  However, there are a few important differences.  The difference between a CAA and a CLA is that in a CAA the contributor assigns all or most of the copyright in the contribution over to the project maintainer.  The project maintainer then licences back to the contributor the licence to exercise all rights associated with the copyright material and the contribution. 

A key benefit of the assignment of copyright over licensing is that where the project maintainer is the single owner of copyright, the project maintainer alone can take legal action to enforce its copyright for blatant infringement.  If the copyright ownership sat with all contributors as well as the project maintainer, this would be very difficult if not impossible to launch legal action for any blatant breaches of copyright.  While many contributors to Open Source projects feel that they may not want to be party to enforcing a breach of copyright, it must be remembered that it would be a breach of copyright to use the source code in a proprietary project without following the terms of the licence.  It is both possible and practicable to enforce this against commercial entities if copyright ownership is under one person or a single entity. The Free Software Foundation, for example, insists on this model if they are to take action on behalf of a project.

A legal opinion from a New Zealand based IP lawyer states there is a second major benefit to having a CAA as opposed to a CLA if the project needs to be re-licensed.  A number of projects encounter problems with their initial license and seek to re-license the project.  Examples include the artistic licence used by the Perl community.  It can be difficult to foresee all the potential requirements of a licence ahead of time, however, simplified ownership structure of the copyright makes relicensing, if necessary, considerably easier. The flipside of this benefit is that some might view this possibility as a barrier to contributing or securing contributions from third parties (e.g. Universities and Partner's clients).

---

Even within the Mahara Governance Group we have some quite divergent views on the pros and cons of each option.  We would like to hear your views on the topic before arriving at any further conclusions. We encourage you to consider what's written here, and have your say by replying to this topic.

Thanks to Rochelle Hume of Paxton-Pennman Et Al for her legal contribution to our deliberations.

Regards

Don Christie (Catalyst IT) and Richard Wyles (Flexible Learning Network)

10 June 2009, 10:17

Hi Richard,

I think I favour the CLA and keeping the contributor demands low.

I know from experience that assigning IP across in my organisation would
be a slow and painful process and we are a heavily pro open source
organisation who actively encourage contributions.

If I was new to the project and had a small contribution to pass on I think
this would discourage me from contributing back to Mahara. This could become
a major barrier for encouraging new contributors. Especially those suspicious
of Catalyst IT/Flexible Learning Network or generally companies from
overseas (i've seen this a lot)

Dan

10 June 2009, 16:23

I agree with Dan: favour the CLA to keep the contributor demans low.

I'd say the Linux model could fit here (I seem to remember it evolved from similar needs). Every contribution has a 'Signed-off-by' line from the author of the contribution (and possibly other intermediate parties in its way to the core code) plus a 'Developers Certificate of Origin' policy (see point '12. Sign your work' in Documentation/SubmittingPatches on any recent kernel source tree)

This allows for the origin of the code to be traced back to the original contributor in case of any legal dispute (copyright infringement, patent litigation, etc.)

Saludos. Iñaki.

10 June 2009, 10:30

This has been discussed in Moodle developers community recently. See the Martin Dougiamas' post at moodle.org. Basically, contributors retain the copyright (or copyleft, to be more precise here) and they publish their work under GNU GPL v3. This helps to protect the project from being re-licensed against the community willing in the future, for example by They-Who-Must-Not-Be-Named, Ltd. and who would buy the single copyright holder. From this point of view, the possibility of re-licensing looks more as a danger than a benefit. And the current process running in Moodle shows that re-licensing is possible if everybody is happy with it.

I can see the benefits of assigning the copyright to a single entity in case of a need to assert the rights. My question is, is there a problem with letting the copyright assigned to the original authors and re-assigning them eventualy in the future in case of a law suit or so? 

Also, there may be a theoretical problem with some countries where copyright can't be re-assigned, can't be assigned to a company abroad, to a company in New Zealand or whatever. For example, the Czech law works with the concept of "authorship" only but the term "copyright" does not exist as a legal term. The authorship can't be re-assigned. If a developer writes a code for a company, there is an agreement where she as an author gives the company an exclusive right to exercise all rights associated with her code.

10 June 2009, 20:43

Hi Richard,

 

Thanks for the invitation to contribute. I’m not sure I’m familiar enough with the challenges to meaningfully comment, primarily because it’s difficult for me to see how someone might meaningfully breach copyright here in a way that compromises Mahara. If someone takes some Mahara code and uses it as the basis for their own proprietary system, well, good luck to them. If someone designs a customization for Mahara and decides not to share it, well, sure, they’re not playing fair – but what is wrong with this? The ongoing commitment of the open source community to Mahara itself need not be threatened in such a case. I would have thought this would be viewed an acceptable risk as far as OS were concerned. The risks of assigning copyright to an organisation seem to me to undermine the very principles Mahara was built under.

 

Is there a concrete example of where copyright would have been useful in an open source project? Where is the precedent here, and what are the real implications of a copyright breach? I need more information on this, apologies in advance for my ignorance!

 

Cheers,

 

Mark.

10 June 2009, 21:11

Dear colleagues

 At the expense of sounding legalistic (I'm not a lawyer), but here are a few questions I might ask first before offering a comment.

1. What was the nature of the original agreement between the NZ TEC and Massey university as lead agent in the development team about ownership.

2. Did Massey university have any special clauses in a contract with the TEC as lead for the original project.

3. Does the NZ Government have an interest in this through its agent, the TEC

4. What if any was the agreement between the development team at Catalyst and Flexible Learning netwok (or Richard Wyles in particular) and the project managers ( the team funded by the TEC).

5 Does the law of NZ apply to Mahara developments.

 

I do not know the answers to these issues, I expect they are easy enough to identify.

Then, not being a lawyer, might I expend a few dollars and ask AJ Park (lawyers specialising in Copyright) what is the best option for the Mahara project. Going to a law firm with a clear set of answers to basic questions like those above would ensure that the cost is containable.

 

Sorry if that is not helpful, but these are fairly basic questions.

 

Andrew Higgins

10 June 2009, 22:23

Hi Andrew,

In response to some of your questions,  everything was handed over to TEC at the conclusion of the project. Massey has no recourse whatsoever. It is also pretty clear in the agreement with TEC that the final product would be handed over to the open source community, so I would be surprised to see any form of TEC preciousness about this emerging. Under the funding agreement Massey agreed to facilitate the development of an open source application within a fixed-term project, an open and shut arrangement. 

I think we should defer to the wisdom from Moodle's perspective (thanks for weighing in, Martin).  Assigning copyright will only complicate things and could lead to proprietisation if the future leadership of that organisation does not remain enlightened re things open source.

Cheers,

Mark. 

10 June 2009, 21:13

Hi Richard -- thanks for allerting me to this thread, and important discussion for any open community.

I have been a little removed from the direct involvement in the Mahara development -- so may not be up to speed in all the issues facing the foundation.

From my perspective as an educator, advocate and user of free software, I think its more important to do the right thing (rather than doing things right from a mechanistic legal perspective.) 

If we go back to the original intent of Copyright under the Statute of Anne -- (which many folk cite as origins of copyright) we see that the Act aimed to promote public rights to copy materials -- hence "copy right"  The intent was to establish an Act for the encouragement of learning in response to the perpetual monopoly held by publishers between the mid 1500s and late 1600s.

From my personal perspective a Contributor Assignment Agreement -- is not necessarily in the spirit of respecting and honouring individual freedoms of code contributors.  The copyleft provisions within the GPL are, in my view, adequate to protect the freedoms of the code and would still provide ample foundation for litigation in the event of "blatant infringement" of copyright. "Blatant infringement"  of the GPL.  is still blatant  irrespective of who owns the copyright ;-)

The difficulty in this type of litigation lies in multiple ownership of code contritutions -- however,  I don't see a strong enough moral base on which to argue a requirement to assign copyright over to a single entity. I think the right thing to do is to respect ownership of copyright as a community asset of the contributors rather than a single owner. 

Hope this helps the team and foundation in doing the right thing :-)

10 June 2009, 21:49

Hi guys,

I can understand where you are coming from wrt to the benefits of a single entity controlling copyright.  Certainly legal proceedings would be easier, and changing the license would be easier in future.  From a lawyer's point of view this makes total sense.

However, I think this is outweighed by the community considerations and the way open source communities generally work:

• People like stability and trust, they don't need the spectre that one entity might "change the license" at some point in the future (this fear is communicated to me frequently, especially by those spreading FUD about open source, so I'm glad I have a good answer to it).
• People like credit - they feel justifiably proud to own part of an application used all over the world.  This in turn increases contributions and commitment from everyone.
  
• People like simplicity. Licensing issues are at best tiresome, and more often just confusing and totally misunderstood.  The less paperwork the better.
  
• People like relationships.  Common goals and shared stakes.

In return, I feel sure that the Mahara community will help fight any battles that need to be fought on behalf of the project that they feel ownership in.  Actual legal proceedings should never be necessary if the community is acting in a coordinated fashion.

I know this from experience: the Moodle community is always putting pressure on those "breaking the rules" (whether actual GPL infringements or just established norms of behaviour) and attempts at commercial forks just faded away.

In a worst-case scanario where a big company took the project and started selling an improved version under a new license, I could imagine easily someone in the community buying a copy of the commercial fork and bringing the new code back to the parent project, no matter what new license they had illegally placed on their version.  Imagine that company trying to take a community to court! 

11 June 2009, 3:25

I would agree with Martin.

 When people create something, they like to see their name up there as being someone who contributed code, a module, and so forth. Its their claim to fame, and recognition of community contribution. Perhaps similar to the "helpful moodler" in moodle.org forums. Its a badge.

In an international market, the rules you will try and fight someone breaching copyright could vary hugely, and has your legal advise taken into account the laws of "random country where rogue company exists" 

 

The changing license type, makes me wonder why has this come up now, have you been considering a change ?  I think that a change in license could promote the "mambo-joomla" type split where they community say "hands off" and take the code and keep developing.

  Just some random thoughts