harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [legal] Re: Bringing License arguments to Sun
Date Tue, 22 Aug 2006 19:00:45 GMT
Stefano Mazzocchi wrote:
> Geir Magnusson Jr wrote:
>> Stefano Mazzocchi wrote:
>>> 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'm going to assume that from here forward, when you say "IP" you mean
>> 'patent'?
> For IP I mean, "anything besides the code that you need to have licensed
> in order for you to run a piece of code that you legally obtained a copy
> of".
> For example, the code might be open source but written in a language
> where the compiler is closed source and for pay. That makes it possible
> to run it and the license might even allow you to modify the source
> code, but without the compiler that freedom is useless.
> The anti-DRM provision planned in the GPL3 is another form of IP
> reciprocity, where "IP" in this case is a cryptographic key that is
> needed to sign the code that will be run by the machine executing it.
> Again, having the source code licensed under a very free license is
> useless if the environment that runs it limits you in other ways.
> Of course, patents follow under the same category as well.
>>> 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).
>> But our license is very explicit about patents as well.
> Sure and, if you ask me, it calms your irrational fears more than it
> provides you with instruments to fight a patent-driven litigation.
>>> 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).
>> Yes....
>>> 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.
>> Yes - I'm all for that.  And you can achieve that w/ CDDL also.  (I'm
>> not pushing CDDL here - my choice would be Apache License knowing that
>> all will be well w/ GPLv3, which I thought was scheduled to arrive at
>> about the same time as the code from Sun anyway...
> That is my second best solution. If MIT/X is too weak and too old, the
> Apache License is the most modern license of the BSD branch but its
> GPLv2 incompatible.
> It is true that the GPLv3 is specifically tasked to be compatible with
> patent reciprocity clauses (which are appreciated by the free software
> community, just were not taken into consideration at the time of the
> GPLv2) but it is also true that Sun will take a considerable amount of
> time as well to make a licensing decision.
> So, let me put it this way: if the GPLv3 was out today, my suggestion
> would be Apache License: protecting on trademarks, non-reciprocal on
> code, reciprocal on patents and ignoring other IP issues (such as DRM).
> With this choice, both sides would be able to use the software.
> But since GPLv3 is still vaporware until I see RMS clapping, I think
> that MIT/X is a better choice right now.

Sure, but Sun has the luxury of time themselves.  They have announced 
javac and hotspot this year, and then the rest by June.

Maybe they could work out something interesting because of that.

>>> 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).
>> But GPLv3 is coming.
>>> 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 [legal]story).
>> Few things in this paragraph :
>> 1) I prefer to think of BSD as not restricting your freedom, rather than
>>  allowing you to something, but as it is a license, it is in a sense
>> allowing the freedom.
> freedom is a highly abused term. Both "open source" and "free software"
> are based on basic principles (the same, actually, just worded
> differently and with different ethical/moral attachments) but at the end
> they "restrict" somebody to "free" somebody else. So, it's not true that
> BSD is really free and GPL is not because forces code reciprocity: it
> just depends on what you value most and who you want to protect/empower,
> the user or the developer.
> I like to categorize licenses by their restrictions rather than their
> freedoms, since this has much simpler moral complexities to deal with.

Sure.  That makes the GPL/BSD difference even easier to describe :)

>> 2) MySQL - No comment, other than I'd not be too keen in participating
>> in a MySQL-like ecosystem around a Java implementation.
> Agreed.
>>> 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.
>> I don't see that.  There's no burden to not contributing patent licenses
>> to a codebase, compared to maintaining an "internal fork" if you choose
>> not to give modifications back to the community.
> That is a good point, but misses mine.
> Let me rephrase: the starting point is that all existing IP that covers
> the RI is owned or licensed by Sun. The current state of affairs is that
> you get a license for that IP once you pass the certification tests and
> either, you pay or you are a non-profit.
> If it is not true that Sun doesn't own all the IP on the RI and there is
> somebody else sitting out there with a submerged patent on it, the Java
> ecosystem has much bigger issues than what license to use for the RI
> codebase, so let's use that as a working starting point.

