Requirements for Projects ingesting other existing external projects

[Relequestual]

In the process of drafting the charter for JSON Schema, I proposed that ingestion of existing tooling was within scope for JSON Schema.

Feedback from @tobie highlighted that doing so would need OpenJS Foundation CPC and Board approval.
https://github.com/json-schema-org/community/pull/325/files#r1172398988 due to IP transfer.

I understand the requirement, but is there any documentation of such a process and the requirements?

There are a few existing tools that I would expect JSON Schema to ingest and take responsibility for over the next year already.

I asked around, and it looks like the Node.js project ingested at least one existing tool under their GitHub org recently. Was this something that went through OpenJS Foundation approval? I'm not looking to get anyone in trouble here, just trying to understand if a process was followed, or if such requirements could be documented by the CPC or made clearer should they be documented already.

I grant, it's probably unlikely that most Projects here will have capacity to take on additional repositorities, but for the larger or better funded projects, it seems like a good thing to enable and support.

Edit: I note that the Node.js Project specifically details the process by which they move GitHub repositories into their org: https://github.com/nodejs/admin/blob/main/GITHUB_ORG_MANAGEMENT_POLICY.md#repositories
The mention...

In certain cases, OpenJS Cross Project Council and/or OpenJS Foundation Board of Directors approval may also be required.

In which cases do the CPC and Board want to be involved, and in which cases do they not?

[tobie]

In which cases do the CPC and Board want to be involved, and in which cases do they not?

IMHO, the CPC should be involved in all cases, and the Board should be involved whenever there are specific IP considerations (as already determined by the IP policy).

[ovflowd]

This seems like a really good question. I also would agree in most cases just Voting Members (CPC) involvement should be enough.

[mcollina]

We don't have any specific guidelines for this. As far as I'm aware, both Node.js and Fastify had projects migrated to the organization without involving the CPC.

[tobie]

How did you manage the IP transfer?

[mcollina]

In all the cases I remember, the creator of the project transferred the repository to our orgs. Typically they were collaborators.

[tobie]

I think it would be good hygiene to run these past the CPC / staff in the future and combine it with a mini-onboarding checklist (license check, CoC, trademark transfer, website footer, domain name transfer, etc.).

[Relequestual]

I think it would be good hygiene to run these past the CPC / staff in the future and combine it with a mini-onboarding checklist (license check, CoC, trademark transfer, website footer, domain name transfer, etc.).

This doesn't seem unreasonable. Logo is another item.

This article is intersting in relation: https://www.codeforsociety.org/news/intellectual-property-in-open-projects

In keeping with CLA/DCO requirements, if the primary owner asserts they, to the extend that they know, are are transfering all IP, and have the right to do so, would that be sufficiant? (Is it even OK to ask that?)

[gregsdennis]

It should be noted that JSON Schema has already ingested the JSON Schema Test Suite, which started as a separate project. This was done years ago, but the concept isn't outside of the realm of existing practices for the project.

[Relequestual]

There was also the "understanding JSON Schema" site, which was originally created by an academic insittute. They transferred the repo to us and gave us permission to publish.

[Relequestual]

I think it would be good hygiene to run these past the CPC / staff in the future and combine it with a mini-onboarding checklist (license check, CoC, trademark transfer, website footer, domain name transfer, etc.).

@tobie what if they don't have a CoC for example? Taking ownership of the project under the GitHub org would automatically apply the org wide default.

I'd love to have a list of the concernes and what things should be checked. This will make it easeir to present to the CPC and for the CPC to escalate to the Board as appropriate.

Of course, this is something the CPC would need to define, possibly in collaboration with the Board and legal.

[mcollina]

In the Node.js project we have the processing of transferring a repository to the project documented: https://github.com/nodejs/admin/blob/main/transfer-repo-into-the-org.md.

I don't think the CPC should block / or be involved in these activities (first because it'd be more work).

[tobie]

@gregsdennis wrote:

It should be noted that JSON Schema has already ingested the JSON Schema Test Suite, which started as a separate project. This was done years ago, but the concept isn't outside of the realm of existing practices for the project.

@Relequestual wrote:

There was also the "understanding JSON Schema" site, which was originally created by an academic insittute. They transferred the repo to us and gave us permission to publish.

Those two should be covered as part of the onboarding process.

@mcollina wrote:

I don't think the CPC should block / or be involved in these activities (first because it'd be more work).

I don't think the CPC should block either, but this is an IP transfer, not getting this vetted creates liability issues for the foundation and for downstream users. For example, I don't even see a requirement to abide by the foundation's IP policy in the document you shared.

[Relequestual]

@tobie The onboarding checklist doesn't (seem to) mention IP, apart from in relation to crowd funding.
In relation to Trademarks...

List trademarks the project commits to transfer to the OpenJS Foundation following graduation

I was told as we had no trademarks, it was a no-op: json-schema-org/community#348

Although I note it IS found in the project application. JSON Schema noted in ours that we might need help with this. I don't recall if there was specific discussion. I wonder, given it's not on the checklist, if it might have been missed.

[mcollina]

I don't think the CPC should block either, but this is an IP transfer, not getting this vetted creates liability issues for the foundation and for downstream users. For example, I don't even see a requirement to abide by the foundation's IP policy in the document you shared.

I think drafting a policy on this would be good, extending the one in Node.js.
Let's not introduce a "CPC approval" process on this, because it would slow things down.

[mhdawson]

Adding to @mcollina comments I think if the OpenJS Foundation could provide projects tools that help scan repos in terms of requirements that might apply in this cases that would add more value and a manual CPC approval. In the case of the Node.js project often the projects transferred are from known collaborators etc. so there may be bigger risk of just forgetting to do things like adding a licence or collaborating document and tooling would help make sure we have have the required docs/checks for both transferred repos as well as newly created ones.

[tobie]

How common are these transfers?

I’m all for streamlining IP transfers (for the record, I worked to streamline the whole IP policy into a 4-point guideline), but IP transfers come with liability and we need to be a little more intentional about this.