search

canada-ca / Open_First_Whitepaper

Open First Whitepaper - Livre blanc Ouvert en premier
https://canada-ca.github.io/Open_First_Whitepaper/
Other
171 stars 54 forks source link

Open Source Code - GPLv2, MIT, BSD #4

Closed mgifford closed 3 years ago

mgifford commented 6 years ago

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.

Acasovan commented 6 years ago

Mike, feel free to add content and we’ll approve! Great points.

Le 21 oct. 2017 à 13:02, Mike Gifford notifications@github.com 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.

43061b4a commented 6 years ago

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).

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.

mgifford commented 6 years ago

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.

obrien-j commented 6 years ago

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. Github license analysis

43061b4a commented 6 years ago

before working through the logistics of actually 'HOW' to get approval to release code.

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.

RussellMcOrmond commented 6 years ago

@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.

jpotvin commented 6 years ago

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 jpotvin@xalgorithms.org https://www.xalgorithms.org

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.

jpotvin commented 6 years ago

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 Executive Director, Xalgorithms Foundation jpotvin@xalgorithms.org https://www.xalgorithms.org

RussellMcOrmond commented 6 years ago

The fact that much physical equipment is technologically bound to a specific software supplier makes this an indispensible consideration.

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.

goatsweater commented 6 years ago

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.

jpotvin commented 6 years ago

RE: " actively blocking its use in a propriety system is a pretty hard line to take from a policy perspective"

@goatsweater,

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: (a) Any entity ought to be able to re-license and provide that same data or source code back to the public sector and others with added enforceable restrictions (price, re-distribution, purpose, etc.) (b) No entity ought to be able to re-license and provide that same data or source code back to the public sector and others with added enforceable restrictions (price, re-distribution, purpose, etc.)

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 Executive Director, Xalgorithms Foundation jpotvin@xalgorithms.org https://www.xalgorithms.org

goatsweater commented 6 years ago

@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.

jpotvin commented 6 years ago

@goatsweater,

RE: "I take more of a permissive stance in general." Consider the following scenario. GC hires Company A to create solution S which is published to bitbucket under a permissive license, Company A then puts the identical code, encrypted, under a restrictive license and its own branding, tweaks the interface a little, and sells seat licenses to several Canadian provinces. And Company B puts the identical code, encrypted, under a restrictive license and its own branding, tweaks the interface a little, and sells seat licenses to governments of several other countries. These sales would directly add to GDP, and would be deemed the preferred approach.

RE: Android version vs iOS version That's not related to the matter at issue here. GPL-licensed apps can run without issue upon restrictively licensed platforms. See: https://en.wikipedia.org/wiki/List_of_free_and_open-source_iOS_applications

RE: Departments need maximum flexibility Hence, both permissive and unified licensing models need to be available for GC project managers to select the license that best suits the project's business objectives. To prevent GC project managers from using the GPL would be to block GC from the majority of the free/libre/open source market.

RE: like the most recent procurement for the open by default portal Obtaining a copy of, and having a GC computer read free/libre/open source code is not a procurement. Acquiring the copyright title to that source code would be a procurement. Acquiring permissions under an end-user license agreement would be a procurement. And acquiring implementation or customization services would be a procurement. So, for example, when SSC purchases a RHEL license, that's a procurement. But when SSC downloads exactly the same source code as CentOS, that's not a procurement.

Joseph Potvin Executive Director, Xalgorithms Foundation jpotvin@xalgorithms.org https://www.xalgorithms.org

goatsweater commented 6 years ago

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 I think 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). This is an opportunity to inform them. I think this paper needs to allow them the maximum of flexibility while keeping a minimum viable openness to their products.

RE: the open by default portal procurement 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. This is the type of activity I'd like to encourage, although the specific license will need to be determined based on the project/purpose of the procurement.

jpotvin commented 6 years ago

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

By default, the Contractor is to own the Foreground IP arising under Crown Procurement Contracts, unless the Crown claims one of the exceptions

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 Executive Director, Xalgorithms Foundation jpotvin@xalgorithms.org https://www.xalgorithms.org

goatsweater commented 6 years ago

I agree that the current Policy on Title to Intellectual Property Arising Under Crown Procurement Contracts is consistent with the logic of more recent contributor agreements. The GC can certainly tell people how to license things though. Anyone in a contract discussion can argue terms. Those terms only apply to the contract, but if it's released once under an open license then it is released. We just need to make sure that openness means everyone benefits from the procurement.

There's a wide range of experience and knowledge at all levels on these topics, and the whitepaper is for everyone to reference. It should help the more knowledgeable teams get some traction, and it should be an educational tool to those who aren't yet up to speed. I think the policy stance should be the more general, widest ranging approach to let project teams do what's right for their projects. I'd also like to see a guide developed that then let's people follow a clear path to pick a license. A guide could demonstrate preference based on scenarios where this whitepaper is trying to avoid specifics. At least, that's my understanding based on issues about specifics in other sections.

jpotvin commented 6 years ago

RE: "but if it's released once under an open license then it is released"

Well that particular version is under that particular license. When a contractor retains copyright title, they can provide the code at a given point in time to the GC client under any of the free/libre/open licenses, but they are still entirely within their (copy)rights to relicense their work under any terms they wish. What I meant to say is, the GC client can't intrude on the contractor's (copy)right title.

