Some issues about the github Terms of Service have been raised by Dominik George.I'd like to pause the github move until we can find out more. Hopefully he will provide some more information for us soon on what those issues are exactly.
>Some issues about the github Terms of Service have been raised by
>I'd like to pause the github move until we can find out more. Hopefully
>will provide some more information for us soon on what those issues are
Yep, give me a bit of time to follow up.
While lengthy discussions about the general issues can easily be found, there are some aspects important specifically for PyGame, and I need to put those into a comprehensive text.
I will start doing that once I get to my desk through city traffic.
In reply to this post by René Dudfield
On Mon, 2017-03-27 at 10:43 +0200, René Dudfield wrote:
> Some issues about the github Terms of Service have been raised by
> Dominik George.
> I'd like to pause the github move until we can find out more.
> Hopefully he will provide some more information for us soon on what
> those issues are exactly.
I use the tosdr.org plugin, which gives a rating for ToS for a website,
and summarises the points of the license. Might give you a good
overview, you can view the summary they give here:
Biggest issues I see in that summary are:
You must provide your legal name upon registration
Your account can be suspended and your data deleted any time for any
In reply to this post by Dominik George
Thanks heaps Dominik. Sorry, I didn't mean to imply there was a rush.
On Mon, Mar 27, 2017 at 10:50 AM, Dominik George <[hidden email]> wrote:
On Mon, Mar 27, 2017 at 10:56 AM, Sam Bull <[hidden email]> wrote:
On Mon, 2017-03-27 at 10:43 +0200, René Dudfield wrote:
>I use the tosdr.org plugin, which gives a rating for ToS for a website,
>and summarises the points of the license. Might give you a good
>overview, you can view the summary they give here:
Unfortunately, the analysis provided there discusses the old ToS, not those in effect since February.
On Mon, 2017-03-27 at 11:24 +0200, Dominik George wrote:
> > I use the tosdr.org plugin, which gives a rating for ToS for a
> > website,
> > and summarises the points of the license. Might give you a good
> > overview, you can view the summary they give here:
> > https://tosdr.org/#github
> Unfortunately, the analysis provided there discusses the old ToS, not
> those in effect since February.
Ah, reported to them that it is out-of-date. Looks like you could
contribute some new points directly at https://edit.tosdr.org/ if you
feel so inclined.
Am 27.03.2017 um 11:59 schrieb Sam Bull:
On Mon, 2017-03-27 at 11:24 +0200, Dominik George wrote:I use the tosdr.org plugin, which gives a rating for ToS for a website, and summarises the points of the license. Might give you a good overview, you can view the summary they give here: https://tosdr.org/#githubUnfortunately, the analysis provided there discusses the old ToS, not those in effect since February.Ah, reported to them that it is out-of-date. Looks like you could contribute some new points directly at https://edit.tosdr.org/ if you feel so inclined.
On Mon, 2017-03-27 at 15:21 +0200, Jorge wrote:
Well, if we're mentioning alternatives, I've still yet to see anything
> Am 27.03.2017 um 11:59 schrieb Sam Bull:
> > On Mon, 2017-03-27 at 11:24 +0200, Dominik George wrote:
> > > > I use the tosdr.org plugin, which gives a rating for ToS for a
> > > > website,
> > > > and summarises the points of the license. Might give you a good
> > > > overview, you can view the summary they give here:
> > > >
> > > > https://tosdr.org/#github
> > > Unfortunately, the analysis provided there discusses the old ToS,
> > > not
> > > those in effect since February.
> > Ah, reported to them that it is out-of-date. Looks like you could
> > contribute some new points directly at https://edit.tosdr.org/ if
> > you
> > feel so inclined.
> Have you considered NotABug or GitLab?
with a better user experience than Launchpad, which is free for open
source projects, and is open source itself. I still put all my projects
In reply to this post by René Dudfield
so, let me start with a introduction on my backgrounds and why I raised
criticism about the switch to GitHub. I am Nik, and more or less here in
On the one hand, I am chairman of Teckids e.V., a German organisation
establishing the free software movement among children and students. As
part of our work, we use Python to teach coding to hundreds of children
every year, and PyGame is our core tool for that since our first tutor
(tutors at Teckids are children themselves) got into programming with
the excellent book Hello, World by Carter Sande. However, teaching
coding is only one aspect of our work - our most important goal (as
voted by our members last weekend) is improving free software to make it
suitable for educational use and use by children, and foster these
On the other hand, I am the current maintainer of PyGame in Debian
(starting only recently). My package version is not yet available,
because the upload was rejected due to copyright uncertainties
(unrelated to those discussed here). This is of course somewhat mixed
with the Teckids role as it is part of our efforts to make and keep free
software tools for children available.
So, the issues with GitHub are twofold as well. First of all, without
looking at the BitBucket ToS, I assume that the switch to GitHub
actually does not make the situation *worse* - this is something that
would need to be found out¹.
Please let me explain the two issues and how they relate.
The first issue is children under the age of 13 years not being allowed
to register with GitHub. This issue already existed before GitHub
updated their ToS, and they claim it is because of COPPA. I do think
that they could easily fix this by not requiring a legal name, which is
the only data thewy colelct that falls under COPPA, but they don't
listen. Then, COPPA only "protects" US children, and GitHub are, in my
opinion, wrong in putting this age restriction in their ToS explicitly.
They could simply tell users "you need to be legally able to accept our
privacy terms". This would mean that in the US, the restrictions by
COPPA would apply, and in e.g. Germany, a child aged seven and above
could register given parental consent. I had a lengthy discussion about
that with GitHub Legal, but with no result.
Now you might wonder whether contributors younger than 13 years do
matter at all. Please note that this is primarily opinion-based - this
aspect of my criticism is therefore explicitly opinionated. I *do* think
that excluding a certain age group is plain discrimination against a
subgroup of people. Furthermore, I have seen children as young as nine
or ten years contribute to free software, both with bug reports and with
actual code patches. This is something that is not widely seen, as
Teckids is the only organisation (according to people at international
conferences) actually helping young users to become *active* members of
the community, but it does exist and I am strongly against adding
hurdles to it.
I would personally love to see PyGame get more use in education, and I
do think that if children use it, they should be able to contribute.
There are many ways to circumvent that - e.g., I could pass on any
reports and code by young contributors, but it's not the same. Many
people get rewarded for their work on free software with attribution,
and this is even more true for children. There are certainly things that
children should not have published on the internet, but a cool history
of contributions visible under their names and accounts sure is
something that could be beneficial in later life.
Another way to circumvent this would be to accept patches on a second
channel, e.g. mail, and merge Git commits with their original author and
push them to the repository, without requiring the contributor to
register with GitHub, which leads us to the second issue.
As of 2017-02-28, GitHub changed their ToS, adding an even clearer ban
on children, and a requirement to dual-license all work to them. A quite
good analysis of that can be found here
https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm and here
I have spoken to two lawyers about that, and they basically say that on
first glance, the ToS are indeed very problematic.
The FSF, in the meantime, has published a post stating that the new ToS
do not conflict with the GPL license family here
(but they still discourage use of GitHub), I (and others) do not think
their view is correct, because the ToS explicitly say that they may use
works without attribution, and the GPL licenses explicitly require
copies to carry attribution. Also, even if the FSF is correct, this only
applies to GPL, and probably not to CC-BY-SA and other licenses
requiring attribution, or even prohibiting sub-licensing under other
In any case, with GitHub imposing special terms on a license granted to
them, all contributors also need to grant this license, for past *and*
new contributions. *If* the separate terms do not conflict with GPL,
this might be a non-issue for GPL code, but it might be an issue with
other licenses. As I see that, in order to merge code into the
repository hosted on GitHub from an outside contributor would require
them to expclicitly grant a license as required by the GitHub ToS, or
even accept the ToS even if they do not register with GitHub.
At the very least, all these issues and open questions make
contributions for all contributors, but especially children, more
complicated. Granting a license to a project is not easy for a child (or
an adult, dfor that matter) anyway, both due to legal and pedagogic
aspects. If they succeed, you don't want to go on and still accidentally
infringe their rights.
So, what's my proposed solution? None, to be honest. As a German, I'd
propose a cool code hosting platform hosted under German law, which
would solve many issues due to German privacy protection laws. Also, a
platform specially for software projects that are used in education and
who want to make contributions by young users easy would probably make
sens. That would need a joint effort by some projects. But these are
only ideas - I do not have a working solution right now, and it also
affects me (I am also still struggling to get some projects away from
At the current time, I would, however, *not* move to GitHub. If there
are no reasons that would endanger the project, I would not do anything
right now, until those who are affected by that have found a solution
(mind that many projects probably don't know that they are affected by
the "children issue").
I would very much appreciate if the PyGame devs considered the topic
around young contributors.
¹: I have quickly scanned the Atlassian ToS and it looks like they have
neither the attribution nor the age issue. While US children under the
age of 13 years still cannot register due to COPPA, this at least means
that children elsewhere can register, given parental consent. BitBucket
has issues of their own, but at least hey are the same for everyone ;).
So right now I'd eevn stay with them because it's at least clear what
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296
Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/
Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer
LPIC-3 Linux Enterprise Professional (Security)
signature.asc (919 bytes) Download Attachment
I think this is worth taking up with the PSF, Raspberry PI, and also with github.
Hi Nik,thanks for the email. I think it's going to take some time to properly read and digest all of that. For now I'll mainly reply to the pygame repo moving to github, and the exclusion. (It would be nice to talk about other things like German language needs on the website+docs, teaching resources, and also the Debian things.)
Excluding people is not nice, and I think it's against what everyone wants. (not sure about github, but I guess for them too). Perhaps with some more voices asking for change they will come to a solution quicker.
Having said that, I think we're in a theoretical problem space with regards to accepting patches for *pygame itself*. Whilst there have been, and are people who could submit patches, none have. For example, there was a child who co-authored a book about pygame with his dad. Then there was the european digital girl of the year award winner who has made some pygame programs. To mention only two people.
It's important for people wanting to participate in the python community, and in digital culture at large. Excluding any person from that is not on in my opinion.
To work around it, have you considered getting parents to to submit any contributions they made? Of course this means children give the legal rights to their parents. It would probably be a good lesson about free and libre software in the process ;)
Luckily if they want to share any work they make with python, they can do that on other websites (launchpad, bitbucket, and several hundreds of others). I think this is a much more common case (100% in the last 17 years), that people want to make things with pygame, and python, and not change python or pygame itself. So we are safe from that perspective - they are not excluded from that.
However, that they are excluded from anything is not good.
If the FSF says it's compatible, I'm inclined to follow them since I don't have the knowledge or resources to find out otherwise. But as you say the GPL/LGPL is only one(two) of dozens of FLOSS licenses. Additionally, I assume that the PSF also ok'd it, since they are on there now too.
The reasons for moving to github:
It's become very common in the python community. pygame has tiny resources, and every hour we spend trying to explain bitbucket and hg for potential collaborators is wasted effort. Managing issues is harder, CI integration is harder, and even things like searching for source code via the web is not there on bb.
The pygame_sdl2, and pygame_cffi projects are on github. These are other pygame projects I'd like to collaborate with, and it makes it easier to do so if we are in the same place. Tom, from pygame_sdl2 made some compelling arguments on the usability of the interface compared to others. I've since seen this in practice on other projects - it makes it easier to collaborate. I was serious about it taking an hour or so of close attention to teach people the basics of bitbucket and hg at sprints. I could basically work with one or two people and other people got stuck on things and gave up. So the collaboration benefits are not theoretical - I've witnessed them multiple times in practice, and have heard from others who have had the same experience.
When people decide to use their very limited free time, they don't want to learn a new website and version control system - they'd rather work on what they are interested in. It's a big barrier to put in front of people.
CPython has moved their operations to github. Which means that pretty much every single python developer has a github account to collaborate. Not only that but out of the top 400 projects (by downloads) on pypi the vast majority are on github. Most of the ones on bitbucket had a dual setup. I did the analysis a few months ago. There's 7000+ pygame related repos on github, and 400ish on bitbucket - even though pygame has been on bitbucket for a long time. A large number of past contributors (pygame has been on cvs, svn, hg, and now git) didn't have bitbucket accounts. Only one past pygame repo contributor didn't have a github account (out of 50) and now they do.
Finally, the pygame project has been on the verge of death for some years. Anything we do to reduce maintenance effort, and make collaboration easier the better. Actually I think pygame died, and some sort of zombie pygame is walking around eating brains... (well it would eat brains if it could get that gamepad out of its mouth). I really do see strong evidence that moving to github will allow more people to contribute, but also reduce the work load for maintainers, such that pygame has more of a chance to exist.
I'm with you on this issue, and am happy to help raise it with the PSF and Raspberry PI if you haven't already. It would be good to hear other peoples opinions here, and especially from the PSF and Raspberry PI (who are both on github and have policies of not excluding people).
But I'm uncertain we should stop moving the pygame repo to it.
I hope we can find a solution.
On Mon, Mar 27, 2017 at 3:41 PM, Dominik George <[hidden email]> wrote:
In reply to this post by Jorge Maldonado Ventura
On Mon, Mar 27, 2017 at 3:21 PM, Jorge <[hidden email]> wrote:
I haven't. Not sure about anyone else.
I hadn't considered moving everything there. They do support git now. But I guess there's less people using it than even bitbucket. I don't think they have windows/OSX build support, so we'd need to use github with travis/appveyor anyway for those.
Well, we're using launchpad already. We use it for building, and for making PPAs available. We'll keep using it for those reasons I think.(speaking of which, we should link those PPAs on the new GettingStarted page).
On Mon, Mar 27, 2017 at 3:38 PM, Sam Bull <[hidden email]> wrote:
In reply to this post by Dominik George
On Mar 27, 2017 08:41, "Dominik George" <[hidden email]> wrote:
I'm almost completely certain that the COPPA applies to websites in the US regardless of the location of the website user.
I'd suggest looking at some of the things StackOverflow has suggested on this topic; for example, having parents set up an account and then "giving" it to the child at the legal point in time.
The problem with this is that actual lawyers in the field have pointed out that these non-legal articles are almost certainly completely baseless. Saying that you think the FSF is wrong seems a bit presumptuous seeing they're paid to be able to understand this sort of law.
I'd suggest looking at the HackerNews discussion of the mirbsd.org article if you have not already; there's no change in rights to the code beyond what is already provided by uploading code to the publicly accessible internet.
It's not like they're going to go... oh, right! I see, we're discriminating against kids here - my bad. Let's fix it... done! Likewise, groups like Raspberry Pi, and the Python Software foundation (neither of which have responded yet) are not going to speak out against one of their corporate sponsors (right away at least) who also provide them with great tools for free*. Similarly, for github to fix this, it will take them quite some time. I expect these international legal issues are very complex, even for them.
However, no response at all so far. I expect this will take quite some time to find a solution to this.
I reached out to a few people, and even the PSF, and Raspberry PI foundations, and also emailed the python EDU-sig mailing list some hours ago. I expect there's a lot more educators on that list who might have figured out a solution. (Nik, are you on that list?)
I think Github have a fairly good track record of fixing issues like this. Although they benefit massively from FLOSS, they do provide great value to society, and the FLOSS movement.
So what can tiny pygame do? We can continue to raise the issue, and seek solutions in other ways. Giving attribution, and things like credit go a long way in FLOSS. I hope the copyright assignment to parents work around could be used (waiting for feedback from Nik on this?). But I think we can still credit them personally even in that case. Gold stars all round.
Github is where lots of FLOSS work is done at the moment, and I think pygame repo not being on there is going to have zero effect on fixing the issue. Additionally, I think pausing the transition for much longer is not a good idea.
But I can't really make the decision here. So I await feedback from others, and Nik in particular about if the suggested work arounds, and plan to effect change are acceptable?
[(A personal story in here, of why I think this is a big issue. One of my brothers is quite a lot younger than me, and when he was five we made a video together about trains. Well, he made up the story, and used the camera, and even edited it. Then we uploaded it to youtube together. Since then he's gone on to make hundreds of other short films with his friends. That moment when you realise you can create things, and send them out to the world is pretty amazing. Digital culture is really a big part of peoples lives, and anything we do to help people participate(and not just consume) is a gain for all of us. We did choose not to link my brothers name to it, because the internet allows any random person to 'comment' on things, and many nasty comments were in fact left (they have since cleaned their comment system up). The story from Nik where a python tutor learned python from a book co-authored by a child also shows that there is value to society in letting all people contribute.)].
On Mon, Mar 27, 2017 at 9:00 PM, Daniel Foerster <[hidden email]> wrote:
The software as an industry seems to be moving towards age-inclusiveness. There are significant issues with allow minors to sign up for any internet-facing service, and it would likely take years of legislation on with support from many companies to provide new guidelines that protect kids and enable them to use services like github. The main stipulation seems to be about requiring a parent's permission to use "social" features, like chat and email. Since github allows contact between members, it would be subject to regulation protecting children's privacy. IANAL.Given the broad support for an enforcement of children's privacy in the USA, I don't see children being allowed on the service without a parent's permission for a long time. From my understanding, github is no worse than other sites subject to US law, in respect to how children accounts are handled (or not).
On Wed, Mar 29, 2017 at 4:05 AM, René Dudfield <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|