On Thu, 2005-09-22 at 11:46 -0500, Brian Harring wrote: > Actually, it does have to deal with glep23, and you already stated in > one of you emails (an "interim solution *now* since I've not heard > anything from GLEP23 for some time").
This is an interim solution only in that it flags a package as commercial until there is some kind of group created to fill that role. Personally, I don't think a group *should* be created for commercial licenses, as they are *not* equal in any way and should be judged individually, rather than as a group. In that case, this would be a permanent solution. > Further, where do you think you're going to migrate the check for this > license to? We wouldn't check for *this* license. We would be checking for the *real* license. So rather than using "check_license" in pkg_setup, we would be using "check_license Q3AEULA". As for where it will eventually migrate (ala GLEP23), I don't know, and honestly, it isn't my concern. > FYI, accept_license checks have been sitting in svn/cvs for about a > month, same as use deps. No, you can't use them now in a released > portage, but that's not much of a reason to introduce a fake license > I'm sitting. Further, a better approach instead of people adhocing > yet another band aid in the tree would be to chip in- you want glep23? Yes, I want GLEP23, but as I have said, I think this *could* be a permanent solution, if used properly. > help bring the *proper*, agreed upon solution to a stable portage, not > taking the easier route. OK. I'm going to ask a question of you. If you do an "emerge -S doom3" on your system, how would you know that the DOOM3 license is a commercial license? How would you know the difference between "doom3" and "doom3-demo", which happen to have the *exact* same license? How would you know that "doom3" requires a purchase? How would GLEP23 resolve this? Now, if you can give me a solution other than the one that I have provided, then I'll gladly accept it. As it stands, I only see one way to provide this information to our users, and that is to add it *somehow* into the ebuilds. This means either via LICENSE or some new variable. The advantage to using LICENSE is that it works *now* on all versions of portage. It also works *now* on packages.gentoo.org's pages. > The suggested intention of this fake license is also a bit daft imo; > what is LICENSE, the metadata? The license the underlying pkg is > released under. Commercial is supposed to be mean "it costs money", > well, how are you going to deal with opera? Flip off the commercial > license now? On the ebuilds for the versions released as free versions, yes. > The original proposed angle (glep23 implementation isn't here) is > jumping the gun, and the angle of "it indicates it costs money" isn't > proper either. > > You want to indicate that this *specific* pkg costs money > (something not related to the license it's released under I might > add)? Stick it in metadata.xml or DESCRIPTION. Description is the worst place for it, IMO. I'd have no problem sticking it in metadata.xml, either, but tell me how users are to get that information? As it stands now, the only data in metadata.xml that is used for *anything* is the herd/maintainer information, and that information isn't available from portage, but only from external 3rd-party applications and jeeves. > License has a specific meaning- aside from the fact you're shoving an > additional license requirement on people when glep23 hits, you're also > blocking anyone from using that as a license group do to the fact you > already introduced a psuedo license in instead of a *proper* groupping. As I've stated, there should not be a commercial grouping, as each license is *not* equal in any way other than being commercial. Things like GPL-COMPATIBLE share something. Commercial licenses can be absolutely diverse. > So... my 2 cents? No (was obvious already, wasn't it? :) Great. Give me another way to let the user know that the package requires a purchase or obtaining a license that we cannot provide them. -- Chris Gianelloni Release Engineering - Strategic Lead Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
