Re: [gentoo-dev] "Commercial" software in portage

[Brian Harring <ferringb@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6942 bytes --]

On Thu, Sep 22, 2005 at 01:30:00PM -0400, Chris Gianelloni wrote:
> 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.

Yet what you're proposing *is* a marker on packages as "this is 
commercial", in effect a license grouping that's not properly 
implemented.

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

It's actually your concern whether you realize it or not.

Your idea of just ignoring "commercial" if it appears in 
license.split() means that ACCEPT_LICENSE implementation now gets 
screwed with, and has to start maintaining a whitelist of 
strings to exempt from checks.

Why is this an issue?  LICENSE field isn't a "one of the licenses 
listed", it's "all of the licenses listed following depset syntax 
rules".  Same syntax as DEPEND.  In other words, you can't stick a 
daft marker into the LICENSE field just the same as you can't stick 
daft atom's into DEPENDS; portage *must* resolve it.  If the LICENSE 
depset doesn't match the users ACCEPT_LICENSE, then the package is 
masked.  What you're proposing directly breaks glep23 (re-read the 
EBUILD License Variable section).

(Heading it off), no, a || ( DOOM3 commercial ) won't work either, 
that's _either_ commercial license accepted, or doom3.


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

Nope, see above.

It's the same old issue of "we want portage to do xyz", then something 
ugly/bad gets implemented that is a kludge getting in the way of a proper
solution.

That's harsh, but it's also the truth from being on the receiving end 
of portage bugs/watching the tree.  It's easier to slap a (imo) crap 
solution into the tree then to do the proper route of trying to 
implement a proper solution.


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

Logic here is rather flawed.

How do you know that the GPL is a 'opensource' license?  How do you 
know that the sorcerer public license is anti-forking?
You get off your ass and look in the licenses directory, that's how.

What you're proposing doesn't in any way help with educating people on 
what the licenses are that they're accepting; sticking "commercial" 
into the license field is a bad hack, pure and simple.

I'll kill this one off further down...


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


>=2.1 portage supports querying from metadata.xml.  Stable portage 
doesn't do a lot of things (like reading metadata.xml), but there's 
no reason later versions can't add in the missing 
functionality/feature.


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


Gave you another way, and I also clarifed why this isn't just a bad 
idea, you _cannot_ do this.

You view description as the wrong place for this; well, I view it as 
the proper place.  License in no way relates to if the binaries/source 
must be purchased or not.

It's a description thing.  "ID's DOOM3 game, non shareware version" 
fex.  Further, you're stating that "commercial" shouldn't be used as 
any form of grouping, but that _is_ what you're attempting- 


> If you do an "emerge -S doom3" on your system, how would you know that 
> the DOOM3 license is a commercial license?  

You read the license, silly, rather then blindly accepting licenses.  
The difference between doom3 and doom3-demo *should* be reflected in 
the DESCRIPTION also, since it's... the pkgs description data ;)

The fields exist for what you're after; I don't know why you're after 
the abuse of the LICENSE field, but it won't fly without a heck of a 
lot more kicking/screaming from me, and a reversal/ammendment of 
glep23.

Alternatives/better approaches I'd be open to, although I'll admit up 
front I think what you're attempting needs to be pkg specific, which 
implies DESCRIPTION in the ebuild (to me at least).
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]