[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] github terms of service issues

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

I think this is worth taking up with the PSF, Raspberry PI, and also with github.

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 <nik@xxxxxxxxxxxxx> wrote:

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
two roles:

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

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
you get.

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)