Loomio
Wed 30 Mar 2016

Status of GPL in Govt software projects

BW
Brent Wood Public Seen by 332

The original draft, in sections 21/22/23 discusses the relevance of the GPL for Govt open software. This thread is to discuss this content & propose alternatives.

TC

Tom Clark Wed 30 Mar 2016

Sections 22 and 23 are troubling. In particular they present an anti-copyleft perspective that is out of place in the document.

BW

Brent Wood Wed 30 Mar 2016

Firstly - my concern:

I find the text, especially in section 23, to be full of "in theory", "could", "potential"... unlike pretty much everywhere else in NZGOAL, this fails to provide a clear guideline, but comes across as if the writer is afraid of something but unable to say what - much like the 1990's attempts to spread FUD about Open Source generally - basically "some nasty things might happen if you do this!" This is inappropriate for a fact based government guideline.

The GPL is probably the most widely used Open Source software licence for a reason - from: http://redmonk.com/sogrady/2014/11/14/open-source-licenses/

"Besides high profile projects such as Linux or MySQL, the GPL has been the overwhelmingly most selected license for years. The last time we examined the Black Duck data in 2012, in fact, the GPL was more popular than the MIT, Artistic, BSD, Apache, MPL and EPL put together."

Somehow this level of use for decades should result in a very clear picture of the ramifications of using it - not "might" or "could" have this result!

So, given the widespread use of the GPL licence, it seems whoever drafted the NZGOAL-SE sections on this had some misgivings, which they have tried to pass on, I suggest unsuccessfully. Here is a place to discuss this...

DL

Dave Lane Wed 30 Mar 2016

Don and I have already mentioned our concern about the portrayal of the GPL to Paul Stone... I wrote this (email excerpt):

I'm a bit concerned, however, regarding the sentiments behind the position "sharealike" copyleft licenses like the GPL. The preference for MIT license as a "permissive, business friendly" license suggests that the gov't wants to create a two-tier system, where businesses can co-opt taxpayer funded FOSS to create forks which are not FOSS. The "permissiveness" is in favour of business interests, not the public interest. This is essentially providing private interests with a publicly funded software commons that they can exploit for their own profit.

That implies that people in LINZ still believe in the "trickledown theory" of economics - that profitable companies are the secret to ongoing prosperity for all of NZ... I think that position could be very compellingly rebutted.

I would argue that the use of the word "permissive" to describe MIT (and other non-copyleft licenses) is loaded. It implicitly defines a perspective - they are "permissive" from the perspective of private businesses. From the perspective of the taxpayer, on the other hand, a "permissive" license is a sharealike license that protects the interests of the citizen and the commons over those of private enterprise. In fact, that's the whole point behind the GPL and other copyleft licenses.

SB

Sam Bonner Wed 30 Mar 2016

Yes, those section in particular, while presumably trying to discuss the differences between copyleft and other FLOSS licenses, seem to use a language designed to spread FUD about copyleft. Examples: "stifling effect", "paternalistic".

SB

Sam Bonner Wed 30 Mar 2016

More generally its very disappointing (to me, at least) that the permissive MIT license has been selected. I'd be keen to understand how they arrived at that license selection (though given the language used around copyleft in the document, it isn't exactly difficult to guess that the authors are either misinformed or have a negative attitude to the freedoms a copyleft license is designed to protect).

DL

Dave Lane Wed 30 Mar 2016

Paul's made it clear that this is a first draft, by one person with one perspective. I think our involvement in the discussion can help to clarify various other perspectives, and that there's room for adaptation... :)

SB

Sam Bonner Wed 30 Mar 2016

Well, I suppose it does raise an interesting question. Obviously I have a viewpoint on permissive vs copyleft licenses, but does NZOSS? Would pushing for a copyleft license by default scare people off and do damage to the cause rather than helping it? I know that's an argument often used by permissive license proponents and its not one I personally buy into, but maybe that's the real reasoning behind the MIT license in this draft?

BW

Brent Wood Wed 30 Mar 2016

Now - a suggestion:

The GPL is the main licence to be genuinely open and permissive - anyone can do anything provided they provide the result back to the project they are building on. Other licences such as MIT effectively state "take what you want, you don't need to contribute anything back."

In many cases these days, code is being made available under multiple licences. In this case, the question seems to be, should anyone reusing taxpayer funded, openly released code be required to contribute something back, or not?

I suggest there should indeed be such an expectation - open source succeeds with give and take - it dies with just take. An open source project survives in the long term because an active and supportive community of developers and users looks after it - and is adequately resourced to do so.

I suggest a commercial business, using such code to improve their product & generate income should indeed be required to help the hand that is feeding it, either by following a GPL licence condition, or in some other way. One approach has been to offer a custom commercial licence to those unwilling or unable to contribute by providing code, by charging a royalty - so when updates and patches are required, commercial users are sharing the cost of maintaining the codebase they are profiting from, instead of effectively receiving a taxpayer subsidy.

So - one approach: the GPL should be the default licence, but those who choose to can opt for a traditional commercial relationship instead to enable code reuse and contribute to the underlying project. It may be that where there is a good case, the alternative licence could be the MIT licence, but this is a case by case exception to a default GPL.

ODN

Open Data NZ Wed 30 Mar 2016

As Dave has said, this is a draft, a starting point. So thank you for this discussion, its really helpful to us, and will aid us significantly in understanding the impacts and counter-arguments. We will also review some of the language.

Please also let us know where you think we are on the right track (if anywhere)...

DL

Dave Lane Wed 30 Mar 2016

Sam, the NZOSS doesn't have an official position on preferred license, but there's definitely a strong undercurrent of "principled" rather than "pragmatic" open source. GPL reflects the former, MIT, the latter. I have a pet maxim: "expedience is the enemy of principle". We're after the principles of openness and enriching the commons, not merely the benefits of a collaborative development model.

TC

Tom Clark Wed 30 Mar 2016

I think it's useful to have a recommended or default license in the document, and to point out alternatives to the default. The current draft does a good job of explaining the choice of the MIT license over the BSD and Apache licenses.

I'd be ok with it if the final draft retained the MIT as the default recommended license provided that the anti-GPL sections of the document were removed. I would be even happier if the GPL were the recommended default. If someone wants to take Crown software and release a proprietary adaptation of it, they should negotiate such a license for themselves.

DC

Don Christie Wed 30 Mar 2016

There really is some great content in your document which will be very welcome by developers and the wider community.

It will be received as a seminal document both in NZ and abroad and its impact will be wider than just the NZ Government. This is probably the first time the NZG has mentioned open source since 2003.

The intention to consult with the wider community is welcome.

Some balance is probably required around the advice on the GPL which seems to be provocative and inaccurate.

Companies such as HP Enterprise and Catalyst have a very strong preference for releasing our code under a GPL licence (assuming that is compatible with any upstream projects).

