Sat 30 Apr 2016

Adaptions (para. 19) should cover using same license as adapted project.

Cam Findlay Public Seen by 293

This section could include explicitly that if adaptions are made to existing open source software that it should be licensed under the same license as the original code base or one in keeping with that particular open source ecosystems community norms recommended in NZGOAL-SE. I'm not sure if this was explicitly mentioned in other sections of NZGOAL-SE draft?

For example, a government agency releasing a SilverStripe CMS module could use BSD or MIT (SilverStripe CMS is originally under BSD). MIT's "permissiveness" fits in with the original projects BSD origin if the agency wanted to keep tight to NZGOAL-SE. Same deal if adapting something like Moodle (GPL v3) the Moodle community would expect GPL adaptions back.


Cam Findlay Sat 30 Apr 2016

This could actually be a very early question in the decision tree "Are you adapting or releasing code that interacts with an existing FOSS project?" - YES -> "Release under the same license as the existing projects code base" END OF TREE.


Danyl Strype Sun 1 May 2016

It would be really interesting to get some metrics on how many projects come into this category (modifying existing project), and how often entirely new software is (or could be) released by NZ govt as open source projects.


Jason Ryan Wed 4 May 2016

My experience is that government almost always adapts or uses an exisiting project, and even when they do build something it is using a framework or platform that has a FOSS license. It makes sense both practically and philosophically to use the project or framework's existing license. It is also the Right Thing to do...


Dave Lane Wed 4 May 2016

Yes, that's my experience, as well. See, for example, CKAN, Drupal, SilverStripe, etc.


Danyl Strype Wed 4 May 2016

If the answer to the question "is the new code modifying or building on top of an existing open source project" is always "yes", is "use the same license as the upstream package" the only piece of advice NZ GOAL-SE actually needs to give? This advice would make the document very simple to understand and follow, and would cover both:
1) situations where there is a legal obligation to share the modifications under the same license. This is case whenever copyleft code is modified and distributed (keeping in mind the distribution conditions that trigger the copyleft condition in each license)
2) situations where the copyright owner has the freedom to choose a license, but using the same license governing the upstream package reduces complications for the its maintainers, as well as re-distributors and re-users. This is the case when:
* non-copyleft code is modified
* copyleft code is modified and distributed in ways that don't trigger the copyleft clause (eg modified GPL software used on a server without distributing binaries or source code)

* a component is built from scratch to work in combination with an existing free code package (eg a module or plug-in)

If a government department was proposing to release code created from scratch, for in-house use, they are effectively creating an entirely new open source project, which would require advice on an awful lot more than licensing. If this is unlikely to happen in practice, because government is not in the business of software development, does NZ GOAL-SE need the much more complicated decision tree about choosing a license for new software at all?