Replies: 34 comments
-
|
Mike, feel free to add content and we’ll approve! Great points.
… Le 21 oct. 2017 à 13:02, Mike Gifford ***@***.***> a écrit :
I like where this is going. I should have said this earlier.
I do think that with the Open Source Code page it would make sense to be more specific. I would like to see these two points about code released by the government:
The government will try to be consistent with the choice of license of the open source software project that it is using to ensure reuse. This will help build adoption within the broader community.
When the government is releasing new code that is unrelated to an existing project it will be released under the MIT (or choose another pervasive license).
I think this would give people an important default when making decisions.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Beta Was this translation helpful? Give feedback.
-
The problem with the government releasing under MIT is that some bigger commercial company can easily port this publicly available code and turn into something commercial. I'd argue that code released by Governments should be under some form of GPL license. I think it's only fair that if you use and benefit of free and open source software that you contribute back whenever you make modifications to the code. |
Beta Was this translation helpful? Give feedback.
-
|
I have to say @ARastogi19 that I do love the viral nature of the #GPLv2. There are folks like @RussellMcOrmond, @mcr & Michael Geist who can go on at great lengths about GPLv2 vs GPLv3. That said, the USA defaults to Public Domain which is even more pervasive than the MIT. I think that's a bit far as attribution is important I feel. By default, all code written by my company is licensed under the GPLv2 & all documentation is under Creative Commons — Attribution-ShareAlike 2.0 Canada. There is also the option of dual licensing which has been leveraged in the past with projects that fell under Crown Copyright. |
Beta Was this translation helpful? Give feedback.
-
|
I'd caution against spending too much time arguing over MIT vs GPL, before working through the logistics of actually 'HOW' to get approval to release code. That being said, I'm not sure how enabling the Canadian private sector to commercialize technology is an issue. If enough people are willing to contribute, the MIT version succeeds. If the commercial partner is able to improve such that people are willing to pay, then it's a win-win. MIT appears to be the most common license in use from various analysis I've seen and is what we chose recently in our open source release. |
Beta Was this translation helpful? Give feedback.
-
Just curious who will be doing the approvals? Is that group/groups identified yet? What will be presented to approve? The reason I ask in because I am sure not everyone likes or has the expertise to read the code. I'm new to this paper/initiative but very interested so sorry if that's already discussed somewhere else. |
Beta Was this translation helpful? Give feedback.
-
|
@mgifford The government has had a long history of gifting the patents and copyright of work paid for by taxpayers to the private sector, under the outdated notion that granting exclusivity to one entity allowed for better follow-on economic benefits than enabling the works to be used throughout the entire economy. This could be a great transition. While copyleft has been a good tool to keep public benefits public, so would having government agencies get past some of the outdated thinking on exclusive rights. If the government can stop abusing copyright and patents to do things which are more appropriately a matter of trademark (authoritative information/etc), privacy and other laws, this would be a major step forward. Ultimately the government should abolish crown copyright entirely, but go beyond what the US did as their works are only in the public domain within the USA --- US government agencies are attempting to claim exclusivity in other countries. Note: Along with government employees we need to deal with agreements with consultants. I had to put up a fight during contract negotiations with IBM and Fujutsu when working through them on contract with Agriculture Canada so that I or the government retained copyright on my work and that I was legally able to release my work as FLOSS. Releasing FLOSS was the purpose of my participation, and IBM/Fujitsu wanted to deny public licensing on this publicly funded work. |
Beta Was this translation helpful? Give feedback.
-
|
This section currently does not explain the practical differences between the demand-side perspective of The Free Software Definition (i.e. user freedoms), and the supply-side perspective of The Open Source Software Definition (i.e. developer principles). Following is the summary from our website. Joseph Potvin, Executive Director, Xalgorithms Foundation Demand-Side Perspective The Free Software Definition: A computer program is distributed free/libre when anyone who obtains it retains the following freedoms:
Supply-Side Perspective The Open Source Software Definition: A computer program is distributed open source when everyone distributing it abides by the following principles:
Isn’t “open source” always “free/libre”? No. Permissive licenses such as those known as “MIT” and “Apache” are open source, but not free/libre. Programming code under these licenses can be re-licensed by anyone directly or as derivative works under a restrictive license, which means that free/libre terms and conditions are not in force. The open source hybrid “Eclipse Pubic License” allows its open source code to be intermingled with code under restrictive licensing. So a mixed package under Eclipse does not meet free/libre terms and conditions. The various “GNU” licenses are both free/libre AND open source. Programming code under a GNU software license may only be intermingled and distributed with code under other free/libre/open licenses. These licences are one-way compatible with permissive licences like MIT and Apache, meaning that code under open source licences can be re-licensed and distributed under the free/libre/open GNU licenses. Most of the global free/libre and open source market uses GNU licenses. Therefore what is colloquially called “open source” software is usually “free/libre/open source” software. That overlap can lead to some confusion, but it’s helpful to be clear in our language about these terms of trade over intellectual rights and responsibilities. There’s no need to dwell on these details if they distract from the purpose at hand. Suffice to say, the free/libre/open branding does pack a whole lot of significance. |
Beta Was this translation helpful? Give feedback.
-
|
The CIO Branch ought to position itself equivalently with the demand-side (free/libre) and supply-side (open source) criteria, in particular because it is both a provider and acquirer of software. In the white paper, the straightforward jargon to use then is FLOSS (free/libre and open source) or FOSS (free and open source) or my preference... FLOW (free/libre/open works). The latter is a modular acronym with swappable semantics at the 4th character, which to me seems the best way of referring to:
The free/libre and open distinction is equally relevant to markets, source code, data, text and hardware. Economists use the phrase "free market" to refer to accommodation of the autonomy demanded by market participants; and the phrase "open market" to refer to the permeability allowed by an authority for trade across its defined market boundary. Similarly, the free/libre and open distinction is useful with reference to data. Reference to "freedom of data" is connected with "freedom of information" (for example https://www.ontario.ca/data/freedom-information-compliance ) This responds to information users' rights. The phrase "open data" generally implies nothing about users' rights, rather it describes the willingness of the supplier to allow anyone use the data for any purpose.' What is missing entirely from this draft white paper is a section on freedom and openness of hardware. The fact that much physical equipment is technologically bound to a specific software supplier makes this an indispensible consideration. Joseph Potvin |
Beta Was this translation helpful? Give feedback.
-
This is a question I have of the bureaucrats drafting this -- how broad is this policy intended to be? Many of the participants have focused on how the government creates, distributes and uses software. I believe the intention is to be beyond technology, so we are also talking about things such as proactive disclosure and cleaning up the ATIP process which has the bureaucracy always trying to deny disclosure. When discussing technology, is this whitepaper intended to discuss how the government regulates technology? As more and more government services are provided online, how the government regulates digital communications becomes more critical. There has thus been a disconnect between how the government wishes to adopt technology, and how it regulates technology. As a simple example, there is so much discussion of "online voting" and yet nothing about the intermediaries that the government has granted control over communications technology: How can we trust that votes are communicated correctly if under so-called "anti-circumvention" laws the owners of computers are not legally allowed to choose their own software. |
Beta Was this translation helpful? Give feedback.
-
|
I think there needs to be some considerations for every type of license. When the GC is using or expanding on existing projects, the default should always be "use what they use" even when that project doesn't necessarily require it. That position gives project teams a direct answer to what license to choose. As for net new things they produce, caution needs to be taken when expressing too hard of a stance in any direction. GPL has great licensing options, but forcing everything down that path means that in many cases a lot of groups could end up being excluded. While we certainly don't want to promote taking code solely for the purpose locking it up as part of a proprietary system, actively blocking its use in a propriety system is a pretty hard line to take from a policy perspective. |
Beta Was this translation helpful? Give feedback.
-
|
RE: " actively blocking its use in a propriety system is a pretty hard line to take from a policy perspective" Thanks for your feedback. If the development of some data or source code is paid for by taxpayers through the work of public sector employees or contractors, regardless of ownership of the copyright title to the work, would you suggest the default policy of the Government of Canada should be:
In my assessment, permissive licensing by the public sector is optimal for specifications and components that enable broad standards conformance. And unified licensing by the public sector is optimal for ensuring that the creation of works that taxpayers are underwriting, are only paid for once. And dual licensing (such as Apache 2.0 with GNU-GPL 3.0) is optimal when the public interest is served by enabling competition between the restrictively-licensed and free/libre licensed sectors of the market. The latter is the approach we are taking with the components we're creating as a private sector funded not-for-profit organization. We distribute our work “open source” under the Apache 2.0 for the programming code that is intended for ubiquitous deployment, including within solutions under restrictive licensing. And we distribute our work “free/libre” under the GNU GPL 3.0 when intended to be maintained free/libre. The different licenses have different purposes. Joseph Potvin |
Beta Was this translation helpful? Give feedback.
-
|
@jpotvin I take more of a permissive stance in general. Mostly because I have no idea what use the things people create will eventually lead to, and I want to leave all avenues open. I like the approach of dual licensing. It gets around some of the tricky situations code developed with taxpayer money could get us in to. I don't want to end up in a position where a license is picked and it restricts the ability to deliver on a mandate. That's just a bigger waste of resources. As an example, AgriCan recently produced a mobile app. They focused on the Android version first thinking that was a larger user base for them only to find out they needed to get the iOS release out the door because it had higher demand. I think all of that code should be released, but I don't think a license should be picked that means Apple will pull the iOS version. That would inhibit AgriCan's ability to deliver on their mandate, and it would literally exclude a majority share of their user population. As much as I want Apple to change their position on GPL, a policy document is not the place to pick that battle. Departments need maximum flexibility to serve their clients in the best way possible. Forcing change in someone else's terms is done through contracting, like the most recent procurement for the open by default portal. |
Beta Was this translation helpful? Give feedback.
-
|
RE: "I take more of a permissive stance in general." RE: Android version vs iOS version RE: Departments need maximum flexibility RE: like the most recent procurement for the open by default portal Joseph Potvin |
Beta Was this translation helpful? Give feedback.
-
|
I'm all for ensuring GC project managers have the opportunity to select the best license for their particular use case. I do not want to block anyone from using GPL code, and it should be encouraged when projects determine it's the right thing to do. The GC makes extensive use of Drupal, for example, and that needs to be considered and encouraged so that any enhancements they make flow back to the community under the appropriate GPL license. RE: Android version vs iOS version RE: the open by default portal procurement |
Beta Was this translation helpful? Give feedback.
-
|
RE: "we (collective we) know that open source things can be distributed on restrictive platforms, but legal advisors and project managers do not (at least not the ones I've spoken to recently)" In my experience, there's a high proportion of GC project managers and directors who do understand, and the unfamiliarity is from the DG level and above in the hierarchy. I don't want to be unfair, and certainly there are exceptions. Few at the DG-to-DM level have had experience with the practical finance and economics of the free/libre/open value chain. On Parliament Hill, the Digital Caucus has a Debian committer as its co-Chair MP, and they're working on increasing understanding in the House. Is the purpose of this white paper basically to provide the DG-through-DM levels a straightforward reference? Are "they" the target audience for this? Should it eventually become a "TBS Guide" (i.e. not a policy, just an explanatory guide)? RE: "The GC is paying someone to produce software under an MIT license. They are procuring that software and the rules of the procurement say the software must be released as open source." GC can't tell the contractor how to license their software. What it can do is state in the contract that all software committed to the project will be under specified licenses. The contractor then remains free to also license their work any way they want, in parallel to the free/libre/open licensed code stream that GC would distribute. Please see: "Policy on Title to Intellectual Property Arising Under Crown Procurement Contracts" (Appendix A – Exceptions to Contractor Ownership and Treasury Board Exemption) https://www.ic.gc.ca/eic/site/068.nsf/eng/00005.html#appA
Some people think this is bad for free/libre/open, but actually, it's consistent with the logic and preferences incorporated into the most recent approaches in this field, such as the Canonical Contributor License Agreement and the Fedora Project Contributor Agreement. In both of these, each contributor retains ownership of copyright title, but licenses it appropriately for the project. This is how for more than a decade some GC projects have arranged free/libre/open source contracting in conformance with Appendix A of the Policy on Title to Intellectual Property Arising Under Crown Procurement Contracts. Joseph Potvin |
Beta Was this translation helpful? Give feedback.
-
|
@mgifford, I'm curious... Why would your company not want the increased cross-license compatibilities of the GPLv3? And why wouldn't your company want the protections against software patent risk that were added to the GPLv3? And in the context of this discussion, why wouldn't the GC want these? |
Beta Was this translation helpful? Give feedback.
-
|
I've got no bias against GPLv3. We've just standardized on what the Drupal community uses. Currently Drupal 8 is distributed with GNU GENERAL PUBLIC LICENSE Version 2, June 1991 |
Beta Was this translation helpful? Give feedback.
-
|
For the benefit of others, here's a useful clarification from:
FWIW, numerous GC free/libre/open projects have long used the “version X or later" phrase. For GC employee or contractor commits to external or GC projects under any of the widely peer-reviewed license schemes, that phrase is useful so that as years go by and personnel come and go, code does not get stuck in legal anachronisms. |
Beta Was this translation helpful? Give feedback.
-
|
@jpotvin For clarity, Drupal also uses "version 2 or later" https://www.drupal.org/about/licensing#q1 There are valid policy reasons why people use "version 2 or later" rather than "version 3 or later". There are valid policy reasons why some people use "version 2" without the "or later", even if I personally strongly disagree with those reasons (Most of those reasons are disagreement with the FSF itself, and not any specific licensing terms. I believe the GPLv3 policy process exceeded the robustness of the consultation process for many international agreements, including much of what is adopted as Canadian government policy and law. The FSF should be congratulated for their work.) On the general topic of support for a full spectrum of policy options embedded in licensing.... This question about policy is an important one, as the policy embedded within licensing agreements shouldn't be taken lightly by the government. What if I ran a company that hosted an application repository/store, and set a company policy that opposed income tax. If the government of Canada or any of the provinces wanted to post apps to that store, it is not like the government would abolish income tax. The provincial governments might even invalidate that companies contractual ability to exclude government produced software which wasn't an income tax app, saying that if the company wants to do business in their province that they had to accept anything which isn't an income tax application even if they had an ideological opposition to income tax. I'm not suggesting that any specific policy implemented by a software license agreement is as fundamental to the operation of provincial and federal governments as income taxes, but that the government shouldn't be using the internal policy of specific corporations in the determining of government policy. BTW: I happen to oppose income taxes and services taxes (The S part of GST), and strongly support resource extraction taxes and the Tobin tax -- but its not like my software contributions and technical services should ever be allowed to influence government policy on this matter any more than the views of any other individual citizen. |
Beta Was this translation helpful? Give feedback.
-
|
I completely agree with @RussellMcOrmond. The policy needs to avoid letting the current policies of any corporations dictate the stance of government. If I look around at the licenses for the things I use day to day, it pretty much covers the spectrum. I think the policy needs to avoid picking one particular license in favour of a more generic wording, but that wording needs to push towards maximum openness and resuability by its citizens. All while leaving teams to easily adopt the licensing scheme of whatever they want integrate with (for example, all our Drupal work would be GPLv2). If a project really has a license conflict, write an API to abstract the integrations. The projects will need to deal with the real world implications of their license choices. Sometimes that will mean certain license are excluded because you are trying to buy into a platform, but this is where maybe legal could help work on a guide: "You want this first, but if it won't work use this instead" type of thing. |
Beta Was this translation helpful? Give feedback.
-
|
With respect to the original issue description, I thought it might be useful, for this discussion, to know what licenses the GoC is currently using. I ran the following command from this repository: For those 21 GitHub organizations operated by the GoC, we have (number of repositories, percentage, license code): MIT, Apache 2.0, and not having a license account for 82% of repositories. If I look at all 567 repositories from all 36 organizations operated by some Canadian government (whether municipal, provincial, etc.), then Apache 2.0, MIT and not having a license still account for 75% of repositories. (BC uses Apache-2.0 rather consistently, so it swaps positions with MIT.) The distribution of the other licenses is more or less the same, with a few additional rarely used licenses. GPL-2.0 increases a little, mostly because the City of Ottawa has a lot of Drupal code. |
Beta Was this translation helpful? Give feedback.
-
|
Good idea. A wider search would also be useful that includes, say, CRAN, Bitbucket, and others. To offer just one example for illustration, there are several Bank of Canada scripts on CRAN. Certainly Health Canada, NRCan, AAFC, StatsCan and their related arms-length agencies, are big users of R. I give this as just one sort of illustration, though. The R community works mainly under the "GPL 2.0 or later" framework. Projects that are led by other entities also have very significant participation from GC teams, receiving in-kind and financial participation from GC departmental sources. Not all GC employees contributing to these projects on GC time are using their GC emails, in part, because services like Github want only a single email per individual. I reckon that the majority of GC employees contributing on government time to external projects are doing so under their private email identities. And when GC entities contract out work on free/libre/open projects, there's no direct way to map those contributions back to the GC client unless the acknowledgement is included in the README or in the commit notes (which is how I used to handle it when TBS funds that I managed were being used to contribute improvements to external free/libre/open projects). |
Beta Was this translation helpful? Give feedback.
-
|
@jpotvin think we've chatted about this offline before 😉 GitHub allows multiple email accounts per user
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, true. I should have checked, but what I was recalling was this: |
Beta Was this translation helpful? Give feedback.
-
|
You might also be interested in a work that has been initiated by the Open Government Partnership: Some issues are addressed in the file: https://github.com/DISIC/foss-contrib-policy-template/blob/master/BestpracticesTemplate.md and more general principles in https://github.com/DISIC/foss-contrib-policy-template/blob/master/FOSSPolicyTemplate.md |
Beta Was this translation helpful? Give feedback.
-
|
I generally disagree with giving priority to «permissive» licenses. I disagree even more that this priority should be found in a policy of any State or public body. Here is my take on it. The term «permissive» to qualify licenses that are basically «non-copyleft» or «non share-alike» is confusing. It seems to lead a lot of people to think that these licenses are «better» because they grants more «freedoms». As it turns out, those «freedoms» include that of redistributing shared code under a different license, which ultimately can mean (not necessarily, but it has happened) the reduction of all freedoms for all users. They also give the freedom to adopt private business models which completely deny users freedoms and contribute virtually nothing back to the community of computer users. Copyleft licenses are imperfect, they limit the possible business models to a subset of the more ethical and difficult ones, they do not address all problems related to developing and sustaining software commons, but at least they try. That's why they should be preferred by public bodies : they are an important instrument to preserve a culture of ethical excellence in the digital industry. The spirit of public service can contribute to that culture. In Canada, publishing documents in the public domain (like in the USA) is not part of the culture, therefore free software licenses are all that we should be concerned with. Public domain is poorly protected as it stands, so even if publishing directly in the public domain was as relevant in Canada as it is in the USA, it probably would not be a good idea. There is nothing easier to do than to take what belong in the public domain, modify it a little, make it your private property, and claim a new monopoly on its exploitation, one that will last even beyond your own death. Software wants to be free and copyleft is a powerful instrument to promote and protect the freedom of all. |
Beta Was this translation helpful? Give feedback.
-
|
Is this issue worth closing? |
Beta Was this translation helpful? Give feedback.
-
|
I sometimes like leaving issues like this open. The challenge seems to be that there is no longer a real drive in the GC to promote open source in any coordinated way. Feel like all the energy has gotten sucked into deploying Office365 and COVID. |
Beta Was this translation helpful? Give feedback.
-
|
When I go to https://github.com/issues/mentioned I have a few things open as if there is work to be done, when there is nothing anyone is expected to do. GitHub has a discussions feature now, and for things which are intended to be discussions they can move to discussions. |
Beta Was this translation helpful? Give feedback.
-
|
Mind you, the project maintainer would need to enable that for this repo. |
Beta Was this translation helpful? Give feedback.
-
I like where this is going. I should have said this earlier.
I do think that with the Open Source Code page it would make sense to be more specific. I would like to see these two points about code released by the government:
I think this would give people an important default when making decisions.
Beta Was this translation helpful? Give feedback.
All reactions