The reasons we do this are multiple...

  1. It is considered the most sustainable licence and that "guarantee" of openness encourages communities to collaborate and contribute knowing everyone else is doing so on the same footing. HP have arrived at the conclusion the share and share alike licensing creates communities that require less overt governance and are more likely to sustain in the long term. See https://www.youtube.com/watch?v=zxIEDNyZOkA

  2. It is a very well understood and widely used licence. It has been around for decades and from the GPLv3 onwards, it has very clear protection from contributions being encumbered by software patents.

  3. It makes business sense to help ensure we will not be charged proprietary fees in the future for a system we may have helped created. From a tax payer perspective this guaranteed reuse is critical. The NZG could look pretty silly if one week one agency releases code under an MIT licence only for another agency to be charged royalties the next week because the software has been relicensed under a proprietary licence.

There are good case studies of the NZ government sponsoring development where code has been released under a GPL licence and even where new projects have been born and are still going strong many years after that initial investment. This includes Koha (library management), Mahara (e-portfolia/social learning), and Moodle contributions.

I am not saying that the government should use the GPL exclusively but that it should be considered alongside the MIT licence as a strong option with the above considerations take into account.

DS

Danyl Strype Wed 30 Mar 2016

I've been telling anybody who'd listen for some time that we need a software license equivalent to the CreativeCommons license recommendations in NZ GOAL, so first and foremost, I'd like to thank everyone involved in making this happen. Whatever recommendations are made, so long as all recommended licenses are free software licenses (copyleft or not), this is a huge step forwards for software freedom. Secondly, I welcome this chance to give feedback during the formative stages of the recommendations (open government at work!), and I'd like to acknowledge and thank those who made this possible. Thirdly, I'd like to thank those who have already made some illuminating comments here.

