On 29/05/18 13:37, Jeremy Stanley wrote:
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.
We're mandating it for StarlingX, aren't we?
AIUI we haven't otherwise forked anything that was still maintained
(although we've forked plenty of libraries after establishing that the
upstream was moribund).
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.
So clearly in the future this will be the responsibility of the
Winterscale Infrastructure Council assuming that proposal goes ahead.
For now, would it be valuable for the TC to develop some guidelines that
will provide the WIC with a solid base it can evolve from once it takes
them over, or should we just leave it up to infra's discretion?
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.
__________________________________________________________________________
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
__________________________________________________________________________
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
