FAQ

Contributing to Intel® TBB

Why is there a contribution process?

In order for Intel® TBB to be released under multiple licenses, with COM being one of them, Intel must maintain rights to the code base.

For Intel® to maintain rights to the code base it needs to dual-license, contributors to the Intel® TBB project must contribute their code and explicitly agree to the contribution terms in order to properly assign these rights to Intel®.

When you contribute you don’t lose rights to your code (we give them right back to you!), but you give us enough rights that we can make the outbound dual-licensing work.

The best way to make changes to Intel® TBB is to contribute them. That way they get into the main source base for Intel® TBB and will be included and tested in all future releases.

What will Intel do with my contribution?

After successfully meeting the submission criteria, Intel will incorporate the contribution into the Intel® TBB source base.

What is the contribution process?

To learn more about Intel® TBB’s contribution process please refer to the contribution section of threadingbuildingblocks.org.

Who will decide which contributions are accepted to the Intel® TBB code base?

The final decision will rest with the maintainer (Intel).

What process do you expect to follow when determining whether or not to accept contributions from the Open Source community?

We will need to have an Intel contribution agreement completed.

 

When can I start contributing fixes and enhancements to Intel® TBB? How can I start doing that?

You can start contributing now.

Why do you have a contribution agreement?

The Intel contribution agreement is needed to ensure that Intel has the rights to your contributions such that it can enforce the Apache v2.0 license and the Intel commercial license effectively for TBB.

Do I lose any rights to my contribution under the Intel contribution agreement?

To preserve the needs of all product users, you will need to assign your copyrights to Intel, which are then licensed back to you.

How do you plan to manage the process of introducing changes made by the community to your commercial products?

We will actively review the proposed changes to the source and assess market demand for the newly proposed changes. The more a change contributes to a capability that shows high demand from our user base, the more likely we are to incorporate the change.

Why should I assign my copyrights to Intel?

So Intel has the rights to your contributions such that it can effectively enforce the Apache v2.0 license and the Intel commercial license for TBB.

Do you expect to accept all input unchanged?

We hope so. When that is not the right thing for TBB, we’ll work it out with the submitter. We’ll need to review the impact of the change, and introduce changes that result in the most overall customer benefit.

What turn around do you expect on accepting changes in from the community?

We regularly post new updates to the Intel® TBB source; the turnaround of a specific change will depend on the complexity of the change and the time it takes to complete each step of the review process. We’ll strive to make the process visible for the community.

Is there a mailing list for users or developers?

Yes we have a mailing list for users or developers and it is inteltbbdevelopers@intel.com. Feel free to connect with us on your questions and concerns and we will be happy to provide the required help.

Does this project include the “right to fork?”

Yes. But may we say “ouch!”? Forking has been called a “nuclear option.” We are committed to being excellent maintainers – translating our passion for parallelism and for helping software developers into a fantastic project. A project which is a good experience for all involved. If “forking” seems like a good idea for some reason, we hope we’ll have the chance to discuss it and work out differences. We think the industry will benefit from a single strong project.

However, we also believe that the “right to fork” is an important right. It is a “check” on the maintainers which helps bring balance. Of course, if your maintainer is evil or bad in your opinion, this “check” can be powerful.

So we believe in the “check” but we think that projects should be well maintained and, in general, not fork. Therefore, we adopted standard licenses, which include the “right to fork.” No funny little “extra” clauses saying you can’t fork. If we fail to be a good enough maintainer to build a community which does not fork – we’ll be sad and disappointed. Enough said.