Ease up. I at least am relying on Marc's assurances that his (or JBoss Group's) lawyer checked out the licensing issues and we are ok. Issues with debian licensing policies are, well, periferal. It's pretty easy to get jboss as is, a debian packaging would be kind of nice but I don't see it as crucial. I don't know how debian is normally distributed but if its on cd it will only be distributing obsolet versions. Keeping up to date even online will be hard unless there is an automated update system. I don't understand the advantages of multiple distribution locations or mechanisms.
We are not jakarta-ant, where the committers appear to spend an appreciable fraction of their time vetoing each others proposals. Here, vote generally means "Lets do this, what do you think?". thanks david jencks On 2001.11.15 19:58:52 -0500 Andrew Scherpbier wrote: > Sorry to bud in here, but I think this statement is a little harsh. > I think these licensing issues that Adam raises are very relevant to all > of the JBoss project! JBoss is licensed under LGPL, right? So does > JBoss include JAXP? If not, then it certainly shouldn't be part of the > source distribution. If it is, then there are some licensing issues > that need to be worked out. (You can't just arbitrarily call someone > elses code licensed under LGPL!) > > I assume you meant 'rpm' (Redhat Package Manager). How do these issues > that Adam raises *not* affect any other sort of distribution, including > a windows installer or something like that? > > BTW, isn't voting about whether a debian package is allowed against the > LGPL? (Or at least the spirit of LGPL?) I am no licensing expert but > this seems like a weird solution to me and sound to me like you are > trying to ignore these serious licensing issues. > > Dain Sundstrom wrote: > > >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 > > > > -- > Andrew Scherpbier, CTO ([EMAIL PROTECTED]) > BlackBall Music (http://www.blackballmusic.com/) > > > > > _______________________________________________ > 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