In its discussion of CC, NZ Goal attempts to avoid making any judgements about the "best" license - opinions will depend to some degree on one's political-economic outlook - in favour of explaining the legal implications of the available licenses, and which license may be most suitable depending on the objectives of the person or organisation choosing the license. The FSF has attempted something similar with free software licenses in a document called 'How to Choose a License for Your Work' , and if they haven't already, I recommend NZ Goal drafters read both this and their 'Various License and Comments About Them' (keeping in mind that these documents are influenced by the FSF's preference for copyleft).

It should be noted that unlike the CC suite of licenses, neither the Free Software Definition nor the Open Source Definition accept "non-commercial" clauses prohibiting commercial use. As others have noted, the practical difference between companies using government-funded software under copyleft and non-copyleft licenses is whether or not they are obliged to share the source code of modified versions they distribute under the same license terms. Under copyleft they are, under non-copyleft they are not.

The choice of a non-copyleft license (or "permissive") as the default recommendation may be intended to match the choice of the non-copyleft CC-BY as the default CC license. These licenses may be considered to create the lowest barriers to re-use, because they create very simple legal obligations for re-users. This is a reasonable consideration, but as other have explained, it's not the only one at play in software. Particularly because public bodies are unlikely to become paying users of ARR (All Rights Reserved) copyright materials added to CC-BY licensed materials, whereas they are much more likely to become paying users of proprietary software built on an "open core" that was and may still be publicly-funded.

If a non-copyleft license is the preferred recommendation, I would strongly caution against using the term "MIT license". As the FSF says "that term is misleading, since MIT has used many licenses for software." According to their license page, "MIT License" usually refers to either the Expat License, or the X11 License. It should be noted that while both of these licenses are considered GPL-compatible by the FSF, they recommend developers wanting a non-copyleft license use the Apache 2.0, as it has stronger protections against software patents. Software patents are not an issue in NZ law (for now, pending TPP-driven law changes), but they are a big issue in other jurisdictions.

Finally, a lot of the software developed by government is intended to run on a server, instead of on a users computer. It should be noted that the AGPL was written specifically for this kind of software. What makes AGPL different from the standard GPL is that if you allow someone to use a version of an AGPL program running on your server, this counts as "distribution" of the software and triggers the copyleft provision. This is not the case with the standard GPL.

The patent-blocking qualities of Apache 2.0 and the differences between GPL and AGPL are the kinds of practical differences between licenses that need to be accurately explained by NZ GOAL.

RB

Richard Best Thu 31 Mar 2016

Greetings all. As some of you know, I've been closely involved with NZGOAL over the years and, given that involvement, have been assisting LINZ in preparing the NZGOAL Software Extension.

With LINZ's permission, I thought it might help to make a few comments and ask a few questions with a view to explaining certain things and furthering the discussion. Please don't take my comments or questions as representing a government view. My comments and questions are not being vetted and so may not reflect or imply any particular government view. If my comments below reveal any incorrect assumptions, they are mine. Please let me know where you disagree with anything I say.

I now address each of the significant themes raised to date (except for the ongoing maintenance issue addressed elsewhere).

Status of GPL

In drafting the "MIT licence as default" and the "Alternative OSS licensing" principles, there wasn't any intention to discredit the GPL. The history, uptake and value of the GPL are all well understood and, as many will know, the GPL has in fact been used by government agencies.

Paragraphs 22-23 (under the heading "Potential stifling effect of sharealike licensing") were intended to do two things: first, reflect the general point made in paragraph 27(a) of NZGOAL itself that the share-alike obligation may have the adverse effect of stifling creativity and/or economic exploitation by licensees; and second, touch on some of the issues that arise when one wades into debates around the use of propagating licences like the GPL. There was no intention to discredit the GPL.

With the benefit of your comments and hindsight, there is an argument that paragraphs 22-23 are simply not needed. Do you agree?

Preference for non-copyright licence as default over GPL unless GPL-licensing required or there is a compelling reason to use the GPL

Various views have been expressed on this issue. Strypey hits the nail on the head when he says:

"The choice of a non-copyleft license (or “permissive”) as the default recommendation may be intended to match the choice of the non-copyleft CC-BY as the default CC license. These licenses may be considered to create the lowest barriers to re-use, because they create very simple legal obligations for re-users."

This is the main rationale for the draft specifying a non-copyleft licence as the default. (As an aside, it's also consistent with UK agencies who use the Open Government Licence for software, although that had no part to play in suggesting a non-copyleft licence as default.)

However, Strypey and others make some very helpful points which raise an important issue: is the approach taken for non-software works appropriate for software? There appear to be sound arguments that there are significant differences.

Agency feedback has been received to the effect that a more balanced approach between non-copyleft and copyleft licensing would be desirable. For this reason, this issue was already on the radar and the comments you've provided are (in my personal view) very helpful in rounding out the discussion.

Preference for non-copyleft, copyleft or no preference?

Some appear to be OK with a non-copyleft licence as default, others would prefer the GPL to be the default. A third possible option is that there is no single default and that both a specific non-copyleft licence like MIT and the copyleft GPL are recommended for agency use, with the choice between them in each case being for the agency. Various factors could be listed that agencies might like to take into account, bearing in mind the freedoms and obligations of each licence, the agency's circumstances and resourcing, the nature of the software to be released, and so forth.

It would be helpful to hear your thoughts on this third possibility.

Selection of the MIT licence as the non-copyleft licence

At least one person has questioned the choice of MIT as the non-copyleft licence and cautioned against its use. The reason for the caution is the FSF's statement that the term "MIT licence" is misleading given that MIT has used various licences for software.

The rationale for selecting the MIT licence is set out in footnote 6 of the draft NZGOAL Software Extension:

"The MIT licence is considered preferable to the BSD 3-Clause licence (another commonly-used permissive open source software licence) because the MIT licence includes a clearer grant of rights and expressly includes the right to sub-license (the BSD licence does not). Whilst many interpret a right to sub-license as being implicit in the BSD licence, the absence of an express reference to it in the BSD licence could produce uncertainty for users, most notably users who wish to incorporate government-produced code in a work licensed under the GPL. The Free Software Foundation considers the BSD licence to be compatible with the GPL but that must depend on a particular interpretation of the BSD licence wording (see generally A Sinclair “License Profile: BSD” IFOSS Law Review, 2(1) pp. 1-6). The MIT licence doesn’t contain the BSD’s ‘no endorsement’ clause but, in most cases, the law would prevent claims of endorsement without permission anyway. Another common permissive licence, the Apache License 2.0, was not chosen because it is more complex. The Free Software Foundation considers it preferable to the BSD and MIT licences as it deals with patent licensing and prevents ‘patent treachery’. However, in New Zealand the Patents Act 2013 excludes computer programs "as such" from patentable subject matter (and, in any event, historically government agencies have not generally been in the business of applying for software patents). NZGOAL-SE could have recommended its own bespoke permissive licence instead of the MIT licence but that would have contributed to further licence proliferation and exposed developers to a licence they’re not familiar with."

In suggesting the MIT licence, the FSF's comments about the term were taken into account. They were not considered to pose a problem because paragraph 57 reproduces the entire text of what most people consider to be the "MIT licence" and the subsequent guidance on applying the licence is to reproduce the full wording of the licence at the top of each software file or to provide the full licence as part of a separate text file. This approach means there would no doubt as to the wording of the "MIT licence" in question.

It would be helpful to hear people's thoughts on the selection of the MIT licence given the rationale above and my comments on the FSF's statements.

AGPL

Thanks Strypey for your helpful comments on the AGPL. I assume you're referring to the GNU version at http://www.gnu.org/licenses/agpl-3.0.en.html ?

Do others agree that separate coverage of network server software and the GNU AGPL is desirable?

Patent-blocking abilities of Apache 2.0

For the reasons given above as to why the MIT licence was selected, it doesn't seem likely that patent restrictions will be relevant to software that is open sourced licensed by government agencies. For this reason, I'm not sure that discussion of Apache 2.0 is necessary. It's probably desirable to make the guidance as simple as possible for agencies. If Apache 2.0 doesn't need to be discussed, perhaps it shouldn't be.

Your thoughts on this point would be helpful.

Thanks for your time.
Richard

JR

Jason Ryan Thu 31 Mar 2016

A third possible option is that there is no single default and that both a specific non-copyleft licence like MIT and the copyleft GPL are recommended for agency use, with the choice between them in each case being for the agency. Various factors could be listed that agencies might like to take into account, bearing in mind the freedoms and obligations of each licence, the agency's circumstances and resourcing, the nature of the software to be released, and so forth.

Thanks Richard. This seems to be the most practical approach for agencies and would probbaly also be the most convenient in terms of engagements with suppliers and the community.

Also, I strongly support the removal of 22 & 23.

BW

Brent Wood Fri 1 Apr 2016

Hi Richard,

  1. Removing 22/23 improves the document, so +1
  2. Anything formally helping explain this complex situation & encouraging the use of an open source licence is better that the status quo.
  3. I think there can be a recommendation for using either MIT or GPL - clarify the core differences & if an agency prefers this outcome, use this licence - that is what a guideline is for & what NZGOAL already does with the CC licences.
  4. For network & some infrastructural software the AGPL does offer advantages. I'd also raise the issue of LGPL for libraries & other more embedded software - I see some advantages there as well.

And lastly - I don't think raised yet - there is also a GNU Free Documentation Licence - if software is to be released as open source, there is a need for open documentation. There are subtle differences between tech docs & creative works, and the guideline should recommend a licence for manual and documentations associated with software code.

DS

Danyl Strype Thu 21 Apr 2016

Thanks @richardbest for your detailed feedback. It's actually quite refreshing to be in a discussion of free code licensing and feel like the under-informed one for a change :smiley: I hope you don't mind if I reply to your questions a little out of order.

Status of GPL

Like others, I agree that the paragraphs 22-23 can go.

Selection of the MIT licence as the non-copyleft licence

Just out of curiosity, when you say:

what most people consider to be the "MIT licence"

Which license is this? The X11 or the Expat? It's good to know the FSF's caution was taken into account. If you are confident that NZ GOAL-SE encouraging people to call it the "MIT License" will not create confusion, I can live with it.

AGPL

On the subject of AGPL, yes, I was thinking of the GNU AGPLv3 you linked to, which incidentally is the license Loomio is released under. I recommended this license to the Loomio developers to protect them from the risk of Company X setting up a "software-as-a-service", using a version of the Loomio software they modified to add new features, without sharing their code back to the Loomio team. My understanding was and is that because Loomio runs on a server, the copyleft provision of GPLv3 would not be triggered to allow the Loomio developers to benefit from the third party modifications, unless Company X distributed pre-compiled binaries (or possibly source code) of the modified version. In short, "software-as-a-service" allows re-users to avoid honouring the spirit of the GPL. My understanding is that AGPL fixes this bug by specifying that to allow users access to a running version of the software on Company X's server counts as "distribution" triggering copyleft.

If my take on this is correct (and IANAL so it needs checking), then NZ GOAL-SE needs to advise that if developers are releasing "server-side software" (software running on a remote computer and accessed via a network) and they want to be legally guaranteed access to (and re-use of) any modified version of their software offered by third parties as a service, they need to choose AGPL. Otherwise they might as well choose a non-copyleft license.

Patent-blocking abilities of Apache 2.0

On the subject of Apache 2.0, I acknowledge that the changes to the NZ Patent Act mean nobody will be sued for patent infringement in NZ Courts. But open source projects routinely span multiple jurisdictions, many of which do still enforce software patents. My understanding (again IANAL) is that Apache 2.0 protects re-users of the software not only from patent infringement suits originating from the original developer (in cases relevant to NZ GOAL-SE a government agency) but from any third party distributing modified versions. It does this by including a provision that revokes the right to use the original code under the license term, which is triggered by the filing of patent infringement litigation (see here: http://en.swpat.org/wiki/Patent_clauses_in_software_licences#Apache_License_2.0). Like the GPL, it's more complicated because it does a more complicated job.

Again, assuming I haven't got my wires crossed here, imagine a local library in the US starts using (and contributing back to) a piece of software licensed non-copyleft by a public library in NZ. Company Y starts vending a modified version of the software, and files a software patent on some parts of what that software does with the US Patent Office. Company Y then sues the local library in the US for patent violation. Most non-copyleft licenses don't address this, so if the software is licensed under any of those, the library is forced to either a) abandon the software and find an alternative, b) attempt to strike down the patents, or c) start paying Company for their version of the software, all of which would cost money and cause stress. My understanding is that if the software were licensed under Apache 2.0, Company Y would lose all rights to use the original code as soon as they filed, which would make their modifications useless, and most likely invalidate their patents. Company Y would either have to a) write their own software, b) use software under a more "permissive" non-copyleft license to enable their patent trolling or c) stick with the Apache 2.0 licensed software but use a less predatory business model.

