Can you effectively enforce reciprocity?

Cilk Arts is very close to releasing their multi-core programming library called Cilk++, and with it, a new license, the Cilk Arts Public License. Using this license, they attempt to close the "IDO [Internal Development Organizations] loophole" they believe exists with the current GPL. Namely: an organization can take a piece of GPL code, create a derivative work, and, if they do not distribute it outside their organization, they do not have to give it back to the community.

Cilk Arts' new license seeks to prevent this, basically, be redefining "distribution" to mean within the company as well:

If you are an IDO building applications for use by others but not "distributed" under the existing open source definitions (e.g., GPL) and you want to keep your Cilk++-based derivative work proprietary, then there is an impact. The CAPL requires you to make a fair exchange in order to use Cilk++. If you share your software with everyone, we share ours with you. If you do not wish to share, you can give back to the project by purchasing a commercial license.

I believe,that while a laudable goal, this will at best be ineffective, and at worst, stymie, or at least slow, the adoption of Cilk++; and yes, I have reasons.

There are, at least, three types of Open Source consumers:

1. Those who have full intention to give back
2. Those who have no intention to give back, and don't, despite the legal obligation to do so. See the archives of GPL Violations for plenty of examples.
3. Those who don't initially have an intention to give back, but after using the library, decide that they'd like to, or can, give back.

The first two types of consumers will not be affected by this license. The givers will give, and the keepers will keep. It is the third type of consumer where Cilk++ will lose out: the "potential givers" (PG) category.

When a PG is evaluating various libraries to use for their new multi-core program, their license and distribution model (even internally) may be in doubt. They may even have a (wrong headed) policy about giving back to open source programs. Thus, when they see "you can't distribute derivative works (even internally)" it may completely turn them off, and they'll go on to the next library. Which would be sad; I've not personally reviewed Cilk++, but as it is coming out of an MIT project, I would assume it to be created by some rather bright people. So, the PG will completely pass over the chance to use this library without any further evaluation. Cilk++ will lose in this case. If the PG would have decided not to give back, Cilk++ would have not lost or gained either way. However, if the PG would have decided to give back down the line (say, enough internal rumbling by developers, or management changing policy), then Cilk++ will have gained a contributor. But, because they say off the top that you have to give back, they will have lost everybody in the "potential giver" category. In addition, they may also lose out on a possible license sale by those who want to try the library, and then end up buying a commercial license because they wish to distribute their application as closed-source.

So, my feedback to Cilk Arts is: go with the standard GPL (or even BSD license). Those who want to give back will, those who don't, won't, and those who might will give you a try and possibly become a contributor (with code or money) when they might not have otherwise.

Your thoughts?