Hello,
I just noticed this new change in GitLab’s free-of-charge tier user policy. They will be:
…limiting the number of users per namespace on the Free tier to 5 users.
What does this mean for GOSH’s GitLab repositories and collaborators? Anything to be worried or up-in-arms about?
P.S. Also see this discussion thread on Hacker News.
Thanks for posting. It does seem like this will affect a community of our size. Not sure what they are thinking there, especially since Github has a very competitive free (as in beer) hosting for public orgs. Given we only make use of Gitlab in a very limited way it doesn’t seem worth doing anything other than moving what we have to Github.
Wow it’s that bad?! 
Really sad that GitLab might be doing something to push users away. Are there any other non-GitHub foundries that might serve GOSH’s needs? E.g. another GitLab instance (maybe the one hosted by OSEG which @Moe has mentioned before?), or other places?
(I’m not aware of what features are used, so this might not be a good suggestion).
Consider https://codeberg.org/
Is self-hosting a GitLab instance an option for GOSH?
This is really annoying. I agree it is a silly thing for GitLab to do.
Everything is open and we are an open source community. We apply to be in the GitLab OpenSource program. There are a bunch of things we do in GitLab using the CI, and I would rather surgically remove my left kneecap than rewrite them as GitHub actions.
Sure, it depends a little how cumbersome the application process is, how often we have to repeat it and what the chances are that we get rejected. If it’s easy enough to do then let’s go with that.
I did it for GitBuilding, it was just a merge request to their open source repo.
I did it for GitBuilding, it was just a merge request to their open source repo.
That sounds… promising? Who should take this step???
Hey @hpy! Sorry for the late response, but GOSH was approved for the Gitlab open source program last year, so we should be OK for now. I will go ahead and make sure it’s renewed for this year as well!
Hi everyone, after some back and forth with folks from Gitlab, I was able to renew our subscription to Gitlab’s Open Source Program for another year!
Great news! Was it complicated and/or difficult getting this? Anything we should collectively learn from your interactions with GitLab @briannaljohns?
I have done the GitLab OSS program for projects before. They are pretty flexible and there is a human in the loop. This means that you can explain things, such as that seeing as we have a hardware project our license is not OSI approved, but it is OSHWA approved.
The annoying thing is that you have to do the renewal manually each year by emailing a person. However, they are working on automating the renewal process, or at least taking humans out of the loop.
Worth noting that there is an academic program as well as the open source one. Our group use this for both our non-OpenFlexure/GitBuilding projects, but also we do have some private repositories for things like grant writing.
Julian, are you talking about a specific project? I see the OpenFlexure design files are under CERN OHL v1.2. which indeed is not approved by OSI, but all three variants of CERN OHL v2 are.
I have had it in my todo list to include CERN OHL v2 in the list at https://choosealicense.com/, from which I believe github.com and gitlab.com generate their drop-down menus to chose a license when you create a project. The instructions to add a license to the list involve a bit of scripting or advanced github/gitlab search to prove the licenses are already being broadly used (at least in 1,000 public repositories) and this bit has made it non-trivial for me so far, but I hope to find time to go through the process this summer. If anybody would like to help, let me know!
Cheers,
Javier
@Javier I’ve been dreaming about having the CERN OHL licenses in https://choosealicense.com, how can I help? Should we start a thread specifically about this?
@Javier
Great to know v2 is OSI approved. I think I had this specific conversation with GitLab probably 3-4 years ago. So it was probably even before v2 was released. But good to know it is now OSI approved.
@hpy It would be good to push forward with this, I am not sure how best to approach choosealicense, I did start this thread in the past which was about an issue I raised trying to get GitLab directly to add open hardware licenses.
Thanks @hpy @julianstirling. I believe github.com derives their list from choosealicense.com. See this and this. And it looks like gitlab.com uses the same source for their license templates. See here.
So being accepted by choosealicense.com seems to be a prerequisite to be listed in github.com and gitlab.com. The instructions to be included in the choosealicense.com list seem quite straight-forward. Once you are sure to fulfil all conditions, you initiate a pull request. We currently can easily tick all boxes except the proof for being used in more than 1,000 public repositories. If any of you has the required skills and time to work on that, and also to open the pull request, I would be super grateful. An example for a github search is given in the instructions. I would of course make myself available to discuss in the pull request thread and answer any questions which may arise.
Cheers,
Javier
Seems there are over 1k spread across the 4 versions of the license. I know a lot of the hardware community is on GitLab but the search seems less functional.
I think it is slightly less standard how hardware projects do their license files as well. I have had a number of projects where we have hardware and software in the same repo so we need two licenses.
I am happy to open a PR with the three v2 licenses, we can then make the case that it makes sense to include all three variants. Open Hardware is becoming known and this is the key license, I think it is time to start the conversation.
Excellent! Here are the links to the three text files for the license texts:
https://ohwr.org/cern_ohl_s_v2.txt
https://ohwr.org/cern_ohl_w_v2.txt
https://ohwr.org/cern_ohl_p_v2.txt
And here are the SPDX pages, with their SPDX identifiers:
https://spdx.org/licenses/CERN-OHL-S-2.0.html
https://spdx.org/licenses/CERN-OHL-W-2.0.html
https://spdx.org/licenses/CERN-OHL-P-2.0.html
I agree that some things are better discussed and explained in the thread for the PR. Please post a link when you have it and let’s continue there.
Thanks!
Javier
Looking forward to it. Let me/us know if there’s additional ways to help other than @julianstirling’s pull request. 