LGPL

Brent brings up the question of using LGPL for libraries. Just to clarify, libraries here are defined as pieces of code providing a discrete function or set of functions, which can be called on by other programs (eg code to turn a song into an .MP3 file), not building that lend books ;) TL;DR of the FSF position on the pros and cons of using the LGPL seems to be that using LGPL for a free code library may make it more likely to be used instead of proprietary libraries offering the same functions (and popularity has many benefits), while if a free code library that offers significant new functionality uses GPL, this has resulted in other software choosing to use GPL, increasing the amount of free code available, and its re-use.

Preference for non-copyright licence as default over GPL unless GPL-licensing required or there is a compelling reason to use the GPL

I think the third approach you mention is the way to go. If any one free code license could cover all use cases, I think the vast majority of projects would be using it by now, yet a number of different licenses continue to be popular (as is non-licensing but that's another story). My suggestions would be:
* Explain the practical differences between copyleft and non-copyleft
* GPLv3 as the recommended copyleft license for "client-side applications" (software running on the users computer, whether desktop, laptop, mobile, or otherwise)
* AGPLv3 as the recommended copyleft license for "server-side applications (as defined above)
* Explain the differences between non-copyleft licenses that provide protections against patent threads and those that don't
* Apache 2.0 as the recommended non-copyleft license for protecting against patent threats in other jurisdictions (for reasons given above). If the NZ approach to software patents spreads around the world (we live in hope), then this could be dropped from future revisions. On the other hand, if implementing the TPP results in the NZ government restoring general software patents in NZ, future revisions could recommend Apache 2.0 as the only non-copyleft license
* "MIT License" as the recommended non-copyleft license where patent threats in other jurisdictions isn't considered a significant risk (just to be clear I don't have a strong preference for MIT but your reasoning for choosing it over any of the BSD licenses seems sound)
* Explain the practical differences between licensing a library under GPL (full copyleft), LGPL ("weak copyleft"), or Apache 2.0 (non-copyleft)

CF

Cam Findlay Fri 22 Apr 2016

Well thought out comment @strypey :thumbsup: - I'll take some time to digest this.

If you're up for it, I'd be really interested to see what a decision tree based on your suggestions might look like as a first step of the current draft tree on page 19 of the draft. Is this something you might be able to put together (even in a rough form) and share with us here? :smiley:

DS

Danyl Strype Sun 24 Apr 2016

I have had a go at a decision tree:

1) non-copyleft or copyleft?

non-copyleft: you simply want to make the code available, for any purpose, under very few conditions
* 2) Do you want to take steps to prevent your source code being used as part of the basis for a software patent litigation? (all copyleft licenses recommended below take as strong a stand as they can against software patents )
* yes: Apache 2.0
* not worried: "MIT License" (X11 or Expat) or "BSD License" (Modified or FreeBSD)

copyleft: you want to create a commons that others will draw from and must offer improvements back to if they publish their changes

  • 3) Is the software you wish to release under a copyleft license a:
    • client-side application (programs that run on a desktop, laptop, or mobile device): GNU GPL
    • server-side application (programs that run on a remote server, accessed via a network): GNU AGPL
    • software library (code implementing a function or set of functions usable in other programs)
      • there are few or no other libraries that implement the same functions and you'd like programs to use a copyleft license if they use your library: GNU GPL
      • there are proprietary libraries that implement the same functions, so you don't mind your library being used in proprietary programs, so long as distributed modifications to the library itself are released as copyleft: GNU LGPL

I have also put this in table form in my wiki page of advice for projects releasing code as free software.

TC

Tom Clark Thu 31 Mar 2016

A few things in response to Richard's points:

  1. I agree with the suggestion to remove paragraphs 22 and 23.

  2. If agencies release software under any recognised FOSS license that's a good thing.

  3. For this document to be useful to it's audience it should offer some concrete recommendations, like a default recommended license. The question about whether it should be a copyleft or non-copyleft license is a complicated one and it should be discussed. Personally, I would argue for a copyleft license, but if the final document recommends a non-copyleft document as the default I would still be satisfied.

  4. I agree with the rationale provided for selecting the MIT as a suggested non-copyleft license,

DC

Don Christie Thu 31 Mar 2016

Hi Richard

The preference for MIT runs counter to the advice on licensing for data which is more in line with the share and share alike licenses. I am against picking a default licence as this will simply be the wrong choice in many cases, whatever default is selected.

I think describing the benefits of both types of licences is valid. Then follow the third way. I think you need to be careful about trying to describe pitfalls as this is where there is strong disagreement with the current draft.

Cheers
Don

RB

Richard Best Thu 31 Mar 2016

Tom, thanks for your feedback. Much appreciated.

Don, thanks for yours too. NZGOAL doesn't recommend share-alike licensing for data. CC-BY is the default but CC-BY-SA can be used if that's the agency's preference. It's a choice for the agency. Thanks for your helpful comments on the third approach and the care needed in describing pitfalls. I suspect the simplest approach is to describe what each licence allows and requires, without getting into philosophical debates.

Jason, thanks for your comments too on the third approach and paras 22-23.

DL

Dave Lane Thu 31 Mar 2016