I think that it's not unreasonable to believe that there are patents out 
there on Java not held or licensed by Sun, but I'm not really worried 
about them.

> So, this means there is nobody out there sitting on the existing
> codebase with a patent that the user community cannot get a license to
> (if their code passes certification).

I don't believe that, but I don't believe that for any software, so my 
position isn't special to Java.  And again, I don't worry about that 
because, well, it's not really pragmatic to go hunting down trouble when 
I think that such a thing is really impossible :)

> Now, there are three cases:
>  1) BigCoWithPatent forks the RI, adds some code that implements one of
> their patents.
>  2) BigCoWithPatent donates some code to the RI that is covered by a
> patent they own but they don't say so.
>  3) Joe Committer donates some code to the RI that is covered by a
> patent that BigCoWithPatent owns and nobody (yet) knows.
> For #1, my claim is that if they have a patent and it's not already
> covering RI code, there will have to be some other code to implement
> such patent. Since such patent would not be trivial matter (or at least
> one would hope) and it is not already covered by the RI (or it would be
> easy to fight it as prior art), therefore it's implemented by a code fork.

Right - I don't think we care about #1.  People are free do to what they 

> the ASF has experienced "private branches" but no fork in the
> Emacs/XEmacs or Free/Open/NetBSD sense where the codebases diverge in
> both community and functionality. BigCoWithPatent might decide that it's
> economically feasible for them to keep investing on a private branch,
> just like say IBM does with WebSphere for HTTPD. For HTTPD, that is a
> small price to pay for "owning" the HTTP serving market. As much as we
> consider non-reciprocity of code a small price to pay for the social
> comfort it generates, I don't understand why you feel that patents are
> different.

Because there's work required in maintaining the private internal branch 
- in not giving back - because you will probably want to harvest cool 
things from the public project.

As for not offering a patent license?  it's painless.  You just don't do 
it. No followup is needed.

> I understand you are concerned about the SCO-like patent attacks of
> somebody coming in and telling you that you can't run your own code
> because they own the rights to the concept... but if that is the case
> against the RI, we have a way bigger problem and that's nothing a
> license can fix.

It doesn't solve every problem, but it would induce patent harmony among 
the participants, at least.  Of course, my vision is that everyone is 
participating on the core of this - so that we have a core VM and 
complete classlibrary that all can use, and then do private innovation 
on performance and ports and such.

> So you are complicating the protections for no rational reason.

I don't think so, because we want a situation where the IP grants are 
clear, explicit and forever, and not dependent upon the current goodwill 
of any participating entity to continue.

> For #2, a CLA (contribution licensing agreement) protects you.

Protects whom and how?

> For #3, it's pain but it's pain no matter what license you choose since
> the guy donating the code doesn't own the rights anyway, so reciprocity
> doesn't work anyway.

Agreed - there's nothing that one can do here.  It's like my view on 
patents outside of the contributors - no reason to go looking.

>>> 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).
>> I'm still not seeing it if my assumption about you meaning "patent" when
>> you say "IP" is valid - what it could do is create a situation where no
>> one would want to do anything out of fear of patent action.  Modern OSS
>> licenses solve this partway by having contributors explicitly license
>> patents they own that are covered by their contributions.
> I have explicitly mentions that there is no need for a CLA (the "input"
> license) to be embedded in the "output" one. It is a decision that the
> ASF made but, if you ask me, it didn't really help us since, just to
> sure, we get CLAs for committers anyway.

But we get CLAs for different reasons, I thought - we get CLAs to 
demonstrate that the ASF is doing due diligence to ensure that 
contributions it gets are valid, and that the poeple making the 
contributions understand the terms under which they are contributing. 
IOW, BadActorBob could contribute someone elses code with or without the 
CLA in place - but with the CLA in place, the ASF has a better chance of 
showing that it didn't participate in contributory infringement as that 
BadActorBob stated he understood by signing the CLA.

