No wonder people bitch about Debian. I vote we forget the DEB and just build an RMP, which Debian can install.
-dain > -----Original Message----- > From: Adam Heath [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 15, 2001 6:20 PM > To: Jason Dillon > Cc: David Maplesden; JBoss Development > Subject: LONG: RE: [JBoss-dev] can't build jboss from cvs > > > On Thu, 15 Nov 2001, Adam Heath wrote: > > > > > Is everything in thirdparty exact copies of external > libraries, that get > > > > built, or just checked in pre-compiled version, or a > mixture of the two? > > > > > > Everything from thirdparty and tools are pre-compiled. > > > > This is bad. If these were to be in the tarball that was > used for building of > > Debian packages, then the source package could not be > uploaded to Debian. > > > > Please see my forthcoming mail, explaining this(I didn't > want to include it in > > this mail, because it would make it too cluttered). > > Please go read the Debian Social Contract(#1), and the Debian > Free Software > Guidelines(DFSG, #2), before continuing on with the rest of > this email. It > has some bearing on general nature of what follows. > > The reason I have been pushing so much for a release of JBoss > that will not > have the precompiled sources, is that these sources, while some being > non-free(I'll explain more about this in a bit), are not > under the control of > JBoss. JBoss should not be concerned with the issues that > occur with these > external entities, except when they affect JBoss. In Debian, > these packages > will not just affect JBoss, but affect all software that uses > them. This > means that each external entity should handle its own issues, > and they should > not be all lumped together with another. > > As far are Debian is concerned, JBoss can do whatever they > want, and can > distribute whatever JBoss wants. However, to actually have > JBoss become > included with Debian, all license issues have to be > resolved(either by using > free versions of software, or by placing a package into > contrib, and having > broken dependencies). > > Inclusion in Debian is a very worthwhile goal, as Debian is > arguably the > second largest linux distribution. In addition to that, > Debian is built on > the distributed free software development, on steroids. > Everything is done > online, in email, irc, and thru web. > > Inclusion into Debian main states something about the > software so included. > It states that the software is free, and only uses free > software to do what it > sets out to do. This is a very important statement to make. > > Inclusion into contrib is allowed for packages that > themselves are free, but > for whatever reason, depend on/use software that is not free. It is > understood, that if a free version of a non-free package was > available, then > the package in contrib would use that instead. > > Non-free precompiled/bundled code: > > There are several bundles items in thirdparty and tools, that > have restrictive > license, that forbid redistribution. For instance, lets > consider jaxp(#3): > > 1. LICENSE TO USE. Sun grants you a non-exclusive and > non-transferable > license for the internal use only of the accompanying > software and > documentation and any error corrections provided by Sun > (collectively > "Software"), by the number of users and the class of > computer hardware > for which the corresponding fee has been paid. > > Having this available in cvs, for download by end users, and > as part of the > precompiled tarball, in addition to the source download, goes against > "internal use only". However, in section 1 of the > supplemental agreement, > there is more discussion about this point. See below. > > 2. RESTRICTIONS. Software is confidential and > copyrighted. Title to > Software and all associated intellectual property > rights is retained by > Sun and/or its licensors. Except as specifically > authorized in any > Supplemental License Terms, you may not make copies of > Software, other > than a single copy of Software for archival purposes. Unless > enforcement is prohibited by applicable law, you may not modify, > decompile, or reverse engineer Software. You > acknowledge that Software > is not designed, licensed or intended for use in the design, > construction, operation or maintenance of any nuclear > facility. Sun > disclaims any express or implied warranty of fitness > for such uses. No > right, title or interest in or to any trademark, > service mark, logo or > trade name of Sun or its licensors is granted under > this Agreement. > > This section states that ".. you may not make copies .. other > than .. for > archival purposes." > > Also, "decompile" is not defined, and could be implied to > mean unjaring of the > embedded jaxp.jar. > > 7. Export Regulations. All Software and technical data > delivered under this > Agreement are subject to US export control laws and may > be subject to > export or import regulations in other countries. You > agree to comply > strictly with all such laws and regulations and > acknowledge that you > have the responsibility to obtain such licenses to > export, re-export, or > import as may be required after delivery to you. > > This could have ramifications if someone in an export > controlled regulated > country downloads JBoss, and, by extension, jaxp. > > In the supplemental license for jaxp, there are additional items to be > concerned about. > > 1. Software Internal Use and Development License Grant. > 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 internally and use internally the binary > form of the > Software, complete and unmodified, for the sole purpose > of designing, > developing and testing your Java applets and > applications ("Programs"). > > This section is just a long winded version of the first section 1. > > 2. License to Distribute Software. In addition to the > license granted in > Section 1 (Software Internal Use and Development > License Grant) of these > Supplemental Terms, subject to the terms and conditions of this > Agreement, including but not limited to Section 3 (Java > Technology > Restrictions), Sun grants you a non-exclusive, > non-transferable, limited > license to reproduce and distribute the Software in binary form, > provided that you (i) distribute the Software complete > and unmodified > and only bundled as part of your Programs, (ii) do not > distribute > additional software intended to replace any component(s) of the > Software, (iii) do not remove or alter any proprietary > legends or > notices contained in the Software, (iv) only distribute > the Software > subject to a license agreement that protects Sun's > interests consistent > with the terms contained in this Agreement, and (v) > 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. > > Again, "non-transferable" is listed here. This means that since JBoss > downloaded jaxp, accepted the license, and then bundled it, > that JBoss is ok > in doing so. However, if JBoss is uploaded to Debian, then > it would mean that > a transfer has taken place, and this is not allowed. > > (i) states that the software must be distributed > "unmodified". However, > unmodified is not defined, and could be taken to mean the > actual file that is > fetched from sun's website, and NOT the embedded jaxp.jar > inside the zip. > > (ii) means that there can not be 2 different jaxp > implementations, which can > be switched at build/compile time. This isn't so bad, as if > there was a free > jaxp implementation, the non-free jaxp from sun would just be dropped. > > (iv) is problematic as well, as I do not see reference to jaxp in > documentation for JBoss. > > (v) could be quite costly for JBoss. If, sun wants to enforce this > aggreement, and finds JBoss breaking this agreement, then > JBoss is responsible > for payment of damages and other associated costs. In some > situations, JBoss > doesn't even have to break this agreement, for these costs to occur. > > 1: http://www.debian.org/social_contract > 2: http://www.debian.org/social_contract#guidelines > 3: http://java.sun.com/xml/jaxp/ > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