This is an excellent discussion. I also support the removal of 22&23, as they implicitly adopt a "business" rather than "citizen" perspective... the think the latter should always take precedence over the former. For the record, as someone involved heavily in FOSS and CC (disclosure: I'm president of the NZOSS and on the board of CCANZ), I strongly prefer GPL (or, in some cases, AGPL) for software rather than "exploitable" FOSS licenses (I prefer that term over "permissive" - again, a question of "from whose perspective") and CC-By for creative works, because, though they have some similarities, the reuse patterns are quite different, as is the value of reciprocation for society...

DL

Dave Lane Fri 1 Apr 2016

Interesting point regarding documentation, Brent. Not sure if the GNU FDL is still appropriate with the advent of CC (even from RMS' perspective)... but it makes me wonder: do we have a precedent yet for the copyright status of APIs or code-level docs? That's something we probably want to get sorted before there's an Oracle vs. Google over Java situation here in NZ...

CF

Cam Findlay Fri 1 Apr 2016

@davelane @brentwood - Worth starting a separate thread about the documentation issue to keep the current topic on track? It would be interesting to explore.

RB

Richard Best Fri 1 Apr 2016

Thanks Brent. Much appreciated.

I've looked at GNU's documentation licence before. It's not the most elegant or user-friendly of documents.

Sometimes it seems people lump documentation within the scope of the GPL (if they're using the GPL), despite the GPL not being a good fit for documentation. I've seen others use CC licences.

I wonder whether this would work: if software is licensed under the GPL, recommend CC-BY-SA for any accompanying documentation. If software is licensed under MIT, recommend CC-BY (but making it clear that agencies can use CC-BY-SA if they prefer).

My initial feeling is that recommending a non-CC licence for a specific category of literary works could be confusing or make life difficult for both agencies and end users. The latest CC licences are much clearer in my view and more accessible.

RB

Richard Best Fri 1 Apr 2016

Dave, what do you mean by a "code level doc"?

DL

Dave Lane Fri 1 Apr 2016

I suppose ultimately, it's all just API documentation (i.e. for calling library code in other code, as opposed to accessing an API via a socket or network stream).

BW

Brent Wood Fri 1 Apr 2016

My 02c, the can of worms around docs, etc...

Take an interactive website. Runs on FOSS code. Has content as well as code. Content is info & metadata & links to data. An "About" page describes the code, licences etc. A "Help" page provides user level docs about interacting with & driving the facility. Somewhere associated with the code is technical developer level documentation. About 1/3 of the code is (good practice) inline comments & self-documentation. As well as the online help, there is a "How To" PDF you can download.

This is a pretty typical situation: underlying code, inline docs, tech docs, data related to this implementation of the code, user & tech docs for this implementation, user manuals - interactive & printable - with very unclear boundaries. A useful guideline would help agencies work through this mess :-)

Like:
machine readable or executable code is covered by the GPL or MIT software licence
tech docs, user guides, reference manuals are all under CC-BY or CC-BY-SA
content is data or docs - so CC-BY or CC-BY-SA (or even proprietary).

Does that simplistically cover all bases?

& I agree with Cam - put this topic elsewhere so this thread has some hope of resolution!

CF

Cam Findlay Sun 3 Apr 2016

@brentwood or @davelane could you start the documentation discussion thread and perhaps re-post a summary of the above points? :smiley:

CF

Cam Findlay Sun 3 Apr 2016

Back on original topic, I take it by "GPL", the policy is referring specifically to GNU GPL v3? Is there provision for updating this if there are future revisions to that license?

Also, any thoughts on LGPL? In certain situations code is a library/plugin versus a whole application and LGPL might be an option. Could the type of license be determined by the type of code released and the intentions of the author? (Which leads towards the suggestion of no default license and a way to easily select one).

DL

Dave Lane Sun 3 Apr 2016

Good questions, Cam. I normally see people license with "GPL v3 or later", trusting the GNU/FSF to come up with a good responses to new threats to copyleft that emerge over time... Linus Torvalds and some others prefer to sit on GPL v2 for the Linux kernel because he thinks that the GPL v3 is too restrictive to commercial interests (puts the balance too strongly in favour of the user)... That's debatable.

Regarding LGPL, I think it's been used by people in ways that's somewhat ill-suited to its original reason for existence (i.e. a concession to the proprietary status quo, to allow GPL-based OSs to run proprietary applications)... I'm not familiar enough with the specifics of the LGPL to say how it's really an improvement over the MIT license... worth more investigation.

SM

Sam Minnee Tue 5 Apr 2016

One thing I'd like to raise is that if a shift to a copyleft license was incorporated into the document, that some kind of exception or consideration was given to the licensing regime of the project or ecosystem that you are working with.

If GPL licensed contributions to an MIT or BSD licensed project were provided by a government agency, we'd struggle to incorporate them. The reverse, however, isn't true: an MIT-licensed contribution can be incorporated into a GPL licensed project.

In other words: if you're working with an existing open source project, consider using the license of that project, or using MIT in order to be compatible with re-licensing.

I'm not opposed to GPL, although I do tend to prefer MIT/BSD because it avoids this kind of wrinkle.

DC

Don Christie Tue 5 Apr 2016

Hi Sam

When I read the draft I think it made it very clear that if contributing to an existing open source project the licence chosen should be the one that project already has, which is a good thing. If it is not clear enough then it is worth tightening up that advice. I mentioned HP & Catalyst's preference for the GPL for code releases, but in our case, the first rule is to play nicely with upstream projects. Not using their chosen licence is not playing nicely :-)

There may also be contributor agreements that the project would expect to be signed - a hurdle that is worth some legal review in each case.

Not sure what wrinkles you see in the GPL, but rather than thrashing that out, there seems to be a consensus around describing the advantages of both share & share alike and MIT and suggesting that the choice made be the one that best suits the context of what is being achieved.

Cheers
Don

CF

Cam Findlay Wed 13 Apr 2016

@samminnee for a nz govt project, since the GPL-ness only triggers upon redistribution/passing on the files. Using a GPL library or module in a permissively licensed existing project base, where the project code itself a) gets customised and; b) the custom project code (that stitches together the core and modules) is not redistributed, GPL should be ok to make use of. It might be different if the project was for commercial clients building something they intended to package as a distributable product though, then GPL in the module would would indicate the project release as GPL. Seems a situational issue.

You make a good point that it it could be good to make it clear to "play nice" license wise when using an existing open source project and contributing patches or creating libraries that extend that project. For example, SilverStripe CMS is licensed under BSD so might be in keeping with the SilverStripe FOSS community culture to release things under a similar license (in practice we do see mostly, BSD and MIT licensed contributions in that community).

CF

Cam Findlay Wed 13 Apr 2016

As @donchristie mentions, seems we have some interest in exploring some robust triggers of when you would pick either MIT or GPL for new open source releases and offer guidance around this.

I'd be interested in starting a thread/s that unpack both GPL and MIT as to when you would use either in a practical sense for new software releases.

NZGOAL-SE will need to be able to guide a user and help them pick a suitable license without too many hoops (otherwise it may not get use in practice).

DL

Dave Lane Wed 13 Apr 2016

Yup - we don't want NZGOAL-SE to be like the holiday pay legislation (for which no one can give useful advice, it would seem).

CF

Cam Findlay Wed 13 Apr 2016

I've fired up some new threads for us to work out some practical situations of when you'd pick a particular license from the two under proposal in the NZGOAL-SE draft.

To contribute to specific discussions on when you'd pick a particular license see the following two new threads:

When would you pick GPL?

When would you pick MIT?

CF

