Top level license not present on some repos

PSF
1

Hello,

I hope this is the right category to ask this question. I’ve noticed that a few repositories don’t have a top level license. This makes it harder to contribute to these repositories.

As an example I’m interested in contributing to GitHub - python/buildmaster-config: Configuration for buildbot.python.org but it doesn’t have a top level license and it seems not covered by the CLA.

As counter example and similar in a sense that is an infra repo, there is GitHub - python/psf-salt: PSF infrastructure configuration that has a license attached (MIT), although not covered by the CLA.

I will have hard time to have approval from my employer (if not impossible) to contribute to buildmaster-config because no license is attached to it.

Is there a reason why no license is attached to it?

Thanks

2

This is a good point. The configuration repos don’t have CLA set up because until recently we didn’t expect non-staff to really edit them. I also personally suspect that configuration didn’t appear as copyrightable material to us when we were opening those repositories.

Unless @zware or @EWDurbin have any other ideas for this, I can:

  • add the MIT license to buildmaster-config (after precedent from psf-salt); and
  • set up the CLA bot for both buildmaster-config and psf-salt.
2 Likes
3

Seems like a plan!

2 Likes
4

:+1: Fine with me.

1 Like
5

Technically speaking, this may be legally problematic since 33 people have contributed to buildmaster-config since its inception, so to relicense you’d technically need to get written permission from each of them to release their contributions under the MIT license they are considered non-trivial and non-mechanical enough to qualify for copyright protection (in your jurisdiction(s) of interest).

In practice I highly doubt anyone is likely to object, and this ultimately stems from the legally problematic nature of the existing scenario where no one technically gave anyone else permission to use or modify their work in the first place, so it doesn’t really make things net worse, it at least covers us in the future (and for anyone who’s involved in the transition or formally agrees).

However, IMO the takeaway here is that the relatively trivial cost of plopping in a license from the start (which GitHub can do for you with a press of a button) avoids all of this. Perhaps requiring that all python org repos are under an OSI-approved open source license (ideally, OSI + FSF + DFSG approved) in the org repository poicy would make sense, both as a matter of general policy and to avoid any sorts of future issues.

3 Likes
6

I’m fine with the MIT license.

1 Like