FAQ on Contributor Proposal
Q: What should I propose to work on?
A: There are three main areas of contribution:
1. ASIC or platform integration (typically hardware vendors)
2. Common code -- implement missing features, maintain interface code, including API version upgrades, security and access policy, etc. (typically network solutions providers)
3. Contribute to “black box” test cases or testing infrastructure (anyone)
Feel free to contribute to other areas and don’t let this list constraint or stop you.
Q: There’s no signature section. Are these binding?
A: No. They are designed to help the community understand your areas of interest to help get you plugged in. They also serve to make sure that when you hit the ground running you are headed in a direction that is compatible with the community. Finally, they identify specific resources and initial work items to get your collaboration started.
You may find that once you get plugged in that there are other areas that are higher priority or more interesting. That’s perfectly fine; members have pivoted once they’ve joined.
Q: Can you give me an example of what a good proposal looks like?
A: Coming soon!
FAQ on Project Participant Agreement
Q: Can I change/edit/amend the agreement?
A: No, sorry! We have many companies who have already signed this agreement with no issues, and we do not plan to change its wording. The main thrust of this document is to make sure that nobody distributes the software before it becomes open source.
Q: Do I have to open source everything?
A: As a member of Stratum, you can have early access so that when it goes open source you have an advantage in the marketplace. We do not expect that hardware vendors will open source everything down to the lowest level software at the hardware interface. It will be normal for vendors to have a binary associated with their hardware. We hope that any binary would be minimal and easily/freely available for distribution.
Q: Can you clarify the FTE requirement? Does it have to be one person? How do you enforce this clause?
A: An aggregate FTE is fine (e.g. 4 people at 25%). We don't have a strict tracking/enforcement mechanism and understand that people's availability can fluctuate. As long as in the average the contribution to the community portion of the project is at or above an FTE, we shouldn't have any issues. If it's obvious over an extended period that a member isn't contributing, we reserve the right to revoke code access; this has happened to a few members.
Q: Can you explain the ONF IPR policy? Does it apply to Stratum?
A: Talk to your lawyers. The gist of it is that Stratum’s codebase is not governed by ONF’s IPR policy. It is licensed under the Apache 2.0 and also temporarily protected from distribution by Stratum’s project participant agreement. However, Stratum is also described in ONF’s UPAN reference design, which is subject to ONF’s IPR policy.
Q: Tell me more about copyright vs. IPR.
A: Well you asked for it…
The ONF CLA covers patent and copyright grants to anyone for your specific contributions to open source projects. The ONF IPR covers patent grants to other ONF members for anything contained in a final ONF spec. Stratum is an open source project, not a spec.
Here is a little bit of background and more information:
The ONF maintained a different CLA for each project that we hosted (i.e. ONOS, CORD, Stratum) before Oct. 8th, 2018. At that time, our attorneys drafted a new version of the CLA that would cover contributions to any projects hosted at ONF (including ONOS, CORD, and Stratum), primarily to make it easier for organizations to contribute to multiple projects. The document, titled "ONF Institutional CLA Contributor License Agreement for All Projects 2018 10 8.DOCX,” would supersede the Stratum-specific CLA; although signing the Stratum-specific CLA would still permit contributions to the Stratum project (but not ONOS or CORD). All of these CLAs have been based on the Apache Foundation's CLA (https://www.apache.org/licenses/cla-corporate.txt). This CLA is compatible with the Apache 2.0 license used by our projects, and it requires a Copyright and Patent license for code, documentation, use cases, or other works of authorship included in ONF-hosted open source projects. The licenses only apply specifically to the contributions made by your organization, and the grants must be to anyone that consumes/uses/modifies the open source project.
Stratum is an ONF-hosted open source project, not a draft specification, which would not be subject to the IPR policy, and contributions do not go through formal membership 60-day review (although they do go through community code review to maintain codebase quality and stability). The IPR policy applies to specification documents that undergo formal membership review like the OpenFlow spec and the Reference Design (RD) specs. The grants per the IPR policy only need to be made to other ONF members, but would include all patents that are included in the Final spec.
Currently, the UPAN RD spec covers a data plane agent that uses next-generation programming interfaces for local and/or remote control and management; it does not refer to Stratum or its internals in much detail, but does describe an agent that, at a high level, behaves like Stratum. This spec has been released in draft form by the ONF's technical leadership team (TLT), and is currently available for review and comment by an ONF member. I would encourage your team to review this spec, especially if you have specific patent claims or concerns in this space.
Stratum Technical Questions: Brian O’Connor email@example.com