Documents to be added as part of ASWF transfer (#1137)

* Technical Charter, governance documents, Code of Conduct (approved by TSC)

* Draft copies of the proposed new CLAs.

These are as identical as possible to the corresponding documents of
OCIO (differing only for name changes and the like, and in just one or
two places, substituting an equivalent but slightly more clearly
worded version of some piece from OpenEXR). None of the important
legal stuff like CLAs or licenses have been altered from the OCIO and
ASWF standard template as they were approved (by my organization) for
that project.

The license remains the 3-clause BSD we have always used, so there is
no reason to contact prior authors for re-licensing. But when we get
around to moving the repo from the Imageworks GitHub account to the
ASWF one, the new CLAs will take effect and subsequent contributors
will need to sign them (even if they had previously signed the Sony
ones).
This commit is contained in:
Larry Gritz
2020-04-16 17:13:27 -07:00
committed by GitHub
parent ffc5303dcf
commit 80ab6c9063
8 changed files with 613 additions and 3 deletions
+58
View File
@@ -0,0 +1,58 @@
Corporate Contributor License Agreement ("Agreement")
Thank you for your interest in the Open Shading Language Project a Series of
LF Projects, LLC (hereinafter "Project"). In order to clarify the
intellectual property licenses granted with Contributions from any corporate
entity to the Project, LF Projects, LLC ("LF Projects") is required to have
a Corporate Contributor License Agreement (CCLA) on file that has been
signed by each contributing corporation.
Each contributing corporation ("You") must accept and agree that, for any
Contribution (as defined below), You and all other individuals and entities
that control You, are controlled by You, or are under common control with
You, are bound by the licenses granted and representations made as though
all such individuals and entities are a single contributor. For the purposes
of this definition, "control" means (i) the power, direct or indirect, to
cause the direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"Contribution" means any code, documentation or other original work of
authorship that is submitted to LF Projects for inclusion in the Project by
Your employee or by any individual or entity that controls You, or is under
common control with You or is controlled by You and authorized to make the
submission on Your behalf.
You accept and agree that all of Your present and future Contributions to
the Project shall be:
Submitted under a Developer's Certificate of Origin v. 1.1 (DCO); and
Licensed under the BSD-3-Clause License.
You agree that You shall be bound by the terms of the BSD-3-Clause License
for all contributions made by You and Your employees. Your designated
employees are those listed by Your CLA Manager(s) on the system of record
for the Project. You agree to identify Your initial CLA Manager below and
thereafter maintain current CLA Manager records in the Project's system of
record.
Initial CLA Manager (Name and Email): ______________________________________
Corporate Signature:
Company Name: ____________________________________________
Signature: _______________________________________________
Name: _______________________________________________
Title _______________________________________________
Date: _______________________________________________
+33
View File
@@ -0,0 +1,33 @@
Individual Contributor License Agreement ("Agreement")
Thank you for your interest in the Open Shading Language Project a Series of
LF Projects, LLC (hereinafter "Project"). In order to clarify the
intellectual property licenses granted with Contributions from any corporate
entity to the Project, LF Projects, LLC ("LF Projects") is required to have
an Individual Contributor License Agreement (ICLA) on file that has been
signed by each contributing individual. (For legal entities, please use the
Corporate Contributor License Agreement (CCLA).)
Each contributing individual ("You") must accept and agree that, for any
Contribution (as defined below), You are bound by the licenses granted and
representations made herein.
"Contribution" means any code, documentation or other original work of
authorship that is submitted to LF Projects for inclusion in the Project by
You or by another person authorized to make the submission on Your behalf.
You accept and agree that all of Your present and future Contributions to
the Project shall be:
Submitted under a Developer's Certificate of Origin v. 1.1 (DCO); and
Licensed under the BSD-3-Clause License.
Signature: __________________________________________
Name: _______________________________________________
Date: _______________________________________________
+252
View File
@@ -0,0 +1,252 @@
# Technical Charter (the "Charter") for Open Shading Language a Series of LF Projects, LLC
This charter (the "Charter") sets forth the responsibilities and procedures
for technical contribution to, and oversight of, the Open Shading Language
project, which has been established as Open Shading Language a Series of LF
Projects, LLC (the "Project"). LF Projects, LLC ("LF Projects") is a
Delaware series limited liability company. All Contributors to the Project
must comply with the terms of this Charter.
### 1. Mission and Scope of the Project
* **a.** The mission of the Project is to develop an open source project
with the goals indicated in the "README" file within the Project's code
repository.
* **b.** The scope of the Project includes software development under an
OSI-approved open source license supporting the mission, including
documentation, testing, integration and the creation of other artifacts
that aid the development, deployment, operation or adoption of the open
source software project.
### 2. Technical Steering Committee
* **a.** The Technical Steering Committee (the "TSC") will be responsible
for all technical oversight of the open source Project.
* **b.** The TSC voting members are initially the Project's Committers. At
the inception of the project, the Committers of the Project will be as
set forth within the "GOVERNANCE" file within the Project's code
repository. The TSC may choose an alternative approach for determining
the voting members of the TSC, and any such alternative approach will be
documented in the GOVERNANCE file. Any meetings of the Technical
Steering Committee are intended to be open to the public, and can be
conducted electronically, via teleconference, or in person.
* **c.** TSC projects generally will involve Contributors and Committers.
The TSC may adopt or modify roles so long as the roles are documented in
the GOVERNANCE file. Unless otherwise documented:
- **i.** Contributors include anyone in the technical community that
contributes code, documentation, or other technical artifacts to the
Project;
- **ii.** Committers are Contributors who have earned the ability to
modify ("commit") source code, documentation or other technical
artifacts in a project's repository; and
- **iii.** A Contributor may become a Committer by a majority approval
of the existing Committers or at the discretion of the TSC. A
Committer may be removed by a majority approval of the other existing
Committers, or at the discretion of the TSC.
* **d.** Participation in the Project through becoming a Contributor and
Committer is open to anyone so long as they abide by the terms of this
Charter.
* **e.** The TSC may (1) establish workflow procedures for the submission,
approval, and closure/archiving of projects, (2) set requirements for
the promotion of Contributors to Committer status, as applicable, and
(3) amend, adjust, refine and/or eliminate the roles of Contributors,
and Committers, and create new roles, and publicly document any TSC
roles, as it sees fit.
* **f.** The TSC may elect a TSC Chair, who will preside over meetings of
the TSC and will serve until his or her resignation or replacement by
the TSC. The TSC Chair, or any other TSC member so designated by the
TSC, will serve as the primary communication contact between the Project
and the Academy Software Foundation Fund of The Linux Foundation.
* **g.** Responsibilities: The TSC will be responsible for all aspects of
oversight relating to the Project, which may include:
- **i.** coordinating the technical direction of the Project;
- **ii.** approving project or system proposals (including, but not
limited to, incubation, deprecation, and changes to a sub-project's
scope);
- **iii.** organizing sub-projects and removing projects;
- **iv.** creating sub-committees or working groups to focus on
cross-project technical issues and requirements;
- **v.** appointing representatives to work with other open source or
open standards communities;
- **vi.** establishing community norms, workflows, issuing releases, and
security issue reporting policies;
- **vii.** approving and implementing policies and processes for
contributing (to be published in the CONTRIBUTING file) and
coordinating with the Series Manager to resolve matters or concerns
that may arise as set forth in Section 7 of this Charter;
- **viii.** discussions, seeking consensus, and where necessary, voting
on technical matters relating to the code base that affect multiple
projects; and
- **ix.** coordinating any marketing, events, or communications
regarding the Project with the LF Projects Manager or their designee.
### 3. TSC Voting
* **a.** While the Project aims to operate as a consensus based community,
if any TSC decision requires a vote to move the Project forward, the
voting members of the TSC will vote on a one vote per voting member
basis.
* **b.** At least fifty percent of all voting members of the TSC must be
present at a TSC meeting in order to establish a quorum. The TSC may
continue to meet if a quorum is not met, but will be prevented from
making any decisions at such meeting.
* **c.** Except as provided in Section 7.c. and 8.a, decisions by vote at
a meeting require a majority vote of those in attendance, provided
quorum is met. Decisions made by electronic vote without a meeting
require a majority vote of all voting members of the TSC.
* **d.** In the event a vote cannot be resolved by the TSC, any voting
member of the TSC may refer the matter to the Series Manager or its
designee for assistance in reaching a resolution.
### 4. Compliance with Policies
* **a.** This Charter is subject to the Series Agreement for the Project
and the Operating Agreement of LF Projects. Contributors will comply
with the policies of LF Projects as may be adopted and amended by LF
Projects, including, without limitation the policies listed at
https://lfprojects.org/policies/.
* **b.** The TSC may adopt a code of conduct ("CoC") for the Project,
which is subject to approval by the Series Manager. Contributors to the
Project will comply with the CoC or, in the event that a
Project-specific CoC has not been approved, the LF Projects Code of
Conduct listed at https://lfprojects.org/policies/.
* **c.** When amending or adopting any policy applicable to the Project,
LF Projects will publish such policy, as to be amended or adopted, on
its web site at least 30 days prior to such policy taking effect;
provided, however, that in the case of any amendment of the Trademark
Policy or Terms of Use of LF Projects, any such amendment is effective
upon publication on LF Project's web site.
* **d.** All participants must allow open participation from any
individual or organization meeting the requirements for contributing
under this Charter and any policies adopted for all participants by the
TSC, regardless of competitive interests. Put another way, the Project
community must not seek to exclude any participant based on any
criteria, requirement, or reason other than those that are reasonable
and applied on a non-discriminatory basis to all participants in the
Project community.
* **e.** The Project will operate in a transparent, open, collaborative,
and ethical manner at all times. The output of all Project discussions,
proposals, timelines, decisions, and status should be made open and
easily visible to all. Any potential violations of this requirement
should be reported immediately to the LF Projects Manager.
### 5. Community Assets
* **a.** LF Projects will hold title to all trade or service marks used by
the Project ("Project Trademarks"), whether based on common law or
registered rights. Project Trademarks will be transferred and assigned
to LF Projects to hold on behalf of the Project. Any use of any Project
Trademarks by participants in the Project will be in accordance with the
license from LF Projects and inure to the benefit of LF Projects.
* **b.** The Project shall, as permitted and in accordance with such
license from LF Projects, develop and own all Project GitHub and social
media accounts, and domain name registrations created by the Project
community.
* **c.** Under no circumstances will LF Projects be expected or required
to undertake any action on behalf of the Project that is inconsistent
with the tax-exempt status or purpose, as applicable, of LFP, Inc. or LF
Projects, LLC.
### 6. General Rules and Operations.
* **a.** The Project will:
- **i.** engage in the work of the project in a professional manner
consistent with maintaining a cohesive community, while also
maintaining the goodwill and esteem of LF Projects, LFP, Inc. and
other partner organizations in the open source software community; and
- **ii.** respect the rights of all trademark owners, including any
branding and trademark usage guidelines.
### 7. Intellectual Property Policy
* **a.** Participants acknowledge that the copyright in all new
contributions shall be retained by the copyright holder as independent
works of authorship and that no contributor or copyright holder will be
required to assign copyrights to the Project.
* **b.** Except as described in Section 7.c., all code contributions to
the Project are subject to the following:
- **i.** All new inbound code contributions to the Project must be made
using the BSD 3-Clause License (available here:
https://github.com/imageworks/OpenShadingLanguage/blob/master/LICENSE)
(the "Project License").
- **ii.** All new inbound code contributions must:
o **a.** be made pursuant to a binding Project Contribution License
Agreement (the "CLA") available on the Project's web site; and
o **b.** be accompanied by a Developer Certificate of Origin
(http://developercertificate.org) sign-off in the source code system
that is submitted through a TSC-approved contribution process which
will bind the authorized contributor and, if not self-employed,
their employer to the applicable license;
- **iii.** All outbound code will be made available under the Project
License.
- **iv.** Documentation will be received and made available by the
Project under the Creative Commons Attribution 4.0 International
License (available at http://creativecommons.org/licenses/by/4.0/).
- **v.** The Project may seek to integrate and contribute back to other
open source projects ("Upstream Projects"). In such cases, the Project
will conform to all license requirements of the Upstream Projects,
including dependencies, leveraged by the Project. Upstream Project
code contributions not stored within the Project's main code
repository shall comply with the contribution process and license
terms for the applicable Upstream Project.
* **c.** If an alternative inbound or outbound license is required for
compliance with the license for a leveraged open source project or is
otherwise required to achieve the Project's mission, the Governing Board
of the Academy Software Foundation Fund of the Linux Foundation
("Governing Board"), or the Governing Board's representatives designated
for such purpose, may approve the use of an alternative license for
specific inbound or outbound contributions on an exception basis. Any
exceptions must be approved by a vote of the Governing Board and must be
limited in scope to what is required for such a purpose. To request an
exception, please describe the contribution, the alternative open source
license(s), and the justification for using an alternative open source
license for the Project.
* **d.** Contributed files should contain license information, such as
SPDX short form identifiers, indicating the open source license or
licenses pertaining to the file.
### 8. Amendments
* **a.** This charter may be amended by a two-thirds vote of the entire
TSC, subject to reasonable approval by LF Projects.
Binary file not shown.

After

Width:  |  Height:  |  Size: 7.6 KiB

+11 -3
View File
@@ -1,13 +1,14 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the Open Shading Language Project. -->
# TSC meeting DATE
# OSL TSC meeting DATE
Host: NAME
[Video link](https://zoom.us/j/100511909)
[Agenda link](https://docs.google.com/document/d/1yf0bG6eoE2EvKZBNZX3nskdTvu99ADTDTNOknCDJd1I/)
### Attendees:
TSC members:
TSC voting members:
* [ ] Luke Emrose, Animal Logic
* [ ] Eric Enderton, NVIDIA
* [ ] Stephen Friedman, Pixar
@@ -39,5 +40,12 @@ Additional attendees:
- info
- info
### Next steps
* New action items:
-
-
* Items for next TSC meeting agenda:
- xxx
+8
View File
@@ -0,0 +1,8 @@
# Code of Conduct
The Open Shading Language project abides by Linux Foundation's code of
conduct, which you can read in full
[here](https://lfprojects.org/policies/code-of-conduct).
To report incidents or to appeal reports of incidents, send email to
the Manager of LF Projects at manager@lfprojects.org.
+41
View File
@@ -48,6 +48,8 @@ Contributor License Agreement (CLA) and Intellectual Property
To protect the project -- and the contributors! -- we do require a
Contributor License Agreement (CLA) for anybody submitting changes.
**While the repo is still under github.com/imageworks**
* If you are an individual writing the code on your own time and you're SURE
you are the sole owner of any intellectual property you contribute, use the
[Individual CLA](http://opensource.imageworks.com/cla/pdf/Imageworks_Contributor_License_Agreement_Individual.pdf).
@@ -64,6 +66,45 @@ opensource@imageworks.com
Our CLA's are based on those used by Apache and many other open source
projects.
**After the repo is moved to github.com/AcademySoftwareFoundation**
OSL uses EasyCLA for managing CLAs, which automatically checks to ensure
CLAs are signed by a contributor before a commit can be merged.
* If you are an individual writing the code on your own time and
you're SURE you are the sole owner of any intellectual property you
contribute, you can [sign the CLA as an individual contributor](https://github.com/communitybridge/easycla/blob/master/contributors/sign-a-cla-as-an-individual-contributor-to-github.md).
* If you are writing the code as part of your job, or if there is any
possibility that your employers might think they own any intellectual
property you create, then you should use the [Corporate Contributor
Licence Agreement](https://github.com/communitybridge/easycla/blob/master/contributors/contribute-to-a-github-company-project.md).
The OSL CLAs may be previewed here:
[Corporate](https://github.com/imageworks/OpenShadingLanguage/ASWF/OSL-CLA-corporate.md),
[Individual]((https://github.com/imageworks/OpenShadingLanguage/ASWF/OSL-CLA-individual.md)).
** Contribution sign off
ASWF requires the use of the [Developer’s Certificate of Origin 1.1
(DCO)](https://developercertificate.org/), which is the same mechanism that
the [Linux®
Kernel](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n416)
and many other communities use to manage code contributions. The DCO is
considered one of the simplest tools for sign offs from contributors as the
representations are meant to be easy to read and indicating signoff is done
as a part of the commit message.
Here is an example Signed-off-by line, which indicates that the submitter
accepts the DCO:
`Signed-off-by: John Doe <john.doe@example.com>`
You can include this automatically when you commit a change to your local
git repository using <code>git commit -s</code>. You might also want to
leverage this [command line tool](https://github.com/coderanger/dco) for
automatically adding the signoff message on commits.
Pull Requests and Code Review
-----------------------------
+210
View File
@@ -0,0 +1,210 @@
<!-- SPDX-License-Identifier: CC-BY-4.0 -->
<!-- Copyright Contributors to the Open Shading Language Project. -->
# OSL Project Governance
OSL is a project of the Academy Software Foundation and relies on the ASWF
governance policies, supported by the Linux Foundation.
There are three primary project roles: Contributors submit code to the
project; Committers approve code to be included into the project; and the
Technical Steering Committee (TSC) provides overall high-level project
guidance.
* [Contributors](#Contributors)
* [Committers](#Committers)
* [Technical Steering Committee](#Technical-Steering-Committee)
## Contributors
The OSL project grows and thrives from assistance from Contributors.
Contributors include anyone in the community who contributes code,
documentation, or other technical artifacts that have been incorporated into
the projects repository.
Anyone can be a Contributor. You need no formal approval from the project,
beyond the legal forms.
### How to Become a Contributor
* Review the coding standards to ensure your contribution is in line
with the project's coding and styling guidelines.
* Sign the Individual CLA, or if you are employed by an organization that
might have any claim to IP you create, have your organization sign the
Corporate CLA.
* Submit your code as a PR with the appropriate DCO sign-off.
## Committers
Project Committers have merge access on the OSL GitHub repository
and are responsible for approving submissions by Contributors.
### Committer Responsibilities
Typical activities of a Committer include:
* Helping users and novice contributors.
* Ensuring a response to questions posted to the
[osl-dev developer mail list](http://groups.google.com/group/osl-dev)
(to eventually become osl-dev@lists.aswf.io).
* Contributing code and documentation changes that improve the project.
* Reviewing and commenting on issues and pull requests.
* Ensuring that changes and new code meet acceptable standards and are in
the long-term interest of the project.
* Participation in working groups.
* Merging pull requests.
### How to Become a Committer
Any member of the OSL community (though typically an existing Committer or
TSC member) may nominate an individual making significant and valuable
contributions to the OSL project to become a new Committer. To nominate a
new Committer, open an issue in the OSL repository, send mail to the TSC
mail list, or raise the issue at a TSC meeting.
The TSC may periodically review the Committer list to identify inactive
Committers. Past Committers are typically given Emeritus status. Emeriti may
request that the TSC restore them to active Committer status.
## Technical Steering Committee
The Technical Steering Committee (TSC) has final authority over this
project. As defined in the project charter, TSC responsibilities include,
but are not limited to:
* Coordinating technical direction of the Project.
* Project governance and contribution policy.
* GitHub repository administration.
* Maintaining the list of additional Committers
* Appointing representatives to work with other open source or open
standards communities.
* Discussions, seeking consensus, and where necessary, voting on technical
matters relating to the code base that affect multiple projects.
* Coordinating any marketing, events, or communications regarding the
project.
Within the TSC are two elected leadership roles to be held by its members
and voted on annually. Any TSC member can express interest in serving in a
role, or nominate another member to serve. There are no term limits, and one
person may hold multiple roles simultaneously. Should a TSC member resign
from a leadership role before their term is complete, a successor shall be
elected through the standard nomination and voting process to complete the
remainder of the term. The leadership roles are:
* **Chair**: This position acts as the project manager, organizing meetings
and providing oversight to project administration.
* **Chief Architect**: This position makes all the final calls on design and
technical decisions, and is responsible for avoiding "design by committee"
pitfalls.
The chair role is assumed to rotate annually (though there are no term
limits, so the TSC may reelect an existing chair). The chief architect
position should be a source of stability and coherent design vision, so the
TSC is encouraged to choose an architect who can serve for many years and
only change architects when it is necessary for the health of the project
and its community.
At the time of election, the TSC will also agree upon which of these two
leaders will serve as the OSL ASWF (Academy Software Foundation) TAC
(Technical Advisory Council) representative for the term. This member
represents the project at all ASWF TAC meetings.
### TSC Members
(Proposed list, subject to revision, some are placeholders while their
organizations decide who should be the permanent representative)
* **Chair and TAC repreentative**: Chris Kulla - Sony Pictures Imageworks
* **Chief Architect**: Larry Gritz, Sony Pictures Imageworks
* Luke Emrose - Animal Logic
* Eric Enderton - NVIDIA
* Stephen Friedman - Pixar
* Derek Haase - DNEG
* Adrien Herubel - Autodesk
* Lee Kerley - Sony Pictures Imageworks
* Mitch Prater - Laika
* Brecht Van Lommel - Blender
### TSC Nomination and Succession
Any proposal for additional members of the TSC may be submitted by
Committers, TSC members, or other major stakeholders of the OSL community by
opening an issue outlining their case or raising the issue at a TSC meeting.
New TSC members are accepted or rejected by majority vote of the TSC.
If a TSC member is for an extended period not regularly participating or
performing the responsibilities expected of TSC members, the TSC may by
majority vote request an alternate TSC member be submitted by that
organization, or remove the inactive member from the TSC.
A voting member of the TSC may nominate a successor in the event that such
voting member decides to leave the TSC, and the TSC, including the departing
member, shall confirm or reject such nomination by a vote. In the event that
the departing member's nomination for successor is rejected by vote of the
TSC, the departing member shall be entitled to continue nominating
successors until one such successor is confirmed by vote of the TSC. If the
departing member fails or is unable to nominate a successor, the TSC may
nominate one on the departing member's behalf.
TSC membership is presumed to be retained by the individual even if they
change employers. The TSC may take action to ensure that organizational
stakeholder representation not become severely disproportionate, for example
by urging an organization that loses its sole TSC representative to nominate
a new member, or to limit the total number of voting members from any one
organization if too many members all move to the same organization.
### TSC Meetings
Any meetings of the TSC are intended to be open to the public, except where
there is a reasonable need for privacy. The TSC meets regularly in a voice
conference call, at a cadence deemed appropriate by the TSC. The TSC Chair
moderates the meeting, or appoints another TSC member to moderate in his or
her absence. Meetings may also be streamed online where appropriate;
connection details will be posted to the osl-dev mail list in advance of the
scheduled meeting.
Items are added to the TSC agenda which are considered contentious or are
modifications of governance, contribution policy, TSC membership, or release
process, in addition to topics involving the high-level technical direction
of the project.
The intention of the agenda is not to approve or review all patches. That
should happen continuously on GitHub and be handled by the larger group of
Committers.
Any community member or Contributor can ask that something be reviewed by
the TSC at the meeting by logging a GitHub issue. Any Committer, TSC member,
or the meeting chair can bring the issue to the TSC's attention by applying
the `TSC` label.
Prior to each TSC meeting, the meeting chair will share the agenda with
members of the TSC. TSC members can also add items to the agenda at the
beginning of each meeting. The meeting chair and the TSC cannot veto or
remove items.
The TSC may invite additional persons to participate in a non-voting
capacity.
The meeting chair is responsible for ensuring that minutes are taken and
archived in the project repository.
Due to the challenges of scheduling a global meeting with participants in
several time zones, the TSC will seek to resolve as many agenda items as
possible outside of meetings on the public mailing list.