Hi Leo, On Thu, 2005-11-17 at 07:26 -0800, Leo Simons wrote: > I have been thinking about this and talking to people. I tell you, it > all makes my head hurt.
Sorry about that. And thanks for this email. It seems we finally have a real start for a dialog. I'll buy you a beer when we meet up! > I spoke to Cliff about this. My understanding here seems correct -- > the patent reciprocity is important to us and many of our contributors > and by dual licensing we and or contributors open up the possibility > of being sued over the patent mess, so it is unlikely (after all, in > the end this is a policy decision) that the ASF wants to recommend > licensing under any license which does not have similar-strength > patent reciprocity clauses. > > By their very nature these kinds of patent reciprocity clauses are > incompatible with the GPL v2, eg as long as this policy stands the ASF > is not in the business of distributing software that is legally > compatible with software licensed under the GPL. Understood. The goals are similar but slightly different. Traditionally people have used copyleft to "fight" these kinds of patent mess. The ASLv2 does active patent retaliation. It is a pity that isn't compatible at the moment. And even more of a shame that neither does really protect against patent-hoarders that don't use and distribute our code. It is an important fight though. And being able to combine the strategies would certainly make sense. I liked you analogy with walls around communities. We want to protect our own communities by drawing clear lines/putting up walls. Unfortunately walls might keep out both the good and the bad guys. That really is why for GNU Classpath we decided to throw in the exception, to lower that wall. That meant loosing strong copyleft, but enlarging the community for this specific goal. At the moment patent reciprocity seems like a similar thing. > I think the ASF will have a revised policy before the end of the year > that will allow Apache projects to do things such as linking with > Hibernate. We also are likely to have an "official" statement where we > say that the LPGL and the AL are considered to be completely > compatible from a legal POV, and hopefully that will be a joint > statement from the ASF and the FSF. > > This means that GNU Classpath dual licensing under GPL+Exception and > the LPGL or re-licensing under the LGPL is likely to mean that we can > start using GNU Classpath as one of the possible class library > implementations for Harmony before the end of the year, so that is one > thing we should perhaps ask the classpath community to consider. > However, we can also wait with asking that question until the new > policy is "official" to avoid later dissapointment. > > Note this would kind-of be a one-way licensing bridge, eg Classpath > would still not be able to incorporate code developed at harmony into > their codebase (much like classpath currently can't take code licensed > only under the GPL since the copyright holders need to agree to that > exception first). Of course, there is never something which would > prevent individuals who contribute stuff to harmony to contribute that > same stuff to classpath and it is explicitly fine for the classpath > community to ask for stuff like that. OK. This is encouraging and interesting. We had GNU Classpath under the LGPL in the past. We changed it a couple of years back because we thought just having the GPL+exception was clearer and to encourage the gcc/embedded devices people to join. This was when we merged with libgcj. That was a good decision back then because it brought with it the whole GCC community that contributed a lot to the project. But if LGPL is more attractive to the Apache community then we should discuss how to get the best of both world (GPL+Exception and/or LGPL). I'll discuss and let you know about the options. I understand this is just a one-way bridge for the moment. But one-way is better then no-way. And it seems the most easily achievable one. I will keep in mind that this is just a proposal for now. But we should get more clarity about it half December I hope when some people meet at ApacheCon. > I read through some of my email archive about this. Cliff offered to > volunteer some time to look at the current classpath exception > statement in detail somewhere in December, however he also had a > better suggestion -- we ask the software freedom lawcenter people for > specific and pointed advice. I'm going to be composing a > history-of-the-discussions-so-far as well as a list of specific > questions about what the problem might or might not be, what the > alternatives are and what the "policy implications" of those > alternatives would be, and we're going to get legal counsel to ponder > those questions. > > The timetable is likely going to be "month and a half for Leo and > Cliff to figure out the right questions", "two months for several > lawyers to provide some answers", and then depending on the answers > compatibility may take a lot longer. Cliff indicated that it might be > the case that we will have to wait for GPL v3 and then even after that > a small revision of the apache license might be needed. If so, we are > talking about end-2007 or something like that before harmony could > ship software linked against classpath. I don't know yet, whether that > is the case. The Software Freedom Lawcenter is a good idea. They seem very good and respected by a lot of people. They could be a kind of neutral party in this discussion. This and the GPLv3/ASLv3 discussions are clearly long-term. But I would like to explore the options and help out with this. > > While the above "legal limbo" distributing a combined ASLv2/GPLv2 > > code base as a larger work isn't clarified it is impossible to > > include any harmony code distributed under the ASLv2 in GNU > > Classpath. That is why we ask all contributors to make sure their > > contributions also available under terms that are GPLv2-compatible > > like W3C/MIT/X/etc. > > Indeed, and understood. The ASF as a foundation that provides a stable > legal umbrella is not going to ask that of contributors, however there > is no issue with others in the harmony community doing exactly this. > There is also no issue with changing our IP clearing framework to > allow for a "this is also MIT licensed" checkbox, we "just" need to > make real clear that it is a contributor's choice to do that and it is > not required for participation, that there are several implications > when doing this (like opening up some patent licensing holes) which > the contributor should realize, and this is not the mode of operation > "by default" (the default is that a contribtor provides stuff under > the relevant CCLA/CLA and we license under the Apache License). > > Also its going to be very hard to keep MIT-licensed contributions > neatly seperate from the Apache-licensed stuff as our trunk rolls > forward -- and if we have a mix of MIT licensed and apache-licensed > stuff then the combined work is apache-licensed. So it'd be up to > whomever wants to integrate stuff from harmony under a MIT license to > track the codebase very closely to figure out what they can and cannot > use -- as a lot of stuff is not going to be available under the MIT > license. This is all very positive. I am not too afraid of the tracking of things. There will be paperwork done anyway for each contribution and each contributor. I see it as just a little bit more stuff to track. We do something similar for GNU Classpath already. But maybe I am underestimating. Seems like the first thing to do is to get an official IBM response through Geir on the idea of handling the core classes contribution that way. If that goes smoothly then we have a good template for dealing with this kind of thing for the future. Let me know how I can help. > hpff. I hope I got that right. No promises though :-) Understood and thanks! I go and run with a couple of these suggestions and let you know what others are thinking. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
