non-free vs. free packages

[Steven Michalske]

Honestly,  lin to me means that we have a simple to use non bloated  
package management system that works with our core configuration on  
Lunar.

Our preference is source based packages, although over time we have  
included binaries for numbers of reasons, all acceptable imho, its  
about ease of use.   there are cases where download licancing  
restricts us so that we cant easily offer a module.  although manual  
download shouldn't be left out of our package management system.   
lunar is a tool for installing software for us to use,  even if there  
is an easy button graphical installer,  i rather lunar do it for me,  
with the behind the scenes scripted method.

there have been times where i have gone to great lengths to install  
software, although i rather have had a simple lin method to do it, so  
i write it once in module form, so when i want to upgrade it lin does  
it for me.  for those one offs that i don't thionk any one will use i  
leave them in zlocal,  others that i thought never would get  
installed i have seen others version bump for me, so people like all  
kinds of modules.

If a war of licenses is to come from this then the best way to  
implement it i feel now would be a non-free section of the moonbase,   
that includes the licenses with the module and prompts for  
acceptance.  this way we are free from liability by showing the  
modules licenses.  also we shoudl cache which licences the user has  
accepted.

this can be done with the plugin methodology to prevent bloat on the  
free only lunar machines.

hardkrash

On Oct 17, 2005, at 3:27 PM, Couannette wrote:

> Zbigniew Luszpinski a écrit :
>
>>> Hello all,
>>>
>>> One way to handle the free vs. non-free is to separate (a la a few
>>> distributions) the non-free from the free into dispirate downloads.
>>> e.g. have a moonbase-nonfree where modules such as nvidia_driver,
>>> j2sdk, etc. can go. You can also add warnings to these packages that
>>> tell a user they need to go do a few jigs around a maypole before  
>>> they
>>> can use it and to not forget the sacrificial chicken.
>>>
>>> The best way, I've found, is to keep the non-free as separate  
>>> from the
>>> free as possible and to even setup guidelines to define what 'free'
>>> and 'non-free' mean to you as a group.
>>>
>>> -sandalle
>>>
>>
>>
>> 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.
>>
>> greets,
>> Zbigniew 'zbiggy' Luszpinski
>>
>
> Sorry Zbigniew but I'm forced to not agree with you.
>
> I think *modules* are for "software modules" that you want  
> installed in your
> Lunar. Either source or binary.
>
> The goal is to USE softwares I think, not to discuss endlessly  
> about their
> licenses. If some software has a terrible restrictive license don't  
> bother /
> loose your time making a "machine à gaz" to handle this problem,  
> and to quote
> cmak : let our vastly superior users figure things out  :), looool.
>
> By the way I like sandalle's idea. A simple directory in Moonbase  
> could handle
> all that stuff ;). Or a flag in DETAILS like NON_FREE=yes.
>
> Cheers,
> Couannette
>
> _______________________________________________
> Lunar mailing list
> Lunar at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar
>