Release policy and checklist

Ready to ship your open-source project under us? Review our release policy before the official hand-off.

To open-source or innersource?

By default, internal projects are considered innersource if the codebase/project sources are accessible only to the team; otherwise, they are open-source if a corresponding OSI-approved license is present.

Please note that if you proceed, our fiscal sponsor will hold the copyrights to your project on our behalf. Be sure to consider this when reviewing our licensing guidelines.

Regarding GitLab for Open-source Program Terms compliance

Innersource projects that are private are considered ineligible for hosting on our GitLab SaaS namespaces. For compliance reasons, they should not be mirrored/hosted there unless manually cleared by Andrei Jiroh in coordination with GitLab's open-source program team. If you need to email them, remember to CC ~recaptime-dev/[email protected] in your correspondence.

While we can have one private project for purposes of security or moderation decisions (we choose to operate the moderation project in hybrid mode, meaning issues may be confidential, but publish those reports and stats there), we may need clearance from GitLab's open-source program team first or use a separate namespace for that.

Contributions

All contributions to a Recap Time Squad-hosted project are made under the project license in an inbound-outbound model under the Linux DCO to simplify compliance.

Checklist

• Select an OSI-approved license

• Adopt the Code of Conduct and Linux DCO

• Migrate any project-specific secrets from repository secrets settings to the centralized setup on Doppler/dotenvx.

Notes

Why do we call the GitLab.com instance GitLab SaaS?

We call the cloud-hosted GitLab.com instance GitLab SaaS to match the SaaS pricing, even though their handbook says otherwise.