non-free vs. free packages

Wed Oct 19 12:27:57 UTC 2005

On Tuesday 18 October 2005 06:00 pm, Stefan Wold wrote:
> 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
>

IANAL so there might be some finer points flying by me, so if there are any 
Lunar lawyers about feel free to jump in with clarification.

I personally do not see the need to split the moonbase in any shape for form 
to accommodate non-free packages. To reiterate, all Lunar does is provide an 
easy mechanism for a user to download and install software. Aside from the 
ISO, Lunar does not store any of this software prior to it's download.

Some applications have been gracious to allow their software to be downloaded 
without the need to physically visit their site, run through some legalese 
before being sent to their download page. The j2sdk module comes to mind. In 
this instance the lunar user *still* must acknowledge their license before it 
can be installed.

I do not see why a similar method cannot be used with non-free modules. It may 
require a user to still visit the non-free site and run through their 
legalese before downloading and that to be would be fine. Then the module 
could be constructed to tell the user this is what they must do and to save 
it in some particular location. Which it would then do something similar to 
"lin --from $SAVED_LOCATION".

From a centralization point of view it might be handy to create a new 
directory in moonbase called "non-free" or whatever just so it's easy to look 
at the tree and see where all those type modules live.

So for those packages the will not allow us to cache them or download them 
remotely. The simplest answer to this is construct the module telling the 
user what *they* need to do and once done, it will perform the install.

Which is pretty much what we do now.

> 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
>
> _______________________________________________
> Lunar mailing list
> Lunar at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar