Return-Path: Delivered-To: apmail-jcp-open-archive@www.apache.org Received: (qmail 30794 invoked from network); 27 Feb 2006 10:48:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 Feb 2006 10:48:43 -0000 Received: (qmail 5525 invoked by uid 500); 27 Feb 2006 10:48:42 -0000 Delivered-To: apmail-jcp-open-archive@apache.org Received: (qmail 5481 invoked by uid 500); 27 Feb 2006 10:48:42 -0000 Mailing-List: contact jcp-open-help@apache.org; run by ezmlm Precedence: bulk Reply-To: jcp-open@apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list jcp-open@apache.org Received: (qmail 5472 invoked by uid 99); 27 Feb 2006 10:48:41 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Feb 2006 02:48:41 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [192.6.10.2] (HELO colossus.hpl.hp.com) (192.6.10.2) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Feb 2006 02:48:40 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by colossus.hpl.hp.com (Postfix) with ESMTP id 1F0296B9D6 for ; Mon, 27 Feb 2006 10:48:19 +0000 (GMT) Received: from colossus.hpl.hp.com ([127.0.0.1]) by localhost (colossus.hpl.hp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32558-07 for ; Mon, 27 Feb 2006 10:48:18 +0000 (GMT) Received: from kropotkin.hpl.hp.com (kropotkin.hpl.hp.com [15.144.59.2]) by colossus.hpl.hp.com (Postfix) with ESMTP id 7CD7A6B9D5 for ; Mon, 27 Feb 2006 10:48:17 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by kropotkin.hpl.hp.com (Postfix) with ESMTP id 46A43538A for ; Mon, 27 Feb 2006 10:48:17 +0000 (GMT) Received: from kropotkin.hpl.hp.com ([127.0.0.1]) by localhost (kropotki [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14503-01-2 for ; Mon, 27 Feb 2006 10:48:13 +0000 (GMT) Received: from timmay.hpl.hp.com (timmay.hpl.hp.com [15.144.30.251]) by kropotkin.hpl.hp.com (Postfix) with ESMTP id E51108FC3 for ; Mon, 27 Feb 2006 10:48:12 +0000 (GMT) Received: from [15.144.25.135] (chamonix.hpl.hp.com [15.144.25.135]) by timmay.hpl.hp.com (8.13.2/8.13.2) with ESMTP id k1RAm9t2015615 for ; Mon, 27 Feb 2006 10:48:09 GMT Message-ID: <4402D8E8.70504@apache.org> Date: Mon, 27 Feb 2006 10:48:08 +0000 From: Steve Loughran User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: jcp-open@apache.org Subject: Re: JSR-198 up for final vote References: <43FA4C1E.9070107@pobox.com> <43FBE4F7.4020403@pobox.com> <43FC385D.2030509@apache.org> <43FCD666.1010005@pobox.com> <1DE9A10D-0FA8-4CB3-8202-5BA4D65EA89C@iq80.com> <43FE61CF.90504@pobox.com> <651D3BFB-9645-4994-9964-FE0BD97BC011@iq80.com> In-Reply-To: <651D3BFB-9645-4994-9964-FE0BD97BC011@iq80.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-HPLB-IMAP-MailScanner-Information: Please contact the Helpdesk for more information X-HPLB-IMAP-MailScanner: Found to be clean X-HPLB-IMAP-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5) X-Virus-Scanned: amavisd-new at kropotkin.hpl.hp.com X-Virus-Scanned: amavisd-new at hplb.hpl.hp.com X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Dain Sundstrom wrote: > On Feb 23, 2006, at 5:30 PM, Geir Magnusson Jr wrote: > >> Dain Sundstrom wrote: >>> On Feb 22, 2006, at 1:23 PM, Geir Magnusson Jr wrote: >>>>> And I suppose they are granting rights to compliant >>>>> implementations; it is only non-compliant rights that have to worry >>>>> about possibly infringing some software patent that oracle holds. >>>>> The trouble is: how do you define compliance? >>>> >>>> Passing the TCK. >>>> >>>> This got me thinking - I do wonder what Oracle has here - I guess a >>>> patent. I wonder how much that aspect matters since no one is going >>>> to implement this anyway except Sun and Oracle. >>> The patent clause is what worries me. With the patent restriction is >>> it possible to license an clean-room implementation under an OSI >>> license? I feel we should not support a JSR that doesn't a grant >>> field of use license to any derivative works of a complaint >>> implementation regardless of the derivative work being compliant or not. >> >> The JSPA says that's every JSR. > > If that is true, then Oracle's statement does not follow the JSPA. > Specifically this: > > under the JSPA, no copyright or patent licenses are granted for any > non-compliant > implementation made by downstream licensees, whether independent or > based on the reference implementation. > > I don't care about the copyright as we can just write our own > implementation of the specification, but if there are patents required > to implement the specification, downstream licensees of our code can not > make non-compliant implementations. To me that goes completely against > the definitions of OpenSource. Therefore, I don't think we should > support any JSR that includes such language. > > -dain This is a really serious issue, as it shows up in any standards body that I've ever got involved in. Patents can tear an org apart. Look at the fuss that arose when the W3C started thinking of a RAND license, which caused so much fuss (rightfully), that they killed that, which is one of the reasons why some specs now go to OASIS, and others to ECMA. (Eu computer manufacters association; says it all) Out in grid-land, all GGF meetings are preceeded by a declaration of IPR policy (you announce something, you are giving some rights to it), and they take a list of all attendees. Nobody wants a repetition of the great rambus/ddr debacle, in which something got standardised that rambus had a submarine patent on. Sunw hold some Java-related patents, specifically to do with code validation. Ignore code path validation (not the signing, but the bit where the validity of untrusted code is checked), and you don't have to care. If you do want to run untrusted code with less than full rights, then it starts to matter. So the Java VM spec itself must have some kind of patent burden. -steve