Return-Path: Delivered-To: apmail-repository-archive@www.apache.org Received: (qmail 90134 invoked from network); 8 Jan 2006 14:18:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Jan 2006 14:18:23 -0000 Received: (qmail 7920 invoked by uid 500); 8 Jan 2006 14:18:22 -0000 Delivered-To: apmail-repository-archive@apache.org Received: (qmail 7859 invoked by uid 500); 8 Jan 2006 14:18:21 -0000 Mailing-List: contact repository-help@apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: repository@apache.org List-Id: Delivered-To: mailing list repository@apache.org Received: (qmail 7848 invoked by uid 99); 8 Jan 2006 14:18:21 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Jan 2006 06:18:21 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of gcjr-repository@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Jan 2006 06:18:19 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EvbMm-0007qC-Fk for repository@apache.org; Sun, 08 Jan 2006 15:17:52 +0100 Received: from p54A5538F.dip.t-dialin.net ([84.165.83.143]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Jan 2006 15:17:52 +0100 Received: from robilad by p54A5538F.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Jan 2006 15:17:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: repository@apache.org From: Dalibor Topic Subject: Re: Making a redist of all the javax.* packages Date: Sun, 8 Jan 2006 14:17:37 +0000 (UTC) Lines: 70 Message-ID: References: <43B934E4.4050703@apache.org> <43B955F6.5090407@apache.org> <43B95C39.5070206@maven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 84.165.83.143 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051010 Firefox/1.0.7 (Ubuntu package 1.0.7)) Sender: news X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Jason van Zyl maven.org> writes: > > Hi, > > This is something I tried to rectify more then four years. I talked to > some people at Sun in addition to Geir talking to some people at Sun and > here's the quick summary. > > 1. Sun has never changed the license for things like JavaMail because > although it is technically illegal to make Sun Binary License artifacts > available outside a distribtion, Sun is not going to go after anyone. Hi Jason, Last time I saw people saying "sure the license says it, but they are not going to go after anyone" (JDocs.com) the thing ended up with Sun calling the folks and making sure they stopped flgrantly violating their license. Business is business. It was a different license from the BCL, though, but pretty clearly violated and Sun put a stop to it. Sun has enforced their licenses and trademarks in the past when they believed it was necessary, and that's not likely to change. If Sun would not reserve the right to enforce the licensing terms, they would release their implementations into public domain, or release them under different licenses. > 2. If you can provide the user with the license verbatim as they would > see it downloading from Sun and provide a click through then all the > legal requirements are satisfied. Only if you are able to act as an agent for Sun Microsystems (for which you'd need a distribution contract with Sun Microsystems, I assume). The licensing agreement is an explicite contract between Sun Microsystems and the user, and as it requires explicit consent from the user, you have to be acting as the agent of Sun Microsystem for a valid contract to be formed. No valid contract, no license to use -> the user is in legal risk because he's using proprietary software without license. That's no different from the user buying a Microsoft Windows XP Pro CD on a flea market in Bosnia: the user may have successfully formed a contract with the 'pirate', but unless he has formed a contract with Microsoft, he has no right to use the copy. > I think a better use of our collective time would be to create a small > tool which cataloged the location of the SBL JARs and showed the user > the license and allowed them to agree to the presented terms and > continue with the build. In this mode we are operating in a legal > fashion and not trying to circumvent SBL even though this is a > ridiculous situation which SUN has never addressed. > > I think creating a small tool to semi-automate the click through > agreement would be the optimal solution. > There is no lack of such tools. That's like any packaging of JDK for a Linux distribution that does not involve manually downloading it from a proprietary runtime vendor site, and agreeing to the licenses in a proprietary-vendor-sanctioned way. They have also been ocassionally shut down by the legal teams of proprietary Java vendors and their legality is dubious at best for the reasons I gave above. See http://journal.boblycat.org/karltk/archives/entry-000272.html for an example (Gentoo, IBM JDK for PowerPC-GNU/Linux). Yes, Java Technlogy licensing is a mess. That's one of the reasons why people are busy writing better implementations of the proprietary "w4r3z" as free software in various projects inside and outside Apache. cheers, dalibor topic