Cam Findlay started a proposal Thu 14 Apr 2016

Licensing of accompanying documentation Closed Sun 17 Apr 2016

Outcome
by Cam Findlay Wed 26 Apr 2017

Sees there is support for this approach. Since this documentation aspect is not currently mentioned in the policy itself (unless I missed something) I'm wondering if this is again one of those practical guidance related aspects? I may run a follow up poll on this aspect.

Something mentioned in this conversation that I really appreciated was the concept of leveraging the existing NZGOAL recommended CC content licenses for documentation existing in text form, in a separate file/s alongside code in a repository (I'm excluding in-code documentation from this particular point).

I propose that it would be a good idea to consider that if MIT is selected for code, then CC-BY is used for documentation, and if GPL selected for code, CC-BY-SA used for documentation. This would keep selection clear and easy to implement. Further, it makes use of the wider NZGOAL suite of guidance.

Agree - 7
Abstain - 7
Disagree - 7
Block - 7
7 people have voted (17%)
TC

Tom Clark
Agree
Thu 14 Apr 2016

CF

Cam Findlay
Agree
Thu 14 Apr 2016

Reuse of exisiting NZGOAL in this situation makes sense. I'd say it would be a strong suggestion to do this and releasers could still opt to make an alternative decision via NZGOAL if they wanted to do something different with their docs license.

DL

Dave Lane
Agree
Fri 15 Apr 2016

Seems reasonable/tidy, and I don't see any negative ramifications from requiring By-SA (I think that By-NC would be far more problematic, so pleased we're not going there :)).

BW

Brent Wood
Agree
Fri 15 Apr 2016

KB

Keitha Booth
Agree
Fri 15 Apr 2016

BC

Byron Cochrane
Agree
Fri 15 Apr 2016

G

GasparI
Agree
Fri 15 Apr 2016

KB

Keitha Booth Fri 15 Apr 2016

I agree with Cam's recommendation. It makes sense to clarify legal re-use of the documentation at the same time

CF

Cam Findlay Fri 15 Apr 2016

Thanks @keithabooth , would you mind adding your vote back up the top of the page to the right (should be some big thumbs up/down buttons) :thumbsup:

CF

Cam Findlay started a proposal Wed 20 Apr 2016

NZGOAL-SE should recommend a default license Closed Tue 26 Apr 2016

Outcome
by Cam Findlay Wed 26 Apr 2017

It seems there is support for a default (in general) and there is some good arguments to be made for a decision tree also (in the minority). The value of having a default seems to have been cited as preference so that those that my not be well versed in open source licensing can select based on sound recommendation from NZGOAL-SE.

There has been some discussion in this thread about the current draft NZGOAL-SE default license (MIT) and alternative approaches.

Two key alternatives were 1) having the default as copyleft (GPL) and; 2) having both MIT & GPL as options with some attributes or decision tree to pick a starting default (then work through the rest of the release process).

This poll is to get a quick read on whether we feel it important that NZGOAL-SE should recommend a default license and provide guidance on when to pick the alternative.

I'm purposefully not putting forward a particular license (GPL or MIT), as we are looking to understand if having a default in general may be of practical value to public sector people following NZGOAL-SE. Please keep on topic :smiley:

Based on the votes and discussion here I'll look to follow up with further dialogue and polls on the other alternatives :thumbsup:

Thanks.

Agree - 10
Abstain - 10
Disagree - 10
Block - 10
13 people have voted (31%)
DL

Dave Lane
Agree
Wed 20 Apr 2016

I think it's important to give some guidance - I think most entities will use the default, as many won't know much about the options (based on a LOT of past experience).

C

Chris
Agree
Wed 20 Apr 2016

Better to have an option so you can release with caveats, to promote sharing rather than may it an all or nothing sum.

EA

Edward Abraham
Agree
Wed 20 Apr 2016

A clear (well reasoned) recommendation helps everyone. I don't want to have to discuss the ins and outs of MIT versus GPL more than necessary.

SB

Sam Bonner
Agree
Wed 20 Apr 2016

BW

Brent Wood
Agree
Wed 20 Apr 2016

CS

Cameron Shorter
Agree
Wed 20 Apr 2016

The government policy should step up and tackle the hard question of which license to recommend so that time and effort isn't wasted debating and potentially introducing incompatible approaches.

DC

Don Christie
Disagree
Wed 20 Apr 2016

Without knowing what that recommendation would be I find it hard to support this idea. We have had some good clear discussion on the two approaches that could be stated quite clearly.

FT

Finlay Thompson
Agree
Wed 20 Apr 2016

Having a default position will make it a lot easy for smaller projects. I agree with Don though that the specific advice matters. However this proposal is that there should be a recommended license(s).

RE

Rob Elshire
Agree
Wed 20 Apr 2016

TCY

T. Charles Yun
Agree
Wed 20 Apr 2016

i think a default is a good idea. it establishes more than guidance, it sets a position on the fact of assumption of an open license. stating GPL or MIT as option is a supportable. a separate doc could go into details on how/why to pick.

DS

Danyl Strype
Disagree
Thu 21 Apr 2016

For me it's horses for courses. Code license choice is to some extent political (as evidence by the reaction to the GPL critique sections). The best course is to clearly explain the rationale for (and consequences of) choosing each license in a set

CF

Cam Findlay
Abstain
Sun 24 Apr 2016

G

GasparI
Agree
Mon 25 Apr 2016

This makes sense for ease and consistency as most people are not experts in license issues and why copyleft is preferable to serve the community. One alternative (e.g. LGPL) should be included for special cases (e.g. libraries).

CS

Cameron Shorter Wed 20 Apr 2016

Re license selection. There is significant time spent debating pros and cons of license selection. The government policy should step up and tackle the hard question of which license to recommend so that time and effort isn't wasted debating and potentially introducing incompatible approaches. The result would likely be a clear decision tree for agencies to follow.

CF

Cam Findlay Wed 20 Apr 2016

Thanks @cameronshorter, consider letting the group know your position on this by using the voting tool back at the top of the page (you should see some big thumbs up/down etc) :smiley:

EA

Edward Abraham Wed 20 Apr 2016

A bit of an anecdote: we developed a website for MBIE that displays regional information in map and time-series form, see http://webrear.mbie.govt.nz/summary/new-zealand. We are wanting to open source the framework so that other data sets can be displayed in the same way. MBIE have indicated to us that a GPL licence would be their preference. I think this is primarily so that other developments get contributed back to the project.

CF

Cam Findlay Wed 20 Apr 2016

This could make a good additional to the thread on "when you would pick GPL", would you mind cross-posting there @edwardabraham ?

EA

Edward Abraham Wed 20 Apr 2016

I will see if I can find out more for you about the current status of the discussiins around this ...

CF

Cam Findlay Wed 20 Apr 2016

