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
