Is there a variation of the GPL/BSD licences that states that you may use modify and distribute this code however you please but in such a fashion that should your distribution of the code compete with my distribution of the code some ways down the road that you will be open to merging our distributions together ?
Consider more vs. less, cat vs. dog or Libre vs. Open Office each set of packages provide similar functionality yet are direct competitors to one another. While the competition is good this creates a plethora of packages with similar implementations and features that users have to sift through before selecting one to become productive.
I was wondering if it were possible to license a package such that anyone can modify and extend it but not necessarily release it in direct competition to primary release. Should a competing release occur I would like to have the power to say "Hang on this is silly, Let's merge our efforts".
I appreciate that any two packages might have uniquely different architectures/strategies/structures for a particular problem and can see the benefit of such packages being in direct competition. When two packages are technically similar though merging them into one should be a no brainer and the way forwards, especially where the latter simply forked the former, added some features and released it in direct competition to the original.
Update (This was too long to respond with as a comment to @vonbrand):
@vonbrand commented that the freedom to extend and distribute a given source is a core part of Open Source software. I was just curious to know if there might be some means of converging the efforts of useful/successful modifications back into the the project in an effort to provide the "Best Possible" product versus having multiple branches where mine features X, his Y and hers Z. Users of the project cannot install/import X,Y and Z and are forced to go with one variant over another. That some variant Y or Z may supercede X is also fine provided the resulting project is better off for it in the end. Python's Esky project got abandoned by the original author due to competing clones and the frustration the maintainer experienced in having to compete against variants of their own package for example. Granted the freedoms permitted to the forks extend back to the original project and it could certainly incorporate these extentions back in but the maintainer of the project must then run around tracking down the forks and may loose the original audience due to the added noise. @amon points out that this is essentially the fault of the projects' stewardship but there might be some means of legally compelling all parties to stay true to the success of a project.