non-free vs. free packages
ratler at lunar-linux.org
Tue Oct 18 22:00:11 UTC 2005
I don't agree at all.
If we split up those modules that are binary or non-free too a second
base, how are the users supposed to install it? I saw someone mention that
we should rewrite lunar coretool to allow multiple download of different
"moonbases". Well that idea is pretty useless, why go through all the
trouble to split it up if our tool still allow you to download the
non-free modules just using an extra command?
If that is the case the difference between having only one moonbase
containing the non-free modules is hair thin. Let's say we split them up
but the users will have to manually download that tarball (Kinda like the
non-free stuff Striker has, that almost no one knows about) that is going
to hamper our userbase.
My point is, as long as the license for a binary/non-free application
doesn't explicity prohibit the use of it the way our package system work,
we should include it. Comparing lunar with debian is also vain, debian
always work backwards.
Take a look at OpenBSD, FreeBSD and Gentoo, all who have a ports system
just like our moonbase, ALL of them include jdk, opera, etc etc. Since we
really don't distribute any of the binaries there shouldn't be any legal
problems in most of the cases. Because in the end it's still the user who
decide what to download and not, and by downloading/installing they are
tied to the license, but not for having a module in the moonbase on their
I say keep it simple, because that is what most of our users would expect
and nothing less.
Over and out.
On Tue, 18 Oct 2005, Eric Sandall wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On Mon, 17 Oct 2005, Zbigniew Luszpinski wrote:
>> Do we really need non-free packages in moonbase?
>> Modules are mainly designed to provide information how to build source
>> packages. Non-free packages are usually binary and have their own binary
>> setup/installer/configurator - installation is done usually by running
>> installer which performs all needed operations automaticaly. So do not find
>> the need for existence of such modules in moonbase. There are so many cool
>> opensource modules that are outside moonbase which are much more worth
>> including than easy to install binaries.
> The problem with that is some 'free' packages will need some
> 'non-free' packages (e.g. eclipse, a 'free' package, needs some JAVA,
> a 'non-free' package). If you don't allow for even binary packages as
> a module then you cannot enforce this dependency.
> One way around it, as I mentioned, is to remove all non-free/binary
> modules from moonbase and add another 'base' that is not installed by
> default which has these. That way, be default, Lunar does not have any
> non-free packages (a la Debian), but people who want them can add the
> non-free repository. You'll also want to add repository dependencies
> in that case (so eclipse could depend on non-free/JAVA, otherwise a
> dependency on just 'JAVA' probably won't find it) that will install
> the non-free repository, if needed.
> - -sandalle
> - --
> Eric Sandall | Source Mage GNU/Linux Developer
> eric at sandall.us | http://www.sourcemage.org/
> http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
> http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> -----END PGP SIGNATURE-----
> Lunar mailing list
> Lunar at lunar-linux.org
More information about the Lunar