Thanks, Only as long as it's public knowledge @edwardabraham and not anything in confidence please. Keep in mind the purpose of the consultation process we're working through together here :smiley:

On another note, when you mention "other developments get contributed back to the project" in your story about the mapping code, keep in mind that the share-a-like clause of GPL only comes into play should a modified copy of the code be redistributed. It doesn't enforce contributions back to the original project per say, which is a common misconception of GPL.

DC

Don Christie Wed 20 Apr 2016

Given the consensus and experience in this discussion seems to favour GPL does that mean dropping MIT as the recommended licence?

RE

Rob Elshire Wed 20 Apr 2016

Having a default license makes good sense to me. As others have said, it makes things easier in (especially) smaller projects. Regardless of which license is the default, the SE should give clear reasoning behind choosing a license.

DC

Don Christie Thu 21 Apr 2016

Save me from "easy", please. It usually doesn't mean "right". As our mothers surely told us all.

So, let's get this right and clear and avoid easy for easy sake.

RE

Rob Elshire Thu 21 Apr 2016

Point taken. What, in your view, would right and clear in this context look like?

CS

Cameron Shorter Sat 23 Apr 2016

Re license selection, the Australian government licensing recommendations for Open Data includes a recommendation on software licensing. I suggest it would be wise to align NZ recommendations with those of other Governments to facilitate international compatibility of policies.
http://www.ausgoal.gov.au/BSD-and-Other-Software-Licences

Quoting:
"If your organisation is publishing software developed without the inclusion of software from any external source, AusGOAL recommends the BSD 3-Clause Software Licence. It provides permissions akin to the CC Attribution Licence, and being one of the Open Software Foundation recommended licences, is well recognised within the open software community. Software licensed under the BSD Licence can be incorporated onto other open source projects, including those licensed under the GPL and Apache Licences. However, GPL licensed software cannot be incorporated into software licensed under the BSD Licence."
"If your organisation is publishing software that incorporates elements from other open source software projects, such as a project licensed under a GPL Licence, AusGOAL recommends application of the same licence under which you obtained third party code."

DC

Don Christie Sun 24 Apr 2016

Hi

I understand the logic but I believe it is flawed. As we have discussed elsewhere the original licence of an open source work is important. It seems odd to have a document recommending open sourcing software only to do so in a manner that allows it to be closed off immediately.

I think Australia have got this advice wrong...just as they did with their approach to the Common Web Platform. NZ did a better job there (not just because they chose Silverstripe :-)) but because they kept supplier participation very open and so acceptance has been wider deeper and more interesting than in Aussie.

So goes for recommending a licence. If you want to go down that route then in this case it really has to be a GPL approach. Otherwise you risk minimising the profound impact this policy and advice could have in government shared use of IT in NZ.

Cheers
Don

CS

Cameron Shorter Sat 23 Apr 2016

PS, I suggest also reaching out the the author behind Australian Open Licensing, Baden Appleyard,
http://www.ausgoal.gov.au/contact-us

KB

Keitha Booth Sat 23 Apr 2016

NZGOAL built on initial AGILF work and AUSGOAL picked up much of NZGOAL. So each has taken from the other. It may be now our turn to take the lead with respect to software licensing. Certainly consider AUSGOAL recommendations seriously but independently.

DS

Danyl Strype Sun 24 Apr 2016

Just to throw another cat among the Pidgeons, today I stumbled upon another license for server-side software. The Common Public Attribution License](https://www.socialtext.net/open/cpal_faq) is similar to the GNU AGPL, in that in both cases the deployment of the software as a network service triggers the copyleft provision (but with slightly different mechanisms). The difference is that the CPAL also obliges organisations using CPAL-licensed software as a network service to put some kind of "powered by [insert software name here]" badge on their user interface.

That could add another branch to the decision tree, under server-side software, asking whether the code releaser want the "powered by" badge when their software is deployed (CAPL) or don't case (AGPL).

CS

Cameron Shorter Sun 24 Apr 2016

I agree with Keitha Booth, certainly consider AUSGOAL recommendations seriously but independently. I am Australian and hope to see this New Zealand document "get it right" and for Australia to follow suite.

Apache has been discussed as a possible license selection. I strongly encourage against Apache, as "it does not require you to include the source of the software". http://www.apache.org/foundation/license-faq.html#WhatDoesItMEAN I.e. Government could contract a company to write Widget X under an Apache license, and the company could deliver the widget as binaries without providing source, which is contrary to the Government's best interest.

Don Cristie, while I like the GPL license and personally would be impressed to see governments recommending it as a default position, the business logic which resulting in NZGOAL recommending CC-By for Data would likely be applicable for Software, resulting in the selection of a permissive license such as BSD. A GPL license is very prescriptive of the business models it imposes upon the NZ Software Industry. I've looked quickly, but can't seem to locate NZGOAL's justification for selecting CC-By for data. I suggest it would be useful to reference it.

Srypey, regarding your proposed decision tree, I think it is missing an statement on what NZ Government considers to be in the best interest of NZ Government, backed by solid reasoning. We here are Open Source advocates, and even we are divided in our opinion on what license to select. This Open Source policy document should be making it easier for government officials to select a license.

I suggest decision tree should be: If follow license convention of the open source project. If select based upon .

DC

Don Christie Sun 24 Apr 2016

Hi Cameron

In your reply to me you are already making assumptions about who will maximise the use of the software and why it might be released in the first place. I am keen to avoid that hence my opposition to a single licence recommendation.

You said - "A GPL license is very prescriptive of the business models it imposes upon the NZ Software Industry"...

This simply isn't the case. There are a myriad of ways businesses have been built around GPL based software. But what your approach risks doing is minimising the value government gets from sharing its software. That is a concern to me as a tax payer as well.

Cheers
don

DS

Danyl Strype Mon 25 Apr 2016

I strongly encourage against Apache, as "it does not require you to include the source of the software".

None of the non-copyleft licenses require sharing of source code, certainly not any of the licenses commonly referred to as the "MIT License" or "BSD License". This is pretty much the essential distinction between copyleft and non-copyleft licenses! This is the kind of difference I think NZ GOAL-SE should help to clarify, rather than being overly prescriptive about license choice.

the company could deliver the widget as binaries without providing source

While I would prefer to see public agencies using copyleft licenses, with a non-copyleft license, the requirement that source code be delivered to the contracting agency (and/or a public-facing repository as discussed elsewhere) could (and by default should) be written into the contract. Also, as the Koha/ LibLime debacle illustrates, control of any trademarks relating to the software name and logos by the contracting agency (or another vendor-neutral stewardship body) should also be written into the contract.

We here are Open Source advocates, and even we are divided in our opinion on what license to select.

This is why it seems unlikely that we can arrive at one default license to recommend for all use cases. There are good reasons that each of the different types of license are used, and this is what I've tried to illustrate in my decision tree. Keep in mind I supplied this tree in response to a request from @camfindlay1 , I'm not proposing it as a replacement for the entire draft of NZ GOAL-SE ;)

