Geir Magnusson Jr wrote: >> CDDL is an example of clever lawyer work to modernize best licensing >> practices, but those are best practices in protection not in social >> empowerment! > > I don't understand that. Do you see the CDDL as somehow restricting > communities? No, I see CDDL something that will significantly slow or hinter the licensing compatibility assessment from both the ASF and the FSF. I fully recognize the lack of IP protection in older licenses (which might look like a naive "if we ignore it maybe it will go away" policy ) but I think that licensing the code, the trademarks and the IP separately is another fully viable strategy. I would use an MIT license for the code and a different license for the IP. The "injected IP" problem can be dealt with a contribution agreement which does *not* need to be part of the license (like apache did, for example). As far as IP protection is concerned, Sun owns (or has acquired the rights to relicense) the existing IP, they will only need to be concerned about new ones coming in from contributions and for that they can have contributors sign IP agreements (like we do for Harmony, for example, even if the license, in theory, already covers that). So, in theory, one could take an MIT-licensed RI, add some code with special IP (say a new garbage collector), pass the tests and then decide to charge people for the license of that IP. Sun could decide that they consider this "free riding" and that they want everybody to have a piece of that cake, so they can use a license that is not violently reciprocal on code donations but it is on IP (and CDDL falls under this category). The problem with this, it's that it makes it incompatible with the GPL, ending up alienating some of the very people they are counting on pleasing (and you can expect all sort of internal and external frustration would that happen). So, the choice is, in my eyes, whether to 'enforce' the reciprocity of IP licensing of not. Here, there is a lesson to be learned from the reciprocity on code: the BSD license does *not* force you to contribute back but many do anyway, and the freedom of being allowed *not to* is what makes the BSD license more palatable than, say, the GPL to many (unless you use a mysql-like unlock-the-gpl business model, which is another story). People contribute back even if they are not forced to because it's convenient for them to do so, or they are left with the burden of maintaining a branch. The same exact argument applies to IP. So, if the RI license does *not* force people to donate the IP to the modifications that are made and redistributed (after passing the tests and obtaining certification), they are actually forking, just like OSI licenses are designed to allow. But they are now on their own, against the rest of the world. The FOSS ecology has shown that branches are very hard to maintain anyway, especially against very active and healthy communities (which has become the ASF motto, community is more important than code, and, I would add, a license has to protect the community more than the code). And if the fork is killed or goes unfeasible and people try to inject known or submerged IP with contributions to the RI, the community watching and a solid contribution agreement will prevent that. In case of contributions that are covered by unknown IP, there is very little one can do to prevent in the license that covers the "usage" of the code. My reasoning for going simple and non-reciprocal for both code and IP is *not* that I'm ignoring the issue, it's that there is no need for a reciprocal licensing of the IP, as I claim that it will be socio-economically inconvenient for anybody to do so. They will try, they will fail, as much as there is no apache# or tomcat++. Just like the BSD, giving people the "freedom of choice" on whether to donate code back or keep it for themselves, has been proved to be *extremely* effective in creating healthy, innovative and open contribution ecosystems. I believe the same freedom on IP contribution is a valid and not more risky strategy that will make the java RI code maximally used and, just like other examples, foster compatibility by becoming, de-facto, the only socio-economically maintainable/feasible implementation over time. And the choice of maximum freedom (given OSI/free-software parameters) and maximum compatibility is, IMHO, a necessary condition for a social ecosystem and dynamics that will guard the RI way more effectively (and at lower costs!) than any license or army of lawyers can do. > I think that CDDL is a reasonable license, and if I wasn't > allowed to use a BSD-style license for whatever reason, I'd go that way... I never said it's a bad license. I'm saying it's not the one I would choose and I gave a socio-economical analysis on why I think this is so. CDDL will lower the perceived fear of "free riding" using IP protection strategies in Sun executives, but at the price of alienating a huge part of the java FOSS ecosystem. Just like I'm sure Sun is willing to think about lack of reciprocity for code donations, I'm suggesting that they evaluate the same exact strategy for IP, trusting that the socio-economical dynamics that this will create will be a much more effective as a protection mechanism *and* will provide them with a solution that will win for them and will win for all the FOSS communities involved, no matter what current or past licensing beliefs. I perfectly realize that I'm suggesting a bold move that might feel too risky, especially for somebody that has not experienced as much as we did in the ASF the power of social dynamics in respect to protection and stability. That said, it's hard to deny that the ASF has never experienced, in 10 years of operation, a single fork, despite the complete lack of reciprocity provisions in its licensing strategy, showing that, although counterintuitive, healthy communities are even more effective than licensing restrictions in protecting the evolution of a codebase. -- Stefano.
