Gitlab for Open Source program doesn't work for projects with contents majorly licensed under a Creative Commons license

I’m trying to apply Gitlab as Open Source program for 自由知識協作平台 Libre Knowledge Collaboration Platform which is an Awesome Lists-like knowledge base/solution directory that I maintain and intend to open access to the public. As the major content of this project is in natural language text instead of code it is not reasonable to use any of the standard OSI-approved licenses which is one of the mandatory criteria for applying.

I believe the characteristic of this project aligns with the spirit of the Gitlab for Open Source program, is there any way to get around the licensing restriction? The project does have some code that is licensed under OSI-approved licenses but is not the major content and shouldn’t be tagged as the entire project’s license.

Then verification ID is: 6429abfe6f49e719d6b58e09.

Thanks.

Hi @brlin :wave: Thanks for raising this.

You’re correct that only projects carrying open source software licenses approved by the Open Source Initiative are eligible for the GitLab for Open Source Program. Unfortunately, Creative Commons licenses aren’t on the OSI’s list of approved licenses. This may be in part because these licenses are meant for creative works more generally—not necessarily software, specifically. Our goal with the GitLab for Open Source Program is to promote collaboration on open source software via GitLab.

Nearly all projects in the namespace to which you link here carry Creative Commons licenses and the WTFPL, which is also not an OSI-approved open source software license. Our team needs to stick to the list of OSI-approved licenses when making determinations about program eligibility so we’re all working from a single source of truth.

I hope that extra context helps explain our requirements.

1 Like

I can understand your team needing to work from a single source of truth. I do not understand why that source has to stay restricted to the list of OSI-approved licenses. You may want to consider the combined set of OSI-approved and FSF Free/Libre licenses for your “single” source of truth (see the list of SPDX licenses for licenses that meet these criteria).

Awesome-like lists, infra-structure as code and documentation projects can all be very helpful in working on or with open source software. For many of such projects, I think the Creative Commons licenses that qualify as FSF Free/Libre are very appropriate. It would be a shame if projects don’t qualify for your Open Source Program just because they use a collaboration-oriented, free/libre license that’s not on GitLab’s approved list.

Hypothtical case in point. I write a piece of software, license it under the AGPL-3.0 and put it up on GitLab in a project under some organization. Now I write a user guide for said software, license it under CC-BY-SA-4.0 and put it up on GitLab in a separate project under the same organization. Would that organization qualify for the Open Source Program?

What if I don’t write the documentation but someone else does and puts it up under a different organization? Does that organization qualify?

1 Like

Nice points here, @paddy-hack. A few additional notes from me:

I can understand your team needing to work from a single source of truth. I do not understand why that source has to stay restricted to the list of OSI-approved licenses. You may want to consider the combined set of OSI-approved and FSF Free/Libre licenses for your “single” source of truth (see the list of SPDX licenses for licenses that meet these criteria).

Thanks for this suggestion! We’re always looking for ways we can improve the program and refine eligibility requirements and processes, so I’m happy to take this under consideration. Incidentally, I’ve had some (very) preliminary discussions with our friends at both the Linux Foundation and the OSI about automating license compatibility checking as part of the program application process and am hopeful that we’ll continue to iterate on solutions here.

Hypothtical case in point. I write a piece of software, license it under the AGPL-3.0 and put it up on GitLab in a project under some organization. Now I write a user guide for said software, license it under CC-BY-SA-4.0 and put it up on GitLab in a separate project under the same organization. Would that organization qualify for the Open Source Program?

This hypothetical case is really quite common in actual practice! I know I personally come across it regularly in program applications. And when I do, I tend to approve those applications. In most cases, the CC-licensed documentation supports the open source software in the project, and that software constitutes the majority of the project. It’s better than an alternative: open source software with conventionally copyrighted documentation. CC-licensed documentation at least allows the project to maintain the spirit of the open source program, if not the letter.

What if I don’t write the documentation but someone else does and puts it up under a different organization? Does that organization qualify?

Here’s a case that’s not likely to be accepted into the program, as the CC-licensed documentation constitutes the majority of the project and isn’t really accompanying any open source software there.

I hope that helps clarify. Thanks for this opportunity to reflect on our practice!

1 Like

Thanks for the feedback. I guess my last case is one where both organizations ought to be encouraged to merge :smiling_face:

2 Likes

For this problem please consider implementing REUSE Specification support.