From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1EIXkg-000874-0t for garchives@archives.gentoo.org; Thu, 22 Sep 2005 20:33:06 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j8MKPihS023610; Thu, 22 Sep 2005 20:25:44 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j8MKMx5Q021136 for ; Thu, 22 Sep 2005 20:23:00 GMT Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EIXgs-0002PN-NJ for gentoo-dev@lists.gentoo.org; Thu, 22 Sep 2005 20:29:10 +0000 Date: Thu, 22 Sep 2005 15:29:31 -0500 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] "Commercial" software in portage Message-ID: <20050922202931.GD10187@nightcrawler> References: <20050921172801.42BBEF5C20@mail.deploylinux.net> <1127325465.30787.58.camel@cgianelloni.nuvox.net> <4331E4F5.3090506@gentoo.org> <1127395820.24269.31.camel@cgianelloni.nuvox.net> <20050922164640.GC10187@nightcrawler> <1127410200.24269.67.camel@cgianelloni.nuvox.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gE7i1rD7pdK0Ng3j" Content-Disposition: inline In-Reply-To: <1127410200.24269.67.camel@cgianelloni.nuvox.net> User-Agent: Mutt/1.5.8i X-Archives-Salt: 454186f8-0f90-4df8-848b-212a9c4f801b X-Archives-Hash: be9812a98aca3aceb7febcf27625573b --gE7i1rD7pdK0Ng3j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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= =20 > > one of you emails (an "interim solution *now* since I've not heard=20 > > anything from GLEP23 for some time"). >=20 > 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=20 commercial", in effect a license grouping that's not properly=20 implemented. > > Further, where do you think you're going to migrate the check for this= =20 > > license to? >=20 > We wouldn't check for *this* license. We would be checking for the > *real* license. >=20 > 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=20 license.split() means that ACCEPT_LICENSE implementation now gets=20 screwed with, and has to start maintaining a whitelist of=20 strings to exempt from checks. Why is this an issue? LICENSE field isn't a "one of the licenses=20 listed", it's "all of the licenses listed following depset syntax=20 rules". Same syntax as DEPEND. In other words, you can't stick a=20 daft marker into the LICENSE field just the same as you can't stick=20 daft atom's into DEPENDS; portage *must* resolve it. If the LICENSE=20 depset doesn't match the users ACCEPT_LICENSE, then the package is=20 masked. What you're proposing directly breaks glep23 (re-read the=20 EBUILD License Variable section). (Heading it off), no, a || ( DOOM3 commercial ) won't work either,=20 that's _either_ commercial license accepted, or doom3. > > FYI, accept_license checks have been sitting in svn/cvs for about a=20 > > month, same as use deps. No, you can't use them now in a released=20 > > 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=20 > > yet another band aid in the tree would be to chip in- you want glep23? >=20 > 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=20 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=20 of portage bugs/watching the tree. It's easier to slap a (imo) crap=20 solution into the tree then to do the proper route of trying to=20 implement a proper solution. > > help bring the *proper*, agreed upon solution to a stable portage, not= =20 > > taking the easier route. >=20 > 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? >=20 > 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=20 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=20 what the licenses are that they're accepting; sticking "commercial"=20 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=20 > > jumping the gun, and the angle of "it indicates it costs money" isn't= =20 > > proper either. > >=20 > > You want to indicate that this *specific* pkg costs money=20 > > (something not related to the license it's released under I might=20 > > add)? Stick it in metadata.xml or DESCRIPTION. >=20 > 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. >=3D2.1 portage supports querying from metadata.xml. Stable portage=20 doesn't do a lot of things (like reading metadata.xml), but there's=20 no reason later versions can't add in the missing=20 functionality/feature. > > So... my 2 cents? No (was obvious already, wasn't it? :) >=20 > 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=20 idea, you _cannot_ do this. You view description as the wrong place for this; well, I view it as=20 the proper place. License in no way relates to if the binaries/source=20 must be purchased or not. It's a description thing. "ID's DOOM3 game, non shareware version"=20 fex. Further, you're stating that "commercial" shouldn't be used as=20 any form of grouping, but that _is_ what you're attempting-=20 > If you do an "emerge -S doom3" on your system, how would you know that=20 > the DOOM3 license is a commercial license? =20 You read the license, silly, rather then blindly accepting licenses. =20 The difference between doom3 and doom3-demo *should* be reflected in=20 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=20 the abuse of the LICENSE field, but it won't fly without a heck of a=20 lot more kicking/screaming from me, and a reversal/ammendment of=20 glep23. Alternatives/better approaches I'd be open to, although I'll admit up=20 front I think what you're attempting needs to be pkg specific, which=20 implies DESCRIPTION in the ebuild (to me at least). ~harring --gE7i1rD7pdK0Ng3j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDMxQrvdBxRoA3VU0RAoeyAKDpTPng/loUBxjDbNc17HgEHXJuQgCeLEl4 GI4un5VDJym0ZiqgRqYWPQk= =d7fh -----END PGP SIGNATURE----- --gE7i1rD7pdK0Ng3j-- -- gentoo-dev@gentoo.org mailing list