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.
After successfully meeting the submission criteria, Intel will incorporate the contribution into the Intel® TBB source base.
To learn more about Intel® TBB’s contribution process please refer to the contribution section of threadingbuildingblocks.org.
The final decision will rest with the maintainer (Intel).
We will need to have an Intel contribution agreement completed.
You can start contributing now.
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.
To preserve the needs of all product users, you will need to assign your copyrights to Intel, which are then licensed back to you.
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.
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.
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.
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.
Yes we have a mailing list for users or developers and it is email@example.com. Feel free to connect with us on your questions and concerns and we will be happy to provide the required help.
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.