harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Bringing License arguments to Sun
Date Sun, 20 Aug 2006 20:00:19 GMT
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

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

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.


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message