non-free vs. free packages

[Stefan Wold]

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 
harddrive.

I say keep it simple, because that is what most of our users would expect 
and nothing less.

Over and out.

Ratler
lunar/developer


On Tue, 18 Oct 2005, Eric Sandall wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, 17 Oct 2005, Zbigniew Luszpinski wrote:
> <snip>
>> IMHO:
>> 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)
>
> iD4DBQFDVVU4HXt9dKjv3WERArp1AJidtce9CKMOQIxzvgsy0ZGRN3PdAKCYyIs0
> brsH5yle+16ccOU+lEN5vg==
> =biNy
> -----END PGP SIGNATURE-----
> _______________________________________________
> Lunar mailing list
> Lunar at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar
>