RE: " the whitepaper is for everyone to reference"

Then incorporate three 2-page cheatsheets in there: one for techs (inside & outside GC), one for project managers (inside & outside GC), and one for execs (inside & outside GC). Reduce the core principles and methods guidance appropriate to each into two pages each. I reckon once that's achieved, all that would be left is to create is single "Intro" page, and a single "More Info" page.

Joseph Potvin Executive Director, Xalgorithms Foundation jpotvin@xalgorithms.org https://www.xalgorithms.org

RussellMcOrmond commented 6 years ago

@goatsweater said, " that in many cases a lot of groups could end up being excluded."

Please do not confuse license compatibility and internal corporate policy.

It is true that some license agreements for existing code may be incompatible with the GPL, meaning those two specific components can't be combined in the same program. This includes sole-proprietor licensing as well as other reciprocal licenses. This does not mean that GPL code and code under a GPL incompatible license can't interact with each other through an API (REST, etc), and run on the same computer. GPL code is used on proprietary operating systems all the time (and GPL incompatible code on on GPL'd kernels, etc), and the use of GPL as a license does not exclude commercial entities from creating proprietary products which happen to run programs under the GPL, it only restricts the licensing of derivative works of the GPL code itself.

There are no groups excluded by the GPL, but there are groups which exclude the GPL. These statements are not the same thing, and it is the internal policy of those groups that determines their own ideological opposition to the GPL and not the GPL which restricts them. There will be other groups that are ideologically opposed to what they consider overly permissive licenses being used by government.

The fact that groups exist that may be ideologically opposed to a specific licensing model should not be a consideration for the government when choosing the policy they wish to use for a specific project, except in rare circumstances where reaching those specific groups is a requirement for the very specific project (IE: it should not be a general policy of the government, but a rare exception when licensing options are excluded).

Different licenses achieve different public policy goals, and the full spectrum should be available and documented to agencies to choose the right policy for their specific projects. The idea that "vendor x" or "activist group Y" doesn't like a specific license model should not be part of the decision making criteria.

jpotvin commented 6 years ago

@mgifford, RE: "By default, all code written by my company is licensed under the GPLv2"

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?

mgifford commented 6 years ago

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

jpotvin commented 6 years ago

For the benefit of others, here's a useful clarification from: https://www.gnu.org/licenses/gpl-faq.en.html#v2v3Compatibility

Is GPLv3 compatible with GPLv2? (#v2v3Compatibility). No. Many requirements have changed from GPLv2 to GPLv3, which means that the precise requirement of GPLv2 is not present in GPLv3, and vice versa. For instance, the Termination conditions of GPLv3 are considerably more permissive than those of GPLv2, and thus different from the Termination conditions of GPLv2. Due to these differences, the two licenses are not compatible: if you tried to combine code released under GPLv2 with code under GPLv3, you would violate section 6 of GPLv2. However, if code is released under GPL “version 2 or later,” that is compatible with GPLv3 because GPLv3 is one of the options it permits.

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.

RussellMcOrmond commented 6 years ago

@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.

goatsweater commented 6 years ago

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.

jpmckinney commented 6 years ago

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:

bundle exec rake statistics:licenses ORGS=aafc-mbb,canada-ca,cds-snc,cihr,communicationssecurityestablishment,csbp-cpse,eccc-msc,fgpv-vpgf,gctools-outilsgc,geocanviz,hifis,mc-mbo-webpublishingteam,nrc-cnrc,nrcan,open-data,phac-nml,pspc-spac,ramp-pcar,servicecanada,tbs-eacpd,wet-boew

For those 21 GitHub organizations operated by the GoC, we have (number of repositories, percentage, license code):

          247       total
          123 49.8% MIT
           59 23.9% (no-license)
           20  8.1% Apache-2.0
           13  5.3% (stub)
            8  3.2% GPL-2.0
            7  2.8% (empty)
            3  1.2% (other)
            3  1.2% GPL-3.0
            3  1.2% BSD-2-Clause
            2  0.8% LGPL-3.0
            2  0.8% Crown-Copyright-CA
            1  0.4% ISC
            1  0.4% CC-BY-4.0
            1  0.4% AGPL-3.0
            1  0.4% MPL-2.0

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.

jpotvin commented 6 years ago

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).

nschonni commented 6 years ago

@jpotvin think we've chatted about this offline before :wink: GitHub allows multiple email accounts per user https://help.github.com/articles/adding-an-email-address-to-your-github-account/

GitHub allows you to add as many email addresses to your account as you like. If you set an email address in your local Git configuration, you will need to add it to your account settings in order to connect your commits to your account. For more information about your email address and commits, see "Setting your commit email address on GitHub."

jpotvin commented 6 years ago

Yes, true. I should have checked, but what I was recalling was this: https://help.github.com/articles/merging-multiple-user-accounts/ ...which says "We recommend using only one user account to manage both personal and professional repositories."

ljoubert commented 6 years ago

You might also be interested in a work that has been initiated by the Open Government Partnership: https://github.com/DISIC/foss-contrib-policy-template

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

mathieugp commented 6 years ago

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.

RussellMcOrmond commented 3 years ago

Is this issue worth closing?

mgifford commented 3 years ago

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.

RussellMcOrmond commented 3 years ago

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.

mgifford commented 3 years ago

Mind you, the project maintainer would need to enable that for this repo.