> It helps on those little patches that people don't sign a CLA for, but I
>  strongly doubt that Sun would allow even a single line of code to enter
> the code repository without some sort of licensing agreement between the
> parties involved, including individuals.

That's fine - I'm all for agreements.  What I want to avoid there (and 
this is tangential to the patent protection in license discussion) is 
assymmetry in freedom to relicense - because I think that will limit 
participation, and we want everyone involved in open source java.

> So, here's my detailed proposal:
>  - MIT/X on the way out
>  - ASF-like CLA on the way in for *any* contribution (you can make that
> click-thru when you apply a patch on jira)

I don't think the CLA does any more than the license wrt IP... does it? 

>  - trademark and patent licenses separate, free for non-profits that
> pass the TCK.
>  - The TCK freely available to download and run with no NDA or
> restriction on result publication on your own certification status. The
> "open source" status of the TCK is non really that important.

Agreed on last sentence - the only thing that open source does is remove 
all sorts of fear that people have in touching the code.

I put it another way to someone else earlier today :

The TCK is a combination of stuff - not just tests.  So make the test 
code open source, and distinguish that from the TCK, which is an item 
you still have to license from the spec lead.  IOW,

   TCK == 'other stuff' + 'test code'

and if test code is in oss, then the limits to participation in the code 
aspects are greatly reduced.  People might not want to sign up for 
whatever the TCK license has in it, but if they can work with the code 
in the project, find and fix bugs, then things should go better.

>>> 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.
>> I don't understand that sentence.
> Case #3 above.

Got it - thanks

>>> 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.
>> I think that there actually is a problem because of the asymmetry in the
>> ecosystem.
>> Big Co and Bigger Co  have loads of patents on this technology, I
>> assume.  Stefano Co. has zero.  
> Correct, and this is true for every MIT/BSD/GPL/LGPL project out there
> but it has not stopped FOSS to exist or even stride, hasn't it?

Well, if you like that argument, why not have us all use GPL? :)  GPL 
hasn't stopped FOSS or broken it's stride :)

My point is that the OSS ecosystem is evolving, and the participants 
entering it, the value of things being OSS licensed, and the stakes at 
stake are much different than years ago.

Sure, Linux is incredibly economically valuable, but it was built 
gradually starting from some guy in his shorts in Finland, to eventually 
something where Fortune 50 companies are contributing and using.

But seeing Sun take Java, which represents a significant commercial 
investment, and push that out 'suddenly', and having the other "big 
players" decide to engage is a different thing.

Maybe it's best described as slowly boiling the frog, versus throwing 
the frog into a roiling pot :)

At the end of the day, I think you can say the results are pretty much 
the same, but i do believe that there is 'path dependence' to how one 
arrives at those results.

>> Big Co and Bigger Co can cross license
>> to keep the peace between them.  Stefano Co can't.  Stefano Co is
>> subject to whatever whims Big Co and Bigger Co have unless mechanisms
>> like the patent languages in modern licenses are in force. True, by not
>> contributing, they stay clear of the patent license obligation, but a
>> counterstrategy to that is to try and form as big a 'commons' as
>> possible, leaving non-participants as outliers.  IOW, create a community
>> of "patent peace", be it via a common codebase that all have contributed
>> to, or something more explicit - a patent pool or such.
> *yes* but this is performed by an *input* license (a patent-strong CLA)
> which does *NOT* need to be part of the *output* license.
> This is *my entire* point.

