On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: > We allow various open source projects that are not an official > part of OpenStack or necessarily used by OpenStack to be hosted on > OpenStack infrastructure - previously under the 'StackForge' > branding, but now without separate branding. Do we document > anywhere the terms of service under which we offer such hosting?
We do so minimally here: https://docs.openstack.org/infra/system-config/unofficial_project_hosting.html It's linked from this section of the Project Creator’s Guide in the Infra Manual: https://docs.openstack.org/infra/manual/creators.html#decide-status-of-your-project But yes, we should probably add some clarity to that document and see about making sure it's linked more prominently. We also maintain some guidelines for reviewers of changes to the openstack-infra/project-config repository, which has a bit to say about new repository creation changes: https://git.openstack.org/cgit/openstack-infra/project-config/tree/REVIEWING.rst > It is my understanding that the infra team will enforce the > following conditions when a repo import request is received: > > * The repo must be licensed under an OSI-approved open source > license. That has been our custom, but we should add a statement to this effect in the aforementioned document. > * If the repo is a fork of another project, there must be (public) > evidence of an attempt to co-ordinate with the upstream first. I don't recall this ever being mandated, though the project-config reviewers do often provide suggestions to project creators such as places in the existing community with which they might consider cooperating/collaborating. > Neither of those appears to be documented (specifically, > https://governance.openstack.org/tc/reference/licensing.html only > specifies licensing requirements for official projects, libraries > imported by official projects, and software used by the Infra > team). The Infrastructure team has been granted a fair amount of autonomy to determine its operating guidelines, and future plans to separate project hosting further from the OpenStack name (in an attempt to make it more clear that hosting your project in the infrastructure is not an endorsement by OpenStack and doesn't make it "part of OpenStack") make the OpenStack TC governance site a particularly poor choice of venue to document such things. > In addition, I think we should require projects hosted on our > infrastructure to agree to other policies: > > * Adhere to the OpenStack Foundation Code of Conduct. This seems like a reasonable addition to our hosting requirements. > * Not misrepresent their relationship to the official OpenStack > project or the Foundation. Ideally we'd come up with language that > they *can* use to describe their status, such as "hosted on the > OpenStack infrastructure". Also a great suggestion. We sort of say that in the "what being an unoffocial project is not" bullet list, but it could use some fleshing out. > If we don't have place where this kind of thing is documented > already, I'll submit a review adding one. Does anybody have any > ideas about a process for ensuring that projects have read and > agreed to the terms when we add them? Adding process forcing active confirmation of such rules seems like a lot of unnecessary overhead/red tape/bureaucracy. As it stands, we're working to get rid of active agreement to the ICLA in favor of simply asserting the DCO in commit messages, so I'm not a fan of adding some new agreement people have to directly acknowledge along with associated automation and policing. -- Jeremy Stanley
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
