Woah... this is a bit much for me to troll over at the moment... but here
are some comments based on a brief look.
First, I don't really care about the details of debian stuff. If you do
that is greate.
Sounds like we need to split up these non-free bits from the free bits. I
am all for that. How do we do that and still allow the build system to
work with little to no user or bs/lib maintainer overhead?
It looks like there is no way jboss could be put directly into 'main', since
it depends on non-free software "to do what it sets out to do". So I would
guess it would go into contrib, honestly I don't really care which module it
goes into.
It would be nice if evey debian os came with JBoss by default if the user
wants J2EE, JMX or advanced java server support, but why not simply provide
our own packages, and provide docs on the lines to add to the apt-get config
file?
Why do we need to provide a source package which contains all 'free' only
sources? If you need to do that, simply take a release from
'jboss-all/build/build.sh release', strip out the bits you deem non-free,
hook those non-free bits up into the dependencies, then turn what is left
over into a package.
If you really need a untouched release from JBoss with out these, then we
need to think about how that would be possible, if that would be possible.
I think that JBoss will eventually have to worry about these distribution
licensing issues, which may lead us to forcing a physical seperation from
free and non-free bits which are required to run the server. I don't have
time to even figure out what to bits are, but I could make time to take that
infomration and devise a plan to augment the build system to handle it,
assuming that the distribution mechansim will not have an adverse affect on
our users.
So, I don't mean to dis you long email, but I don't really have time to get
into the debian'ism which you are working with. I am willing to look at the
thirdparty seperation, but to make a change like that probably will not be
swift... though it might be better to make such a change before any 3.0 is
released.
I am open to ideas on how to seperate these, though I can tell you that
things like 'go download x from x.com, y from y.com' and so on will not fly.
I would expect that if this worked at all it would be, here is the
jboss-xxx.zip with LGPL and here is jboss-thirdparty-xxx.zip with (long list
of varing licenses which allow us to distribute it).
A user would then unzip each at the same level and have a happy release to
start using.
--jason
On Thu, 15 Nov 2001, Adam Heath wrote:
> 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