CF

Cam Findlay Sun 24 Apr 2016

For those that have so far responded in the affirmative in the poll for the consideration of a default licence (regardless of copyleft/permissive angles), would it be acceptable to you to have instead a quick qualifying decision tree (max 1-2 questions) that brings the user/developer releasing the software to an initial default? They would then work through the rest of the decision tree from there already proposed in the draft (some alterations might be required once we review implications of this kind of change). I may run this as a follow up poll later this week after some dialogue.

My thoughts here are that:

I agree there is value in clear guidance that a default might give the user of the policy and I think a short decision tree could perhaps offer that same value (that is, brining the policy user that my not know the ins and outs of copyright law and open source licensing to a starting default quickly ). I'd like to see these questions in plain English and watch out for technical jargon.

This would maintain the spirit of the wider NZGOAL framework, that of giving guidance for the release of copyright materials and when to use attribution and share-a-like aspects of licensing.

For NZGOAL proper (the policy for content and data not software that NZGOAL-SE extends), it seems that 2 qualifying questions are asked before putting forward CC-BY as the default (granted these are based around whether the agency has the copyright to be able to release the work). However keep in mind NZGOAL proper does set out a principle of "CC-BY as default".

As a user and developer of FOSS, I'm a fan of both MIT, GPL and a host of other licenses. However am in a privileged position of having some understanding of copyright law and FOSS licenses from experience and use. Others may not have this and that should not exclude them from making practical use of NZGOAL-SE.

It would be nice to find common ground here to help move the policy toward a place where it get the best outcomes for government sharing code and for the wider public reuse (both citizens and commercial reuse). :smiley:

Also just like to say, I've been impressed with the conversations over the past few weeks and there are some great constructive points and things to consider heading toward revisions of NZGOAL-SE. Keep them coming. :nz:

DS

Danyl Strype Mon 25 Apr 2016

I think a short decision tree could perhaps offer that same value

I agree, and even better if the decision tree could be visualized in the same way the decision tree for choosing a CC license is visualized in the CC license chooser.

CF

Cam Findlay Tue 26 Apr 2016

Let's get it working on paper first ;)

DL

Dave Lane Mon 25 Apr 2016

I'd like us to select a copyleft license (GPLv3/AGPL) as the default license, but deferring to upstream licenses for derivative projects. The purpose being that the interest of the citizens/taxpayers are prioritised.

CF

Cam Findlay Mon 25 Apr 2016

Updated poll given that 25th April is a public holiday in NZ.

CF

Cam Findlay started a proposal Tue 26 Apr 2016

It would be acceptable to have a short, initial decision tree (max. 1-2 questions) that guides the policy user to a starting default license. Closed Sun 1 May 2016

Agreement here means:
- You'd find it acceptable and see value in having an initial short decision tree to arrive as a starting default license (even if you voted previously for a single default).
- You'd be ok if the two license starting points could be GPL or MIT based on the short decision tree (for the reasons given below).
- Addition license options could then be sought once a policy user has a starting default and this would be in the form of guidance notes outside NZGOAL-SE (for the reasons given below).

Reasoning

In the previous poll, a majority voted towards considering a default license. A number of people mentioned the value was around ensuring all users of the policy could be guided to a workable license (the single default, unless exceptions apply).

I'm proposing here (and this was echoed in past dialogue here on Loomio) that the same value may be realised by providing a well through out, plain English, short decision tree to guide any user of NZGOAL-SE to an initial default license. The two licenses put forward as possible starting points once answering 1-2 questions would be GPL or MIT. Logic here is that there has been well researched recommendations in the draft already (MIT and GPL) and robust conversations here mostly around GPL.

Once a starting default is arrived at, the user would then proceed through the rest of the proposed release process (which may offer opportunity for the policy user to consider alternative licenses if they wish to pursue that).

I'm conscious that the more licenses (LGPL, AGPL, Apache and so on) in NZGOAL-SE, the more complex it becomes for the average policy user to understand the policy and actually bother using it to release code. I'm hoping to avoid a "too hard basket" while having something such as further guidance notes on a wider range of options available for those that want to venture towards further options for their unique situation (should GPL or MIT not be fit for the purpose they have).

I'll look at raise another thread to discuss how these questions might be framed and cover. :smiley:

Agree - 4
Abstain - 4
Disagree - 4
Block - 4
5 people have voted (12%)
CF

Cam Findlay
Abstain
Wed 27 Apr 2016

Looking forward to hearing everyones thoughts.

DS

Danyl Strype
Agree
Wed 27 Apr 2016

A *se*t of defaults, one for each common use case, sounds like a win-win. To me this is infintely preferable to a Highlander style "there can be only one" sword battle over one default, between the copylefters and non-copylefters ;)

DS

Danyl Strype
Agree
Wed 27 Apr 2016

A *se*t of defaults, one for each common use case, sounds like a win-win to me. This is infintely preferable to a Highlander style "there can be only one" sword battle over one default, between the copylefters and non-copylefters ;)

FT

Finlay Thompson
Agree
Thu 28 Apr 2016

Officially mandated guidance will make discussions much easier.
The range, and breadth, of the "which license" discussions show the value in having a guidance position.
Those discussions are unhelpful when you want to get a contract signed up.

RE

Rob Elshire
Agree
Thu 28 Apr 2016

A path to assist in making the decision will be very helpful to get to implementation. It will also lessen the possibility of the whole thing being put in the too hard basket where nothing is done.

G

GasparI
Agree
Thu 28 Apr 2016

e.g. GPL / LGPL - some guidance is preffered.

DC

Don Christie Wed 27 Apr 2016

Hi

Just a quick note to say I appreciate all the thought and good work
going into this discussion. It is very wide ranging and positive.

I am however struggling to keep up being overseas and on leave. I am
sure you will all arrive at a positive outcome but if I haven't voted or
commented it doesn't mean I don't care :-)

Cheers
Don

CF

Cam Findlay Wed 27 Apr 2016

Thanks for your input so far @donchristie - some excellent debate on key sections :thumbsup:

CF

Cam Findlay Thu 28 Apr 2016

I'll keep this poll open til the end of the consultation period :thumbsup:

DS

Danyl Strype Fri 29 Apr 2016

Just to clarify my position statement on the 'decision tree' proposal, I agree that having to choose between the long list of licenses certified by the FSF and OSI would be hugely intimidating, to decision-makers who are not intimately familiar with both the technical and legal issues they raise. @robelshire is right that this currently creates a high risk of "too hard basket", and I think we all agree that one thing NZ GOAL-SE needs to do is simplify this decision. As I've argued, I think the best way to do this is to break the licenses down into categories (eg copyleft for client, copyleft for server, non-copyleft with and without patent immunization), explain the differences in lay language that assumes no prior knowledge of free code or open source jargon, and recommend a default for each category.