formalising retirement as a Python committer
Sadly I have come to the conclusion that there is no realistic prospect of my being able to actively contribute to Python development in the foreseeable future given my current pursuits and interests, though I rely heavily on Python both personally and professionally.
As a practical matter I have not actively participated in Python development in some years and as a consequence I don't think I have any valid keys still on record. Nor do I now have any operational OS/2 systems to support the Python port to that platform that was my primary interest and contribution.
I would therefore request that appropriate administrative action be taken to close off any commit privileges previously granted to me that may still be active.
Beyond the OS/2 port, it pleases me that I was able to make several small contributions of more general utility.
While the announcement today of the planned move of the Python repository to GitHub has no bearing whatsoever on my decision, I would note that GitHub's requirement that a person only have one account - to be used for both personal activity and any activity on behalf of an employer - is of sufficient concern to me that had I decided to continue as a committer I would be seeking legal advice concerning my position. I say this as to date I have been able to satisfy my employer's requirements for clear separation of my personal activities, including my participation in Python development, from my activities as an employee. This has been possible by exclusively using only provably personal resources, including accounts and internet access, for personal activities. Such clear separation becomes much more difficult when resources such as accounts are shared between personal and employee roles, especially when being seen to do the right thing is as important as actually doing the right thing.
My best wishes to all who have made Python what it is and for Python's future!
Andrew MacIntyre.
--
Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 02.01.2016 13:06, Andrew MacIntyre wrote:
While the announcement today of the planned move of the Python repository to GitHub has no bearing whatsoever on my decision, I would note that GitHub's requirement that a person only have one account - to be used for both personal activity and any activity on behalf of an employer - is of sufficient concern to me that had I decided to continue as a committer I would be seeking legal advice concerning my position. I say this as to date I have been able to satisfy my employer's requirements for clear separation of my personal activities, including my participation in Python development, from my activities as an employee. This has been possible by exclusively using only provably personal resources, including accounts and internet access, for personal activities. Such clear separation becomes much more difficult when resources such as accounts are shared between personal and employee roles, especially when being seen to do the right thing is as important as actually doing the right thing.
You are making a good point which I believe we have not yet discussed.
Github requires that "One person or legal entity may not maintain more than one free account." in A.7. of their ToCs:
https://help.github.com/articles/github-terms-of-service/
So if you are using a free account for company purposes, you'd have to get a paid account for personal use to e.g. contribute to Python and clearly separate personal contributions from ones you make as employee.
By using just one account, such a separation would be difficult or could cause problems for employees of companies which require clear separation of activities from personal ones. It would also create a problem for the PSF, since without a clear separation, we'd need a contrib form from the employer to be able to legally accept the contributions in such situations.
Would any of the existing committers run into such a problem ?
I guess the PSF could refund any Github charges incurred to remedy the situation. Their smallest plan is USD 7 per month and account, so that would mean costs of USD 84 per year and committer - this certainly within range of what the PSF can provide without problem.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jan 02 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 2 January 2016 at 13:46, M.-A. Lemburg <mal@egenix.com> wrote:
I guess the PSF could refund any Github charges incurred to remedy the situation. Their smallest plan is USD 7 per month and account, so that would mean costs of USD 84 per year and committer - this certainly within range of what the PSF can provide without problem.
Alternatively, would it be worth reaching out to Github to ask if they would be willing to allow an exception? The condition seems intended to disallow spamming or camping of accounts, which clearly isn't the case here.
Note: I have no direct interest in this, as I only use my github account for personal activities, so the issue doesn't affect me.
Paul
On 3 January 2016 at 00:12, Paul Moore <p.f.moore@gmail.com> wrote:
On 2 January 2016 at 13:46, M.-A. Lemburg <mal@egenix.com> wrote:
I guess the PSF could refund any Github charges incurred to remedy the situation. Their smallest plan is USD 7 per month and account, so that would mean costs of USD 84 per year and committer - this certainly within range of what the PSF can provide without problem.
Alternatively, would it be worth reaching out to Github to ask if they would be willing to allow an exception? The condition seems intended to disallow spamming or camping of accounts, which clearly isn't the case here.
Note: I have no direct interest in this, as I only use my github account for personal activities, so the issue doesn't affect me.
I use my own GitHub account for both personal projects and for work, but Red Hat's open source contribution policies are probably the most liberal on the planet, so I don't have any need to separate them.
However, it's also the case that if an employer is simultaneously:
- Expecting employees to maintain a clear separation between personal and paid activity on GitHub; and
- Refusing to pay for dedicated GitHub work accounts for their employees
Then there's a contradiction between their expectations and their failure to provide employees with the resources needed to meet those expectations.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, 2 Jan 2016 at 07:14 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 3 January 2016 at 00:12, Paul Moore <p.f.moore@gmail.com> wrote:
On 2 January 2016 at 13:46, M.-A. Lemburg <mal@egenix.com> wrote:
I guess the PSF could refund any Github charges incurred to remedy the situation. Their smallest plan is USD 7 per month and account, so that would mean costs of USD 84 per year and committer - this certainly within range of what the PSF can provide without problem.
Alternatively, would it be worth reaching out to Github to ask if they would be willing to allow an exception? The condition seems intended to disallow spamming or camping of accounts, which clearly isn't the case here.
Note: I have no direct interest in this, as I only use my github account for personal activities, so the issue doesn't affect me.
I use my own GitHub account for both personal projects and for work, but Red Hat's open source contribution policies are probably the most liberal on the planet, so I don't have any need to separate them.
Ditto for me and Microsoft.
However, it's also the case that if an employer is simultaneously:
- Expecting employees to maintain a clear separation between personal and paid activity on GitHub; and
- Refusing to pay for dedicated GitHub work accounts for their employees
Then there's a contradiction between their expectations and their failure to provide employees with the resources needed to meet those expectations.
I also know of people whose company is being mean to them by saying "we expect you to use your single free account for us and it's your problem if you want a clean separation because we're too cheap to pay for your own account" getting around this by ignoring the ToS restriction. Obviously not everyone will feel comfortable doing that, but I have never known anyone to have their GitHub account shut down because they had separate work and personal accounts that were both on the free tier.
But as MAL said, the PSF could easily cover the fee for a core dev to get a paid micro account if someone felt they really wanted it.
Another idea I had is could someone reach out to another project like Django or Go that switched to GitHub and see how they handled this situation for contributors? I don't feel I'm in a good position to ask about this since I personally don't have this issue so I don't think I could judge what would be an acceptable solution beyond the paid micro account solution.
On Sat, 2 Jan 2016 at 09:49 Brett Cannon <brett@python.org> wrote:
On Sat, 2 Jan 2016 at 07:14 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 3 January 2016 at 00:12, Paul Moore <p.f.moore@gmail.com> wrote:
On 2 January 2016 at 13:46, M.-A. Lemburg <mal@egenix.com> wrote:
I guess the PSF could refund any Github charges incurred to remedy the situation. Their smallest plan is USD 7 per month and account, so that would mean costs of USD 84 per year and committer - this certainly within range of what the PSF can provide without problem.
Alternatively, would it be worth reaching out to Github to ask if they would be willing to allow an exception? The condition seems intended to disallow spamming or camping of accounts, which clearly isn't the case here.
Note: I have no direct interest in this, as I only use my github account for personal activities, so the issue doesn't affect me.
I use my own GitHub account for both personal projects and for work, but Red Hat's open source contribution policies are probably the most liberal on the planet, so I don't have any need to separate them.
Ditto for me and Microsoft.
However, it's also the case that if an employer is simultaneously:
- Expecting employees to maintain a clear separation between personal and paid activity on GitHub; and
- Refusing to pay for dedicated GitHub work accounts for their employees
Then there's a contradiction between their expectations and their failure to provide employees with the resources needed to meet those expectations.
I also know of people whose company is being mean to them by saying "we expect you to use your single free account for us and it's your problem if you want a clean separation because we're too cheap to pay for your own account" getting around this by ignoring the ToS restriction. Obviously not everyone will feel comfortable doing that, but I have never known anyone to have their GitHub account shut down because they had separate work and personal accounts that were both on the free tier.
But as MAL said, the PSF could easily cover the fee for a core dev to get a paid micro account if someone felt they really wanted it.
For Django this has literally never come up.
Alex
On Sat, Jan 2, 2016 at 1:24 PM, Brett Cannon <brett@python.org> wrote:
Another idea I had is could someone reach out to another project like Django or Go that switched to GitHub and see how they handled this situation for contributors? I don't feel I'm in a good position to ask about this since I personally don't have this issue so I don't think I could judge what would be an acceptable solution beyond the paid micro account solution.
On Sat, 2 Jan 2016 at 09:49 Brett Cannon <brett@python.org> wrote:
On Sat, 2 Jan 2016 at 07:14 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 3 January 2016 at 00:12, Paul Moore <p.f.moore@gmail.com> wrote:
On 2 January 2016 at 13:46, M.-A. Lemburg <mal@egenix.com> wrote:
I guess the PSF could refund any Github charges incurred to remedy the situation. Their smallest plan is USD 7 per month and account, so that would mean costs of USD 84 per year and committer - this certainly within range of what the PSF can provide without problem.
Alternatively, would it be worth reaching out to Github to ask if they would be willing to allow an exception? The condition seems intended to disallow spamming or camping of accounts, which clearly isn't the case here.
Note: I have no direct interest in this, as I only use my github account for personal activities, so the issue doesn't affect me.
I use my own GitHub account for both personal projects and for work, but Red Hat's open source contribution policies are probably the most liberal on the planet, so I don't have any need to separate them.
Ditto for me and Microsoft.
However, it's also the case that if an employer is simultaneously:
- Expecting employees to maintain a clear separation between personal and paid activity on GitHub; and
- Refusing to pay for dedicated GitHub work accounts for their employees
Then there's a contradiction between their expectations and their failure to provide employees with the resources needed to meet those expectations.
I also know of people whose company is being mean to them by saying "we expect you to use your single free account for us and it's your problem if you want a clean separation because we're too cheap to pay for your own account" getting around this by ignoring the ToS restriction. Obviously not everyone will feel comfortable doing that, but I have never known anyone to have their GitHub account shut down because they had separate work and personal accounts that were both on the free tier.
But as MAL said, the PSF could easily cover the fee for a core dev to get a paid micro account if someone felt they really wanted it.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084
This hardly seems like a real problem, so let's not worry more about it until someone actually needs help solving this.
-- --Guido van Rossum (python.org/~guido)
On 03.01.2016 05:19, Guido van Rossum wrote:
This hardly seems like a real problem, so let's not worry more about it until someone actually needs help solving this.
For Andrew, it would have been a real problem, so IMO it's better to be prepared for it and let potential new contributors know that we can help resolve the issue.
Otherwise, people who potentially have a problem wouldn't even consider contributing via the new Github workflow, which can't really be in our interest.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jan 03 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On Sun, Jan 3, 2016 at 5:38 AM, M.-A. Lemburg <mal@egenix.com> wrote:
On 03.01.2016 05:19, Guido van Rossum wrote:
This hardly seems like a real problem, so let's not worry more about it until someone actually needs help solving this.
For Andrew, it would have been a real problem, so IMO it's better to be prepared for it and let potential new contributors know that we can help resolve the issue.
Otherwise, people who potentially have a problem wouldn't even consider contributing via the new Github workflow, which can't really be in our interest.
The problem can hardly be unique to Python, can it? Thousands of well-known open source projects are now on GitHub. Also note Alex's comment that it has literally never come up for Django (which IMO has a healthier ration of contributors than core Python).
-- --Guido van Rossum (python.org/~guido)
On 03.01.2016 22:06, Guido van Rossum wrote:
On Sun, Jan 3, 2016 at 5:38 AM, M.-A. Lemburg <mal@egenix.com> wrote:
On 03.01.2016 05:19, Guido van Rossum wrote:
This hardly seems like a real problem, so let's not worry more about it until someone actually needs help solving this.
For Andrew, it would have been a real problem, so IMO it's better to be prepared for it and let potential new contributors know that we can help resolve the issue.
Otherwise, people who potentially have a problem wouldn't even consider contributing via the new Github workflow, which can't really be in our interest.
The problem can hardly be unique to Python, can it? Thousands of well-known open source projects are now on GitHub. Also note Alex's comment that it has literally never come up for Django (which IMO has a healthier ration of contributors than core Python).
Right, but people who have such a problem won't become contributors if a Github account is the prerequisite for this and most likely also won't bother asking for help. Others will either silently accept violating Github terms by using multiple accounts or ignore potential problems they might run into with their employers.
I think we should be pro-active and tell people that we are aware of the problem, do care and will offer help where needed.
Who knows, perhaps this will trigger some rethinking on behalf of Github to remove the restriction in their ToCs.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jan 03 2016)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
M.-A. Lemburg <mal@egenix.com> wrote:
Right, but people who have such a problem won't become contributors if a Github account is the prerequisite for this and most likely also won't bother asking for help. Others will either silently accept violating Github terms by using multiple accounts or A ignore potential problems they might run into with their employers.
This is exactly what will happen, especially when new committers don't dare to ask.
Given that the PSF protects itself with upload terms [1] that exceed the regular level (e.g. Google's terms are far less strict), it only seems fair that the software authors who make all this happen receive equal legal protection.
Stefan Krah
On 4/01/2016 12:38 AM, M.-A. Lemburg wrote:
On 03.01.2016 05:19, Guido van Rossum wrote:
This hardly seems like a real problem, so let's not worry more about it until someone actually needs help solving this.
For Andrew, it would have been a real problem, so IMO it's better to be prepared for it and let potential new contributors know that we can help resolve the issue.
My concern related to a potential situation rather than an existing situation, fortunately, and was partly based on incomplete information.
For my personal circumstances I've now concluded that if it had become necessary I think the separation requirements I need to comply with could be satisfied by:
- using a free GitHub account exclusively for personal activities; and
- using paid GitHub accounts exclusively for any employment related activities even in the unlikely event I have to cover costs myself.
If the scenario eventuated I would still seek formal advice to validate this assessment. It is also fortunate that I've not compromised a free GitHub account by employment related use before reaching these conclusions.
Otherwise, people who potentially have a problem wouldn't even consider contributing via the new Github workflow, which can't really be in our interest.
Having clear information about handling conflict of interest situations, particularly between personal and employment related activities in the context of both the PSF's contribution requirements and GitHub's ToS requirements (especially in relation to free accounts), can only be a help in my view.
All the best, Andrew.
--
Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Sat, Jan 2, 2016 at 5:46 AM, M.-A. Lemburg <mal@egenix.com> wrote:
So if you are using a free account for company purposes, you'd have to get a paid account for personal use to e.g. contribute to Python and clearly separate personal contributions from ones you make as employee.
In practice, I have seen the following common scenarios.
Companies and businesses, most often have a paid account with GitHub. This allows them use Github with the code which is not yet open source or will never be open source. It is simply using Github.com as an Infrastructure as a Service, which many companies will willingly do. If it is using this paid account is unsuitable for contributing to open source projects then a free account could be created by the contributor.
If the company encourages to use to free account, then I think, the company realizes that the person may contribute to, not just it's open source projects, but to other open source projects hosted in Github using that account and should be open to that.
A third scenario was mentioned by M.-A. Lemburg, wherein the company uses free account, but the company or the individual, more likely the latter, for some reason will not like to use the same account or other project contribution. In that situation, the choice is to buy a paid account.
Andrew,
Thanks for your contributions. You will be missed. Enjoy your new pursuits and interests! If you ever want to come back we'll make sure to accommodate you somehow.
--Guido
On Sat, Jan 2, 2016 at 5:06 AM, Andrew MacIntyre < andymac@bullseye.apana.org.au> wrote:
Sadly I have come to the conclusion that there is no realistic prospect of my being able to actively contribute to Python development in the foreseeable future given my current pursuits and interests, though I rely heavily on Python both personally and professionally.
As a practical matter I have not actively participated in Python development in some years and as a consequence I don't think I have any valid keys still on record. Nor do I now have any operational OS/2 systems to support the Python port to that platform that was my primary interest and contribution.
I would therefore request that appropriate administrative action be taken to close off any commit privileges previously granted to me that may still be active.
Beyond the OS/2 port, it pleases me that I was able to make several small contributions of more general utility.
While the announcement today of the planned move of the Python repository to GitHub has no bearing whatsoever on my decision, I would note that GitHub's requirement that a person only have one account - to be used for both personal activity and any activity on behalf of an employer - is of sufficient concern to me that had I decided to continue as a committer I would be seeking legal advice concerning my position. I say this as to date I have been able to satisfy my employer's requirements for clear separation of my personal activities, including my participation in Python development, from my activities as an employee. This has been possible by exclusively using only provably personal resources, including accounts and internet access, for personal activities. Such clear separation becomes much more difficult when resources such as accounts are shared between personal and employee roles, especially when being seen to do the right thing is as important as actually doing the right thing.
My best wishes to all who have made Python what it is and for Python's future!
Andrew MacIntyre.
--
Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
-- --Guido van Rossum (python.org/~guido)
participants (9)
-
Alex Gaynor -
Andrew MacIntyre -
Brett Cannon -
Guido van Rossum -
M.-A. Lemburg -
Nick Coghlan -
Paul Moore -
s.krah -
Senthil Kumaran