Fri 15 Apr 2016

Code forking (section 29-30)

Cam Findlay Public Seen by 314

Reading over the section 29 and 30, I think what is being discussed here is avoiding diverging forks and reads like "forking is bad". As someone that works in open source code daily, my understanding of the term "fork" is a positive thing. I can take a fork (a copy of the code) and make my changes without having ask and then from my fork offer code back to the original project (after discussion of my feature change with the original maintainer of course!).

I think that 1) perhaps a better phrase than "Code forking" for this section might make sense (any idea?) and; 2) this sections purpose seems to be about code contributions back to existing open source projects and; 3) this section is trying to guide agencies to use the canonical versions of code repositories rather than diverging forks of released open source projects.

I'd love to hear some comments around this. :thumbsup:


Cam Findlay Fri 15 Apr 2016

This section might also cover what the license/sub-license situation is when someone either submits or accepts code contributions into release government open source projects.

If someone makes a fork of a code repository with an existing license then that license applies to that fork or copy of the code. If I then write some new code on top of this, I'd be the first owner of the copyright of that new code.

Then I offer that new code back to the original project from where I took my fork from, am I actually offering that back under the same license of the original code repository OR does my bundle of rights under NZ Copyright Act still apply in tact (not licensed)?

In the spirit of open source, I'd hope that the intention is that the contributor is offering open source licensed code back, however legally I'm not sure how this works. I'd also hope that some sort of complex rights assignment process wasn't involved as I can see this working against accepting fixes from the public into govt code (a benefit of open source code).

Would be great if anyone knows the finer points here to chime in. :question:


Don Christie Fri 15 Apr 2016


1st rule, which I think was covered in the draft, if you are releasing code back to the project, new or otherwise, use the same open source licence as the project, regardless of your preference. Catalyst prefers the GPL but we are delighted to be able to contribute BSD licensed code upstream to the likes of OpenStack and Silverstripe. And why not, both platforms have given us great value.

The GPL is clear on modifications. You own the copyright but if you you have simply modified an existing program you and you chose to give it to someone else you need to give it to them under the GPL licence.

If you have developed something new (like a Drupal module or plugin), you get to decide what licences to use. You can release code under multiple licences proprietary and open source. That's what Alfresco and other projects to.

In this example, the Customs plugin could have been released under any licence. But Totara is GPL (based on Moodle) so it would have been a bit shit to release under a different licence.


What many projects ask contributors to do is sign a contributor agreement. These cover the fact that you really do have the right to contribute code and that you waive any patents you have that may cover your code. Some CAs also ask you to assign copyright to the governing body. The latter type do this for 2 reasons. Firstly it is easier to defend the entire work against licence infringers and secondly so that they can do the multi-licence thing. Have an open source "community" edition and a proprietary version as well.



Cam Findlay Mon 18 Apr 2016

What I'm drawing from above comment is that for a government released FOSS project, contributions back from the public might be easier to manage if the project was GPL. As if I modify the code and offer a patch back it would be under GPL too so the copyright bundle of rights licensing aspect would then be clear. The author retains the copyright and the code would be offered back under GPL for further redistribution.

I'm unclear (personally) how this works in the MIT situation (hence my dialogue here to get some perspectives and input from wider community experience). If for example, I accept the original MIT license of a codebase, then I modify it with new code, my new code would need to be itself licensed in a way to offer it back as a patch to the original MIT licensed project. This could be complex and a blocker for others contributing into released government FOSS projects. In this case would guidance be required here?

Additionally, @donchristie I think we are on the same page about respecting the license of already released FOSS projects and communities :smiley: .

Further, guidance on a Contributor Licensing Agreement (CLA) would be useful, in particular assuring the contributor actually has the copyright in order to contribute the code. This could reside either in a set of additional Guidance notes (as has been raise in other threads) or as a suggested inclusion in the NZGOAL-SE (at this point unsure which way would be best so up for discussion).

Has anyone got other comments around the topics of CLAs or forking of code as a positive or an undesirable thing or the legal aspects of offering code contributions?


Cam Findlay started a proposal Thu 28 Apr 2016

Principles about the licensing aspects of contributions and Contributor License Agreements should be included in NZGOAL-SE Closed Sun 1 May 2016

NZGOAL-SE is all about dealing with licensing. One aspect of licensing that I think needs to be addressed in the policy itself is that of dealing with how licensing works when a member of the public or another government agency staff member makes a contribution to a project once it has been released on open source terms.

I don't think it's currently clear in the wording of the draft. There is mention if modifying the code (presumably in a copy of it) to use the existing licensing from the original project, however raising a pull request (a proposal of a fix/improvement to code) might be on the original code repository not a copy.

This proposal suggests that some principles about how you might deal with considering contributions to projects once released may have a place in NZGOAL-SE in particular:

1) Projects should include a README or CONTRIBUTING file that explains how contributions will be incorporated into the code base and under what terms.

2) A clear statement should be included in the above file about copyright assignment. Does the contributor retain copyright and license their contribution to the project OR does the contributor assign copyright to the project maintainer and in return, gain the bundle of rights to use/modify/redistribute under the license already in the project? When would you chose either approach or should one be the recommended?

3) Guidance on when a Contributor Licensing Agreement (CLA) should be signed by a contributor (guidance notes could explain how to do this and the when and why should be in the policy).

Agree - 1
Abstain - 1
Disagree - 1
Block - 1
1 people have voted (2%)

Cam Findlay
Thu 28 Apr 2016

I'd be keen to see something along these lines (even just a set of principles and then the rest in guidance notes).


Danyl Strype Fri 29 Apr 2016

Through all of these, discussions, valuable as they are, I keep thinking we're all talking somewhat in the abstract. This is why I've brought up Koha a couple of times, as it's one I've read a bit about, but I am here as a software freedom activist, I can't comment from an active developer perspective. So, it's great to see @donchristie mention the Totara example, and more such case studies from participants who are developers would really help to ground the discussion.

One case study I can comment on as a community developer (not a software developer) is Indymedia, the network of open-publishing, activist news websites founded in 1999. Benjamin Mako Hill (an Indymedia techs also involved with Debian and the FSF) wrote a good article called 'Software (,) Politics and Indymedia' about the open source development dynamics that drove Indymedia's multiple CMS projects. It summarizes the way that Active, the original CMS software used in Indymedia, was forked and adapted into eight different projects, which shared a very similar user interface, with totally different things going on under the hood.

He quotes the Jargon File on the meaning of a 'fork':

“what occurs when two (or more) versions of a software package’s source code are being developed in parallel which once shared a common code base, and these multiple versions of the source code have irreconcilable differences between them.

Of course, this was all written pre-GIT, and @camfindlay1 's positive understanding of forking reflects changes in practice that have been made possible by the radially different way GIT works, compared to previous versioning systems. Before GIT, merging versions that had wandered off in different directions was at best painfully tedious, and at worst, outright impossible. Beyond a certain point forking became irreversible, and overly fragmented projects were at risking of dying, even though there may still be many developers working on different forks and plenty of users keen for new versions. Because of this, open source projects tended to discourage forking unless there was a very good reason, and instead allowed developers space to scratch their own itch by having complex versioning conventions with things like stable and testing branches (as Debian still does).

TL;DR what 'forking' means by default will tend to depend on how long the developer interpreting it has been in the game. I think confusion can be avoided though, as long as NZ GOAL-SE has one phrase for GIT-style forking, and one for divergent forking in the older Jargon File sense, defines them in the document, and uses them consistently.


Danyl Strype Sat 30 Apr 2016

Just a note on CLAs since you brought them up in the proposal (which I agree with BTW but it closed before I managed to indicate that ;) If you're using a copyleft license, it's not as crucial, because just by modifying and distributing your code they're licensing it under the original license. If you're using a non-copyleft license a CLA is now considered essential to make sure the contributor is actually licensing their code under the original license. This protects the project from litigation trolls somehow acquiring copyright ownership over some part of the code and using it to extract money from the project, or more commonly, end users of the software (eg the SCO case against Linux). It also helps protect the project legally if someone has deceptively submitted code they don't hold the copyright on (and its not under a compatible free code license).

As for copyright assignment, one argument for this is that you can only assert a copyright claim over code when you own the copyright, but if the government holds the copyright over the core code of a package, just enforcing that would usually be enough to school anyone violating the license. That presumes the developers are government employees who sign away copyrights on what they do at work as part of their employment contracts (don't know how common this is in NZ public service), or contractors who sign the copyright over the to the government as part of the commissioning contract (which arguably would have been better in the case of Koha). An argument against it is that it risks future managers of the stewardship body changing to a proprietary license (see the thread on "open core" business strategies), but this can be dealt with by a clause in the CLA that says any version of the contributors code must always be licensed under a free code license, or even specifying what kind of license (eg copyleft or non-copyleft) or even which license (with an 'or later' condition that covers what should happen if that licenses was ever retired).

There is a mix of practices in open source communities around copyright ownership, with some projects that don't require copyright assignment:

... and some projects that do require copyright assignment


Don Christie Mon 16 May 2016


I am not a developer or a user of github...can I see a version of the
document as it stands right now?



Cam Findlay Mon 16 May 2016

Hi @donchristie you can read the human readable version of the current state at:


Note: the review and release section is still to come (though the revised tree is up).


Don Christie Mon 16 May 2016


Thanks Cam. I presume this link:


is the one to follow?



Cam Findlay Mon 16 May 2016

@donchristie see https://www.loomio.org/d/iqPA14xe (splitting this discussion off to separate thread)