Ah.  I still don't understand though.  Who are the parties to the input 
license?  BigCo and Sun?  (lets put some names here so it's clear)  What 
does StefanoCo do then?

>>> 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.
>> I guess I didn't understand the analysis, as I see that significant
>> threats remain within the resulting ecosystem, threats that if we don't
>> already know how to deal with, we're working hard on finding solutions.
> I'm sorry, but this is FUD.

How is it "FUD"?  Clearly, I'm not the only one concerned about patent 
protection, as you see it in every modern OSS license...

> I've outlined all the possible scenarios and I've shown that the
> licensing strategy that I proposed achieves the same protection level
> and increased compatibility *now*.
> If you disagree, please outline scenarios where my strategy fails and
> the reasons why.

I can't understand the strategy as I don't understand what the "input 
license" is and who it's between.

In the case of the ASF CLA, that's a restatement of the terms of the 
Apache license wrt copyright and patent, and some other additional 
things like a statement of originality and ability to contribute.

> "I see significant threads within the resulting ecosystem" without
> detailed explanation and rationalization sound way too George W. for my
> taste.

The threat of patents, and how to create a system in which there's a 
"patent peace" among all participants.  I'll re-read what you wrote in 
both messages, but I still don't grok it.

I think that the only reason why Sun would consider MIT is because of 
the problem w/ the GPL.  CDDL would be fine with us, but it's been 
deemed not compatible with the GPL by the FSF.

>>> 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.
>> I dunno.  Assume you have the GPLv3 now.  Isn't that statement
>> non-operational?
> We *DO NOT* have GPLv3 now. My strategy is based on that.
> If we had GPLv3 now, and Apache License compatibility written all over
> it, the choice of the Apache License would be a no brainer.


>> And since that's just a matter of months, isn't this really about having
>> a "brand approved" license that successfully interoperates, rather than
>> any real philosophical incompatibility?
> "matter of months"? please, don't insult our intelligence.

Sun claims that they will have things done by June 2007.  The FSF is on 
track to have GPLv3 done by May 2007.  Which bit of your intelligence 
was insulted there?

> But besides, license compatibility is a much less beneficial goal than
> social cooperation... and philosophical neutrality is a necessary
> precondition for any social cooperation.
> Sun could use the Apache License and bet on the GPLv3 social
> harmonization process to succeed, could choose CDDL and then dissipate a
> great deal of social friction or use the strategy I outlined and achieve
> the same results now, without bets, without delays and without social
> friction and without increasing risks.

Maybe.  I need to grok the input license.

>>> 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 think you have to be really careful about how you think about that
>> "lack of reciprocity", because comparing it to how patents are treated
>> is very different.   The "lack of reciprocity" in Sun's projects to date
>> is a copyright grant of joint ownership, not a license to use under terms.
>> By asking for joint copyright, Sun is getting free and unfettered
>> licensing rights to do whatever they want with the code.  A CDDL-style
>> or Apache License-style patent structure isn't the same thing.
>> Very simply speaking, the Apache patent license boils down to this :
>> "Each Contributor hereby grants to You a patent license to use (et al)
>> the Work"
>> That doesn't mean "You" can do anything you want with that patent
>> license, which is what Sun is able to do with the joint copyright
>> assignment.
>> Of course, Sun is free to continue with that if they choose.  I just
>> hope that what they create is a level playing field, so there are no
>> needless barriers to participation.
> I've outlined both the "inbound" licensing strategy and the "outbound"
> one. Clearly, a good "inbound" one and a bad "outbound" one would ruin
> the dynamics just as bad.
> so, yes, I know very well that both needs to be defined and I understand
> why you like a license that defines both (so that you don't have to hope
> for the other one to be done right).
>>> 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.
>> I agree with you, but there have been several forks over the years.  IBM
>> forked httpd, IBM, JBoss, ObjectWeb others forked WS...  I'd even argue
>> that Sun is technically forking Derby in their "JavaDB" product, and IBM
>> "pre-forked" Derby with the Cloudscape product that was the source of
>> Derby ... :)
> Those are 'vendor branches', they forked the code but the community is
> one. The ASF has never experienced a forked community, this is what I meant.

That is 100% true.


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