Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 22330 invoked from network); 5 Dec 2005 14:46:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Dec 2005 14:46:29 -0000 Received: (qmail 88354 invoked by uid 500); 5 Dec 2005 14:46:21 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 88292 invoked by uid 500); 5 Dec 2005 14:46:20 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 88273 invoked by uid 99); 5 Dec 2005 14:46:20 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2005 06:46:20 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of davanum@gmail.com designates 66.249.82.204 as permitted sender) Received: from [66.249.82.204] (HELO xproxy.gmail.com) (66.249.82.204) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2005 06:46:19 -0800 Received: by xproxy.gmail.com with SMTP id s12so565581wxc for ; Mon, 05 Dec 2005 06:45:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=auq3dBqPBN26TRyQsND7VuZqTNJL/Jv0OQc+hKl7x9GUYxriAfA99WcizaRvcDZGzuarRe8+GQygP0tA0fd4aNl8L4JLe9azihKhkdzseluWdtzldG5D4de0UUeYIgO6EF/2O11yKaJL0vmeEbuIBmCG7FN8rHhMYpY6FHxIK1o= Received: by 10.11.122.53 with SMTP id u53mr124046cwc; Mon, 05 Dec 2005 06:45:58 -0800 (PST) Received: by 10.11.122.64 with HTTP; Mon, 5 Dec 2005 06:45:58 -0800 (PST) Message-ID: <19e0530f0512050645y1f6d1925p8df8b95571ffba14@mail.gmail.com> Date: Mon, 5 Dec 2005 09:45:58 -0500 From: Davanum Srinivas Reply-To: dims@apache.org To: Mark Wielaard Subject: Re: [Licensing/Community] Fresh start Cc: harmony-dev@incubator.apache.org In-Reply-To: <1133792890.6134.137.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <19e0530f0512041050h62dad4b3v6bace1e1886cd68d@mail.gmail.com> <1133792890.6134.137.camel@localhost.localdomain> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Mark, Personally, i'd like to see progress on the "VM Interface" ASAP, that would go a long way to removing the mistrust. That would enable harmony VM to use unmodified classpath stuff as-is for development purposes and can act as a firewall till the licenses get sorted out. See snippet from Leo's email: "Mark told me someone tried something like that a year or two ago already. I forgot whom or what it was called, but I'd suggest trying to learn about it and if it failed, why." If i see some componentization such that i can drop in say xalan/xerces and not use classpath's built-in stuff (this would end users can mix and match stuff to make their distribution) that would be even better. But "VM Interface" is priority #1. Thanks, dims On 12/5/05, Mark Wielaard wrote: > Hi Davanum, > > On Sun, 2005-12-04 at 13:50 -0500, Davanum Srinivas wrote: > > Just remember, it has to go both ways :) Apache code in classpath and > > classpath code in Harmony. We can't just push things so that it is a > > one way street. So far what i have not heard is how/what can be done > > to enable Classpath to use the tons of jakarta code and other Apache > > code. > > > > How about a plan of attack? Anthony, Dalibor and Mark can try hard to > > lobby FSF's GPL v3 effort to be as compatible as possible with ASL > > 2.0? In the mean while, we can take up Stefano's offer of working on a > > VM interface. If we get thru in one piece till GPL v3 gets out, then > > we can investigate if Classpath can switch to use Xerces/Xalan etc > > from Apache. In the parallel, let's see how LGPL bridge policy works > > in the real world usage (once Apache-Legal formulates it and announces > > it). At that point we can eval options on both sides and see how best > > to go forward. > > Thanks for pointing out the obvious. I have been reading a lot, but not > really found I way to make sense of where/why we aren't working more > together as a team :{ I changed the subject a little because I believe > this is not just some "legal/licensing" thing. It feels much more like a > community thing. Somehow we seem to mistrust each other. And I don't > really know how that happened. Ever since I became maintainer of GNU > Classpath I have worked hard to enlarge the community and work together > by cooperating with as many existing communities as possible. That was > also my intention when I joined the Harmony initiative. But instead of > having created a larger community we seem to have created communities > that are unsure of the goals of the other. While at the same time we do > seem to have the same goal, but we are not acting like we are. > > I think we should split up the "legal/community" issues into the > following "subprojects" (I already tried to discuss this in private with > some people to get a better understanding, but maybe it is better to > throw this out into the group). Each of these points is not just a > "licensing" issue, but also a "community" issue since I feel that we can > only solve it if we understand why the different communities feel these > things are important. I have tried to explain it from "my side" a bit > below. Input on other viewpoints are very welcome. > > - Understanding the acceptable dependencies of code distributed under > various licenses for the various groups. For GNU projects and most other > Free Software projects I know it is mostly anything goes as long as it > is upwards compatible with the GPL (with a preference on the FSF to have > a clear legal trail and possible copyright assignment). [Unfortunately > this doesn't include the ASL which is one of the main sticking points. > And why various people have asked the key contributors to make sure > their contributions are (also) available under GPL-compatible terms. > Geir has been talking to IBM about this.] The precise "rules" for the > ASF seem still under heavy discussion. Maybe this will be discussed more > at the ApacheCon next week. > > - Starting from the understanding of the point above it would be good to > get a clear view of how the LGPL fits into that. It looks like many > Apache projects would like to build upon existing LGPL code bases, but > are not sure what the requirements are. I know we talked a lot about > this before, but I am not clear where we stand, or which uncertainties > still seem to exist. This is probably not possible to do before the > previous item is clearly understood. But if it is resolved and > acceptable to the apache community then we can certainly look into > making sure GNU Classpath code is also available under the LGPL, but see > next point. > > - The FSF has been using exceptions for runtime libraries for > GCC, like the one for GNU Classpath, to the GPL. The intent was to have > a more easy to understand license for these kind of runtime libraries > which is similar in spirit to the LGPL, but with a couple of freedoms > removed (especially the relinking/shared library requirement for the end > user). But it seems this exception is even less well understood then the > LGPL even though people seem to have been using such runtime libraries > for a very years through GCC. We can have a long debate about the > precise legal wording, but it is unclear why there is so much > confusion/distrust about the intent in some groups. Long time GCC users > and distributors don't seem to have any doubts about it as far as I can > see. When the LGPL issue is resolved it will probably be easy to solve > this one also. > > - In the long run it would be good to get the ASL and GPL compatible > through the GPLv3 process. This does not help us in the short term > though (release date 2007). I talked to various FSF people, including > Richard Stallman, and the goal clearly is to get them compatible through > the process (even if it is too early to tell whether or not that can > happen as is, or whether there are also small changes needed to the > ASL). Richard asked me to make sure the people were aware of that and > participate in this process. http://gplv3.fsf.org/ > > - Seeing that the GPLv3 process will take more than a year, is there any > way to create temporary bridges between code bases distributed under the > various licenses? Some clear wording to unambiguously make ASLv2 and > GPLv2 code mixable would be nice. I have no idea if that is possible. It > was clearly the intent of the ASLv2 to make this possible, but I don't > know if there is any simple clarification to make this also legally so. > > What do people think of the above? Are these the things that are truly > blocking participation between the groups? They feel a bit too > legal-mumble-jumbo to me, but I don't know how to reword them more as > community participation issues. > > Cheers, > > Mark > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBDlE55xVhZCJWr9QwRAvAXAJ4kdQ3sB5Fx6Ir3t351EQalUY+M7gCfd4sc > rl9S2w/mZDv2h5/3S//Wd8c=3D > =3D5qOt > -----END PGP SIGNATURE----- > > > -- Davanum Srinivas : http://wso2.com/blogs/