Hi, On Sun, 2005-05-08 at 00:44 -0700, Jason Brittain wrote: > * I have been watching the Kaffe and Classpath projects since their inception, > and wow, that's quite a bit of work they bit off for the sake of free Java. > Although the licenses don't work for me, I'm proud of them for sticking > with > it. And, I must congratulate them on being complete enough to run Tomcat. > This is the first OSS JVM I've ever been able to get Tomcat running on. > Keep up the exceptional work! > > http://article.gmane.org/gmane.comp.jakarta.tomcat.devel/51624/match=kaffe++tomcat
Thanks. > * Aside from dual-licensing, reimplementation seems to be the only way to have > the same kind of software available under more than one OSS license. And, > I believe the Apache licenses have a different and mutually exclusive > purpose > in life versus the (L)GPL licenses. Probably few codebases will be > dual-licensed AL and (L)GPL like the "tri-licensed" Mozilla browser, which > the > FSF describes as the "disjunction of the GPL and the MPL". > http://www.mozilla.org/MPL/ > Maybe I'm wrong here, but if Kaffe and Classpath were dual-licensed this > way, > wouldn't that be acceptable to all, except for the ASF politics of adopting > donated code? The intention of the current GNU Classpath license is to be acceptable to the Apache community. If it is not, then we are willing to discuss and eventually change it in a way so that it is. > * I believe that the AL and GPL have different goals that are mutually > exclusive. > It would sure solve some problems if they could one day be reconciled > enough > to consolidate major OSS projects like this. It's certainly worth trying. > But, people have been trying to get these two licenses to be compatible > enough > to collaborate for a long time and it still hasn't happened, so I have > serious > doubts that it happen. I am optimistic. There are currently talks on the highest levels of the FSF and ASF to get things finally cleared up. It looks like we will have a breakthrough soon. But it happens when it happens. Till then we will at least for the projects participating on Harmony make the best of it. > * I have chosen not to contribute to Kaffe nor to Classpath, solely due to > their licenses. Yes, I'm aware that Classpath's license is GPL with > exceptions to make it not GPL anymore. But, to me, it's either GPL or it's > not GPL. If it's not the GPL, I don't understand why the FSF would want to > help. The FSF worded the GPL carefully and deliberately to achieve certain > goals. Removing the viralness of the GPL undermines restrictions that the > FSF > seems to want in there. This changes the license significantly. It's not > actually the GPL. It's close, but it's probably more like the LGPL, which > is also not the license that the Classpath project members chose. Yes, the FSF and GNU projects like to use pure unadulterate GPL whenever they can. But that doesn't mean they don't want to compromise when that is of strategic interest. For GNU Classpath we have adapted the license two times already to appeal to a wider audience. We are willing to do that again if necessary. Dalibor and I had a little discussion session about the GNU community, the GPL, making compromises and working with other communities a while ago: http://www.klomp.org/mark/classpath/CommunityGPLCompromise/ As you can see one of the participants was Geir. That is one of the reasons we are now talking about Harmony. > I also do not find the GPL as free as > the AL or BSD-style licenses due mainly to the viralness, which is there > for > reasons that I understand, but in the end it's just unacceptable for the > Java code that I write and the ways I need/want to use it. We all make different compromises. And we all want to do the best for our respective GNU or Apache communities. That is something we have to respect. So I am sure we won't cooperate on everything. But I do hope we will cooperate on most things and make the results usable to both the Apache and the GNU worlds. > * It sure seems like the about only time the committers of a GPL or LGPL Java > project spend time seriously considering the terms of their chosen license > is > when they hear about an Apache licensed project with the same goals that is > getting some resources and attention. In the absence of the Apache > licensed > project, I've asked about BSD-style relicensing or dual-licensing and it's > just out of the question (to be clear, I never asked for a BSD licensed > Kaffe > nor Classpath, but other (L)GPL'd projects that will remain unnamed). I've > often been told "there's nothing wrong with the (L)GPL, it's plenty free > enough and we're not changing it". I've all but given up asking. But, > then > when enough people give up waiting and asking, and have to have it licensed > as BSD-style, and form a new project to just reimplement all of it because > there is no other option, then lots of GPL developers seem more interested > in > discussing collaboration again. I wish this wasn't a recurring pattern. We do feel the same pain "on the other side". Often the first reaction of someone pointing out a Apache licensed code base is to say "O, no! That would be nice to use, but I am sure if we asked to distribute under a acceptable license they get mad. Lets not have a flameware. Lets not ask. Lets start our own thing." That is sad, but it happens. And sometimes it happens for good technical reasons. But often it happens because of some legal technicality. It would indeed be great if that could be solved not just in project Harmony, but also on a bigger FSF/ASF scale. > * I like the Apache license all except for the attribution terms. Really, > guys, > do you think everyone would just forget that the ASF existed if the > attribution terms weren't in the license? To me it seems like a vanity > restriction placed on all licensees. If there's a good reason for it, I > wish I knew what it was. It's not a very big deal, but I wish OSS code > could be free of advertizing. But, also, hasn't this been one of the > barriers to GPL compatibility/collaboration since this is a license > restriction that the GPL doesn't have? Yes it was with the Apache License 1.1. This part has been solved by rewording it a bit so that it is technically GPL compatible in the 2.0 version. The only remaining difficulty with the 2.0 version is the precise wording of the patent retaliation clause. There were some other misunderstandings which have been worked out already. > Now, a suggestion for the Harmony project: > > - Any Java runtime can only safely implement one version of Java at a time. > For example, it's either Java 1.3 or it's Java 1.4. It can't be both. > Programs that run on the JVM often try to detect which version of Java > they're running on, and call appropriate methods based on the detected > version. If you target Java 1.5 now, by the time you get, say, one fourth > of the way to having it fully implemented, the latest stable version of > Java may be Java 2.3 (or something higher like that), and 1.5 won't seem > important anymore. If then you try to implement newer versions of some > core > classes to stay at least partially compatible with the latest stable Java, > then parts of the core will implement v1.5, and parts will implement v2.3, > and programs will end up being very confused about which version of Java > they're running on, and will break in random ways. I noticed this problem > with Kaffe, and I wanted to mention it here. Please, in any one binary > release of Harmony, make sure it attempts to implement exactly one version > of > Java. Note that this is the reason there is no GNU Classpath 1.0 release yet. We don't feel that it is a complete free replacement for the proprietary core class libraries just yet. The coverage is somewhere between 1.1 and 1.5, with some packages better then their proprietary counterparts, where others have just been started. Kaffe actually keeps a list of the progress they are making with the integrated effort: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-kaffe.html The problem here has always been whether or not we should just halt development and just forbid people to work on the parts they would really want to improve (maybe just because their application uses those parts, but not others). But that is just not how cooperative distributed development works. We are all volunteers and rejecting work that is technically good and useful is just not what we do. We could create different branches for work on 1.1, 1.2, 1.3, 1.4 and 1.5 work simultaniously. But this is a lot of extra work and maintanance for which we don't have the voluteers atm. We do have a separate branch for the new generics work in GNU Classpath though. We do have a volunteer that manages that branch. So we could certainly use someone that just made a GNU Classpath 1.1, 1.2, 1.3 and 1.4 'cuts'. Containing just those parts that could be considered part of the proprietary counterpart of the JDK. That is real work though. So we would need really dedicated volunteers that really can do that work of cutting up the unified release. We also don't want to see lots and lots of shattered releases that are all not really done. But there is a lot of important other work to do that might be more urgent to get done. Just focussing on getting full 1.4 and 1.5 coverage will certainly be multiple person-months of work. 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
