Re: JakartaOne : Plan
On Mon, 11 Mar 2002, Geir Magnusson Jr. wrote: | Enough people have expressed interest in Jakarta One that I believe we | should go forward, at least as a social gathering so we can see what we all | look like. Do you guys know about JBossOne? It's apparently going to be located right across the road from JavaOne.. I'm not sure though, and I haven't read all messages here lately, so it might have come up already.. -- Mvh, Endre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JakartaOne : Plan
On 3/12/02 6:36 AM, Endre Stølsvik [EMAIL PROTECTED] wrote: On Mon, 11 Mar 2002, Geir Magnusson Jr. wrote: | Enough people have expressed interest in Jakarta One that I believe we | should go forward, at least as a social gathering so we can see what we all | look like. Do you guys know about JBossOne? It's apparently going to be located right across the road from JavaOne.. I'm not sure though, and I haven't read all messages here lately, so it might have come up already.. Yes - they are having it during the day, as I understand it. I was hoping a few of them (or all of them :) would come and join us - since they are giving talks at JBossOne, it might be nice to see if they would repeat a talk or two at JakartaOne. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting POC lives! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JakartaOne : Plan
On Tue, 12 Mar 2002, Geir Magnusson Jr. wrote: | On 3/12/02 6:36 AM, Endre Stølsvik [EMAIL PROTECTED] wrote: | | On Mon, 11 Mar 2002, Geir Magnusson Jr. wrote: | | | Enough people have expressed interest in Jakarta One that I believe we | | should go forward, at least as a social gathering so we can see what we all | | look like. | | Do you guys know about JBossOne? It's apparently going to be located | right across the road from JavaOne.. I'm not sure though, and I haven't | read all messages here lately, so it might have come up already.. | | Yes - they are having it during the day, as I understand it. I was hoping a | few of them (or all of them :) would come and join us - since they are | giving talks at JBossOne, it might be nice to see if they would repeat a | talk or two at JakartaOne. You actually mentioned it in the same message I was replying to! How observant of me! ;) -- Mvh, Endre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
License issue (the come back)
Hello. They have been already *several* discussions about Sun proprietary APIs licenses, and more precisely about exact redistribution conditions. Current consensus in ASF, AFAIK, is that redistribution of crypto API (as jsse) is strictly forbidden, and redistribution of non-crypto APIS is not permitted with source code. We (jpackage project, http://jpackage.sourceforge.net) contacted sun legal department to have an official response on this topic. We exposed our own practices, that is to provide a non-free section for all normal APIs with standard packages, and a non-distributable section for all crypto APIs and JDKs, with empty packages. The only response we had was: read the license carefully :-) (kind of RTFM, actually) So we did, and here is the result non-free jaasBCL + LDS jaf BCL javahelpBCL + LDR javamailBCL + LDS jaxpBCL + LDS jdbc-stdext no license jimiBCL + LDS jms no license jndino license jta no license jtopen no package jts BCL + LD netbeans-java-extbinno license resolverno license non-distributable javacc ? jsseBCL + LD sun-jsdk1.3 BCL + LDS + LDR sun-jsdk1.4 BCL + LDS + LDR blackdown-jsdk1.3 BCL + LDS + LDR ibm-jsdk1.3 ? BCL means standard Binary Code License, which is the basic Sun Binary Code License for all software. Most java software add extra clauses, especially concerning redistribution, which are refered here as LDS (License to distribute software), LRD (License to distribute redistributables) and LD (License to distribute). Full citations of those clauses are included at the end of the message. no license means in current package only, and ? means uncertainity. My own interpretation follows: 1) There is nothing in any of those license making click-through procedure mandatory 2) There is no point having jsse and jts in different section are they are subject to exactly the same conditions 3) The US export laws enforcement clause is part of BCL, which apply to *all* packages, not only to crypto packages. 4) LDR refers to a a distributable section in README file, that was not found either in javahelp nor in JDKs The last point is the only real problem IMHO. Basically, it forbids to export software in free world ennemy countries TM. I don't know if making somone from such a country able to download software from a website could be considered software exportation, but considering the technical impossibility to prevent it, i doubt Sun itself could claims to fulfill it. Apart this problem, i still don't see what prevent distribution of all packages having at least one of those additional distribution clause (LD or LDS), as long as original license is preserved. LDR with a non-existent distributable section is not acceptable here. However, IANAL, and as I know ASF people have already stepped onto this problem, i would like your opinion here. Thanks for your help. LDS 2. License to Distribute Software. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java (TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Java applets or applications (Programs), (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. LD 1. License to Distribute. Sun grants you a non-exclusive, non-transferable, royalty-free, limited license to (a) use the binary form of the Software for the sole purpose of designing, developing and testing your JavaTM applets and applications intended to run on a compatible Java environment (the Programs), provided that the Programs add significant and primary functionality to the Software, and (b) reproduce and distribute the binary form of the Software through multiple tiers of distribution provided that you: (i) distribute the Software complete and unmodified; (ii) do not distribute additional software intended to
RE: License issue (the come back)
The last point is the only real problem IMHO. Basically, it forbids to export software in free world ennemy countries TM. I don't know if making somone from such a country able to download software from a website could be considered software exportation, but considering the technical impossibility to prevent it, i doubt Sun itself could claims to fulfill it. On the other hand it would be hard to prove that you exported it yourself to a banned country, and didn't provide it to a user in the continental US who then sent it abroad. It certainly seems unworkable in principle, and as a foreigner I wonder what the US lawmakers would consider to be adequate protection against downloading by evil foreigners. You can pretty much bet the farm that terrorists won't let licence conditions stop their plans. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
on 3/12/02 7:05 AM, Guillaume Rousse [EMAIL PROTECTED] wrote:
So we did, and here is the result
You didn't find licenses for a lot of software that has licenses...instead
of saying 'no license' which implies that it does not have a license, you
should have stated ('could not find a license')...
I went through the java.sun.com website and in about 30 seconds found the
licenses for the first 3 'no license' items below...you can do the rest of
the work...
non-free
jaasBCL + LDS
jafBCL
javahelpBCL + LDR
javamail BCL + LDS
jaxpBCL + LDS
jdbc-stdext no license
BCL
jimiBCL + LDS
jmsno license
BCL
jndino license
BCL
jtano license
jtopenno package
jtsBCL + LD
netbeans-java-extbinno license
resolverno license
non-distributable
javacc?
jsseBCL + LD
sun-jsdk1.3 BCL + LDS + LDR
sun-jsdk1.4BCL + LDS + LDR
blackdown-jsdk1.3 BCL + LDS + LDR
ibm-jsdk1.3?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JakartaOne
On Mon, 11 Mar 2002 15:19, Geir Magnusson Jr. wrote: Before we do the call for papers, does anyone really care? I would rather do nothing than do something lame. Serious show of hands here - if you will be in the area, and are interested in attending, say so. Feel free to send to me directly so we don't bomb the list with that kind of noise. I will post a summary. Love to come along and see some faces but melbournes a long way away ;) -- Cheers, Pete *--* | The best defense against logic is ignorance. | *--* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-poi/build/jakarta-poi/docs/apidocs/org/apache/poi/util - New directory
On Sat, 9 Mar 2002 01:14, Andrew C. Oliver wrote: As a future suggestion: probably at least one committer to every project should have access to the webserver. I know its important to protect it and all, but since there is currently no good alternative... It doesn't work otherwise. Trust me. In theory thats what your champion is supposed to do. ie Whoever is your champion does all the updating until you know the system enough and get given appropriate access/permissions/instructions. Bug them and all should flow ;) -- Cheers, Pete - First, we shape our tools, thereafter, they shape us. - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
I went through the java.sun.com website and in about 30 seconds found the licenses for the first 3 'no license' items below...you can do the rest of the work... Could you help us in such works since : - you were damn't fast on such hard task - you have many friends at Sun which could help you Don't forget that Guillaume and I are french and we may have sometimes problems in understanding all the subtilities of all the Sun licenses in english only. We'll be more than happy to have a french version of them. Nota that many others companies like IBM provide license in several languages to help their users / customers... BTW, Guillaume and I want to know if we could or couldn't make the Sun jars available via jpackage project next to others free jars, with the final goal to have a ready to use Java distribution which will be a great benefits for all the Java community, both developpers and users. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
The BCL states that you cannot make a distribution of the .jar file outside of your product. In other words, if you want to distribute the single .jar file, you can't do that. (i) distribute the Software complete and unmodified and only bundled as part of your Programs What about a dummy program - say Linux java installer - with minimal code ? If this is not acceptable, you can probably just redistribute ant or tomcat4, which make use of almost all those packages. Ant is the best vehicle, and very usefull to have it installed anyway. BTW, the clause 'complete and unmodified' is very interesting - does it refers to the jar or the whole binary package ( most people refer to the whole downloaded package as 'software', and the jar is a piece of it ). If so, tomcat and most other packages that include it are breaking the licences, since they repackage and include only the jar. 'Software' is previously defined as 'accompanying software and documentation and any error corrections provided by Sun (collectively Software) Even more fun is the restriction on creating 'java., javax., or sun.' packages. Does it mean that you're not allowed to include open source ( and clean room ) implementations of javax. pacakges if you include one of those licences ? The only possible conclusion is that software shouldn't be redistributed without a lawyer checking and aproving every included license, and we need a list of licenses that are acceptable for inclusion on packages we distribute ( from jakarta, xml, etc ), verified by a lawyer. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
on 3/12/02 4:41 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The only possible conclusion is that software shouldn't be redistributed without a lawyer checking and aproving every included license, and we need a list of licenses that are acceptable for inclusion on packages we distribute ( from jakarta, xml, etc ), verified by a lawyer. Costin Correct. We have setup [EMAIL PROTECTED] for that reason (this is also commonly discussed on [EMAIL PROTECTED] and [EMAIL PROTECTED]) and have setup pages like this one to help us track things... http://jakarta.apache.org/site/jars.html -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
On Tue, 12 Mar 2002, Jon Scott Stevens wrote: http://jakarta.apache.org/site/jars.html The problem is that the list should be reversed - i.e. what licences are _allowed_ and verified by a lawyer. And we have 2 issues - what jars are allowed in CVS, and what jars are allowed in the binary software we distribute. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: License issue (the come back)
on 3/12/02 5:02 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The problem is that the list should be reversed - i.e. what licences are _allowed_ and verified by a lawyer. And we have 2 issues - what jars are allowed in CVS, and what jars are allowed in the binary software we distribute. Costin We welcome your contributions. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
It has nothing to do with language barriers or who I know. - I went to each product on Sun's website. Ex: http://java.sun.com/products/jms/ ok - I clicked the 'Download' link on the left side navigation. Ex: http://java.sun.com/products/jms/docs.html ok - I clicked the 'continue' button on the page. Ex: Download the version 1.0.2b Source, API Documentation and Jar (the jar file has been added) ok - I looked at the license and the words Ex: You have chosen to download Java(TM) Message Service (JMS) API -- Javadoc 1.0.2b Sun Microsystems, Inc. Binary Code License Agreement And then you have to understand what is exactly BCL. I'm not a lawyer, english is not my primary language sorry, so 2 reasons to be more than carefull BTW, Guillaume and I want to know if we could or couldn't make the Sun jars available via jpackage project next to others free jars, with the final goal to have a ready to use Java distribution which will be a great benefits for all the Java community, both developpers and users. The BCL states that you cannot make a distribution of the .jar file outside of your product. In other words, if you want to distribute the single .jar file, you can't do that. Ok, so you confirm us that the Sun jars couldn't be used outside a real program and as such couldn't be part of a RPM distribution ? But what happen if that distribution use these jars (ie javamail) for REAL program (like Tomcat 4.x) ? (i) distribute the Software complete and unmodified and only bundled as part of your Programs 'Part of my program', could we see a distribution as a set of programs depending on BCL jars for both build, install and runtime ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: License issue (the come back)
We have setup [EMAIL PROTECTED] for that reason (this is also commonly discussed on [EMAIL PROTECTED] and [EMAIL PROTECTED]) and both list are not available to basic commiters ? have setup pages like this one to help us track things... http://jakarta.apache.org/site/jars.html Yes, but how could I find this page from homepage ? BTW, you could add to jaf exclusion : jaas, javahelp, javamail, jdbc-stdext, jimi, jms, jta, jts -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
