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. >> 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. > 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. 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). 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. 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. 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. So you are complicating the protections for no rational reason. For #2, a CLA (contribution licensing agreement) protects you. 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. >> 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. 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. 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) - 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. >> 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. >> 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? > 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. >> 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. 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 see significant threads within the resulting ecosystem" without detailed explanation and rationalization sound way too George W. for my taste. >> 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. 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. >> 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. -- Stefano. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
