non-free vs. free packages

[Couannette]

Dennis Veatch a écrit :
> 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.

I LIKE this !

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

Really clear IMHO.

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

Thus we should free the users from any new and error-prone method of handling
those non-free modules. We just have to inform them on a per module basic off
licensing restrictions (i.e. with a DETAILS's field, that's the simplest way I
think).

You all will fell that everything as been said about this topic.

Best regards,
Couannette

PS: non-free modules are very usefull software, if not we would not discuss
about this, isn't it ;^) ?