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
want.
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?
how?
- 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.
Ok.
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.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
