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

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

[Matthew Marlowe]

>> We could add a license, called "commercial" into the tree.  This license
>> would look like the following.

I would definitly support adding "commercial" as a license group as part of
GLEP23 implementation. 

As part of adding any new commercial license to the tree, developers would have
to add the license to the commercial group.

>>  While this will break completely
>> interactive ebuilds until GLEP23 is fully implemented, a user can add
>> the license to make.conf in an ACCEPT_LICENSE variable, to keep portage
>> from asking again.  

We wouldnt break anything (hopefully) if we just do this as I specified above.

Also, I'm wondering if we truly need check_license in ebuilds.  Instead, we could
require that all licenses listed in the commercial group be manually added to
the ACCEPT_LICENSES line /etc/make.conf before emerging.  If the license
wasnt added, emerge would stop and ask the user to add the license manually.

Therefore, the user would be explicitely indicating their approval of the license by 
adding it.  Implementation could be as simple as ACCEPT_LICENSES not allowing 
"+commercial" to be defined.  It makes no sense, or at least we shouldnt encourage 
someone to say they agree to all commercial licenses so easily anyway.  The default 
portage ACCEPT_LICENSE would be -commercial.

MattM

-- 
gentoo-dev@gentoo.org mailing list

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

[José Carlos Cruz Costa]

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

Hi everybody,

If it's commercial, the company in question should (and must) allow an
ebuild for is product, like what happens with rpms and other packages.
Adding commercial ebuilds to portage is like tainting the kernel with binary
drivers.

Maybe a better solution comes with gensync? If companies want ebuilds, sure.
They go to the "commercial" portage. Hell, even put a price on maintaining
those ebuilds.

Remember that are a lot of people that don't want to use that kind of
software. There are people that doesn't have even xorg and have to sync all
the ebuilds from portage.

On 9/21/05, Matthew Marlowe <mattm@gentoo.org> wrote:
>
>
> >> We could add a license, called "commercial" into the tree. This license
> >> would look like the following.
>
> I would definitly support adding "commercial" as a license group as part
> of
> GLEP23 implementation.
>
> As part of adding any new commercial license to the tree, developers would
> have
> to add the license to the commercial group.
>
> >> While this will break completely
> >> interactive ebuilds until GLEP23 is fully implemented, a user can add
> >> the license to make.conf in an ACCEPT_LICENSE variable, to keep portage
> >> from asking again.
>
> We wouldnt break anything (hopefully) if we just do this as I specified
> above.
>
> Also, I'm wondering if we truly need check_license in ebuilds. Instead, we
> could
> require that all licenses listed in the commercial group be manually added
> to
> the ACCEPT_LICENSES line /etc/make.conf before emerging. If the license
> wasnt added, emerge would stop and ask the user to add the license
> manually.
>
> Therefore, the user would be explicitely indicating their approval of the
> license by
> adding it. Implementation could be as simple as ACCEPT_LICENSES not
> allowing
> "+commercial" to be defined. It makes no sense, or at least we shouldnt
> encourage
> someone to say they agree to all commercial licenses so easily anyway. The
> default
> portage ACCEPT_LICENSE would be -commercial.
>
> MattM
>
> --
> gentoo-dev@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 2595 bytes --]

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

[Daniel Ostrow]

On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> Hi everybody,
> 
> If it's commercial, the company in question should (and must) allow an
> ebuild for is product, like what happens with rpms and other packages.
> Adding commercial ebuilds to portage is like tainting the kernel with
> binary drivers. 
> 
> Maybe a better solution comes with gensync? If companies want ebuilds,
> sure. They go to the "commercial" portage. Hell, even put a price on
> maintaining those ebuilds.
> 
> Remember that are a lot of people that don't want to use that kind of
> software. There are people that doesn't have even xorg and have to
> sync all the ebuilds from portage. 

This is what rsync excludes are for...there is no good reason to remove
things like doom3 and UT2k4 from the tree for the sole reason that they
are commercial packages. You don't want them...fine...exclude them.

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org


-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Wed, 2005-09-21 at 14:00 -0400, Daniel Ostrow wrote:
> On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> > Hi everybody,
> > 
> > If it's commercial, the company in question should (and must) allow an
> > ebuild for is product, like what happens with rpms and other packages.
> > Adding commercial ebuilds to portage is like tainting the kernel with
> > binary drivers. 
> > 
> > Maybe a better solution comes with gensync? If companies want ebuilds,
> > sure. They go to the "commercial" portage. Hell, even put a price on
> > maintaining those ebuilds.
> > 
> > Remember that are a lot of people that don't want to use that kind of
> > software. There are people that doesn't have even xorg and have to
> > sync all the ebuilds from portage. 
> 
> This is what rsync excludes are for...there is no good reason to remove
> things like doom3 and UT2k4 from the tree for the sole reason that they
> are commercial packages. You don't want them...fine...exclude them.

...or just don't emerge them.  It isn't like we're sending SpanKY to
your house to force you to play them.  Many commercial packages are
designed to be used on RPM-based distributions, so many users find out
ebuilds invaluable for these things.

The whole point I am trying to make is that I am *not* going to make any
sort of political decision, but rather implement a slight change
tree-wide to empower users to make decisions of that sort for
themselves.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Philippe Trottier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Ostrow wrote:
> On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> 
>>Hi everybody,
>>
>>If it's commercial, the company in question should (and must) allow an
>>ebuild for is product, like what happens with rpms and other packages.
>>Adding commercial ebuilds to portage is like tainting the kernel with
>>binary drivers. 
>>
>>Maybe a better solution comes with gensync? If companies want ebuilds,
>>sure. They go to the "commercial" portage. Hell, even put a price on
>>maintaining those ebuilds.
>>
>>Remember that are a lot of people that don't want to use that kind of
>>software. There are people that doesn't have even xorg and have to
>>sync all the ebuilds from portage. 
> 
> This is what rsync excludes are for...there is no good reason to remove
> things like doom3 and UT2k4 from the tree for the sole reason that they
> are commercial packages. You don't want them...fine...exclude them.
> 

Possible to make the default a non-commercial ebuild rsync ? The exclude
file for rsync should be easy to make. That would be convenient for all
and allow purist to keep their system clean. Also would allow coders to
know what are the GNU weakest tools and work on them.

It is a fact that I would like to be able to read what licenses I agree
with and as a mater of fact I do not have to accept even GNU license to
use gentoo, so in theory I would do it like this:


After installing any stage any installation, the first action should
generate something like:

GPL/FSF license in the list of accepted licenses, please read
/usr/portage/licenses/LICENSE and add the license to your make.conf file
(only) if you accept it.

 Later on if I emerge some BSD licensed thing the same message should
appear, commercial licenses too

Otherwise the GLEP23 goes in the right direction. I know probably
everyone hates the "reading" part of license agreement, but your own
good read them at least once. And do not accept any commercial license
without reading it properly, you can't guess what is implied in some cases.

Phil
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDMmp5P0/FkJ0eBc0RAvLZAKC+Yof943+odO4x8ex5qVfL1WDJ1gCdF0gw
cmOF+o5v2eI+kBglyGJFr1I=
=9Msh
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

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

On Thu, Sep 22, 2005 at 11:26:19AM +0300, Philippe Trottier wrote:
> Daniel Ostrow wrote:
> > On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> > 
> >>Hi everybody,
> >>
> >>If it's commercial, the company in question should (and must) allow an
> >>ebuild for is product, like what happens with rpms and other packages.
> >>Adding commercial ebuilds to portage is like tainting the kernel with
> >>binary drivers. 
> >>
> >>Maybe a better solution comes with gensync? If companies want ebuilds,
> >>sure. They go to the "commercial" portage. Hell, even put a price on
> >>maintaining those ebuilds.
> >>
> >>Remember that are a lot of people that don't want to use that kind of
> >>software. There are people that doesn't have even xorg and have to
> >>sync all the ebuilds from portage. 
> > 
> > This is what rsync excludes are for...there is no good reason to remove
> > things like doom3 and UT2k4 from the tree for the sole reason that they
> > are commercial packages. You don't want them...fine...exclude them.
> > 
> 
> Possible to make the default a non-commercial ebuild rsync ? The exclude
> file for rsync should be easy to make. That would be convenient for all
> and allow purist to keep their system clean. Also would allow coders to
> know what are the GNU weakest tools and work on them.

The rsync exclude list would be rather massive, and would require 
modification to the rsync generation.  Also results in cvs users 
having a different tree then what those rsync'ing would get (not good 
imo).

GLEP23's accept_license is (for me) the preferred solution; you have 
everything locally, the choice of what you use is yours (rather then a 
default upstream with a secondary repo of commercial).

~harring

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

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

[Jason Stubbs]

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

On Friday 23 September 2005 23:42, Brian Harring wrote:
> GLEP23's accept_license is (for me) the preferred solution; you have
> everything locally, the choice of what you use is yours (rather then a
> default upstream with a secondary repo of commercial).

It doesn't fully cover what's being discussed here.

$ grep LICENSE doom3-1.3.1302.ebuild
LICENSE="DOOM3"
$ grep LICENSE doom3-demo-1.1.1286.ebuild
LICENSE="DOOM3"

The first is what's under discussion. The second isn't.

-- 
Jason Stubbs

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

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

[Daniel Ostrow]

On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> Hi everybody,
> 
> If it's commercial, the company in question should (and must) allow an
> ebuild for is product, like what happens with rpms and other packages.
> Adding commercial ebuilds to portage is like tainting the kernel with
> binary drivers. 
> 

More to the point...most of the ebuilds in question are just wrappers
for the install process...it still requires the original media (be that
physical or digital) or a key to install trust me when I say that we
aren't distributing binaries unless we have the right to do so.

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org


-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> If it's commercial, the company in question should (and must) allow an
> ebuild for is product, like what happens with rpms and other packages.
> Adding commercial ebuilds to portage is like tainting the kernel with
> binary drivers. 

Umm... no.  An ebuild is just a recipe for fetching/building a package.
It isn't the same as modification and redistribution (ala RPM) in any
way.  It is *nothing* like tainting the kernel and this conversation has
*nothing* to do with what I asked an opinion on.  I'm trying to ask a
technical opinion on a technical issue.  There's no need to pull in any
political garbage into the discussion, as that only fans the flames.

> Remember that are a lot of people that don't want to use that kind of
> software. There are people that doesn't have even xorg and have to
> sync all the ebuilds from portage. 

Those people are the exact reason I am wanting to do this.  Right now,
they see "License:     DOOM3" when they do an "emerge -S"... I'm
proposing they would see a "License:     DOOM3 commercial" instead.

Anyway, please try to refrain from hijacking my thread into some
pseudo-political stance.  I'm not making one or asking for one.  I'm
asking for acceptance on a technical solution for some users that allows
them to make a political decision, without making any decisions for
them.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

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

On Wed, 2005-09-21 at 10:31 -0700, Matthew Marlowe wrote:
> >> We could add a license, called "commercial" into the tree.  This license
> >> would look like the following.
> 
> I would definitly support adding "commercial" as a license group as part of
> GLEP23 implementation.

This isn't so much talking about GLEP23, but doing an interim
implementation *now* since I've not heard anything from GLEP23 for some
time.

> As part of adding any new commercial license to the tree, developers would have
> to add the license to the commercial group.
> 
> >>  While this will break completely
> >> interactive ebuilds until GLEP23 is fully implemented, a user can add
> >> the license to make.conf in an ACCEPT_LICENSE variable, to keep portage
> >> from asking again.  
> 
> We wouldnt break anything (hopefully) if we just do this as I specified above.

Except GLEP23 isn't implemented, so we cannot rely on it.

> Also, I'm wondering if we truly need check_license in ebuilds.  Instead, we could

Yes.  GLEP23 support is not in portage yet.  Certain packages (which
will rename nameless, *cough*enemy-territory*cough*) *require* that the
user accept the license before it is installed.

> require that all licenses listed in the commercial group be manually added to
> the ACCEPT_LICENSES line /etc/make.conf before emerging.  If the license
> wasnt added, emerge would stop and ask the user to add the license manually.

This is almost what check_license does, except it doesn't require the
user to add it manually, just accept the license.

> Therefore, the user would be explicitely indicating their approval of the license by 
> adding it.  Implementation could be as simple as ACCEPT_LICENSES not allowing 
> "+commercial" to be defined.  It makes no sense, or at least we shouldnt encourage 
> someone to say they agree to all commercial licenses so easily anyway.  The default 
> portage ACCEPT_LICENSE would be -commercial.

Anyway, you didn't answer my question, at all.

My question is about adding a "commercial" license to portage *now* and
adding it to relevant ebuilds so it shows up when users do an "emerge
-S" or look in http://packages.gentoo.org now, not when GLEP23 finally
rolls around.  At that time, I would expect there to be a proper
implementation.  Of course, I also think that there's no point in
grouping commercial licenses at all if we aren't going to allow
acceptance of them all as a group.  Commercial licenses are individual,
so they should stay that way, but that's a discussion for another
thread... ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Lance Albertson]

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

Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 10:31 -0700, Matthew Marlowe wrote:
> 
>>>>We could add a license, called "commercial" into the tree.  This license
>>>>would look like the following.
>>
>>I would definitly support adding "commercial" as a license group as part of
>>GLEP23 implementation.
> 
> 
> This isn't so much talking about GLEP23, but doing an interim
> implementation *now* since I've not heard anything from GLEP23 for some
> time.
> 
> 
>>As part of adding any new commercial license to the tree, developers would have
>>to add the license to the commercial group.
>>
>>
>>>> While this will break completely
>>>>interactive ebuilds until GLEP23 is fully implemented, a user can add
>>>>the license to make.conf in an ACCEPT_LICENSE variable, to keep portage
>>>>from asking again.  
>>
>>We wouldnt break anything (hopefully) if we just do this as I specified above.
> 
> 
> Except GLEP23 isn't implemented, so we cannot rely on it.

Is this just a one-off implementation until GLEP 23 is implemented, or
something that will complement it? Whats going to happen to this data
after GLEP23 gets implemented? I'd hate to see something added simply
because its a quick one-off solution to make something work. I'd rather
see people focus on the actual GLEP and moving it along. Of course, if
this data will just be an added feature of GLEP23, I don't see a problem.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

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

[Chris Gianelloni]

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

On Wed, 2005-09-21 at 17:55 -0500, Lance Albertson wrote:
> Is this just a one-off implementation until GLEP 23 is implemented, or
> something that will complement it? Whats going to happen to this data
> after GLEP23 gets implemented? I'd hate to see something added simply
> because its a quick one-off solution to make something work. I'd rather
> see people focus on the actual GLEP and moving it along. Of course, if
> this data will just be an added feature of GLEP23, I don't see a problem.

This really has nothing to do with GLEP23, as it isn't related to any
kind of grouping, or ACCEPT_LICENSE.  It is simply a marker to say to
our users: "Hey, you have to buy this for it to work."  That is
something that GLEP23 does not provide for in any way.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

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

On Thu, Sep 22, 2005 at 09:30:20AM -0400, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 17:55 -0500, Lance Albertson wrote:
> > Is this just a one-off implementation until GLEP 23 is implemented, or
> > something that will complement it? Whats going to happen to this data
> > after GLEP23 gets implemented? I'd hate to see something added simply
> > because its a quick one-off solution to make something work. I'd rather
> > see people focus on the actual GLEP and moving it along. Of course, if
> > this data will just be an added feature of GLEP23, I don't see a problem.
> 
> This really has nothing to do with GLEP23, as it isn't related to any
> kind of grouping, or ACCEPT_LICENSE.  It is simply a marker to say to
> our users: "Hey, you have to buy this for it to work."  That is
> something that GLEP23 does not provide for in any way.

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

Further, where do you think you're going to migrate the check for this 
license to?

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?  
help bring the *proper*, agreed upon solution to a stable portage, not 
taking the easier route.

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?

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.

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.

So... my 2 cents?  No (was obvious already, wasn't it? :)
~harring

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

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

[Chris Gianelloni]

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

[-- 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 --]

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

[Chris Gianelloni]

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

On Thu, 2005-09-22 at 15:29 -0500, Brian Harring wrote:
> 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).

Snipping pretty much everything since I *really* don't care.

I'm just dumping this idea.  I was proposing it because of a
conversation with a user where we thought it would be a good idea to
give the user some way of knowing that a package requires some
additional purchased (or otherwise obtained) portion that is not a
distfile/tarball.  Anyway, you seem to have done a good job of
convincing me of whatever it is you think you've convinced me of, but
the truth is I just didn't care enough to bother getting into some
pointless pissing match over something that I didn't feel very strongly
about in the first place.  Basically, you "win" by default of me just
not caring enough to argue anymore.

I'll just wait around for portage 2.1 or whatever and see what kind of
kludge we have to design then.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[warnera6]

Chris Gianelloni wrote:
> On Thu, 2005-09-22 at 15:29 -0500, Brian Harring wrote:
> 
>>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).
> 
> 
> Snipping pretty much everything since I *really* don't care.
> 
> I'm just dumping this idea.  I was proposing it because of a
> conversation with a user where we thought it would be a good idea to
> give the user some way of knowing that a package requires some
> additional purchased (or otherwise obtained) portion that is not a
> distfile/tarball.  Anyway, you seem to have done a good job of
> convincing me of whatever it is you think you've convinced me of, but
> the truth is I just didn't care enough to bother getting into some
> pointless pissing match over something that I didn't feel very strongly
> about in the first place.  Basically, you "win" by default of me just
> not caring enough to argue anymore.
A.  The above is kind of sad in terms of the outcome, I'm sorry more 
people didn't jive with your idea, but there is no need to cry about it.
B.  Whats wrong with stuffing it into metadata.xml and modifying p.g.o 
to pull the extra data out?  It certainly isn't that complicated.  Or 
just modify the DESCRIPTION field.  "Doom3" -> DESCRIPTION = " A popular 
first person shooter.  This game requires a license key to play." Simple no?

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 22 Sep 2005 17:57:16 -0400 warnera6 <warnera6@egr.msu.edu>
wrote:
| Or just modify the DESCRIPTION field.  "Doom3" ->
| DESCRIPTION = " A popular first person shooter.  This game requires a
| license key to play." Simple no?

Yick. I'd rather see metadata.xml long descriptions becoming more
useful than cluttering up ebuilds with that nonsense.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

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

[Chris Gianelloni]

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

On Thu, 2005-09-22 at 23:01 +0100, Ciaran McCreesh wrote:
> On Thu, 22 Sep 2005 17:57:16 -0400 warnera6 <warnera6@egr.msu.edu>
> wrote:
> | Or just modify the DESCRIPTION field.  "Doom3" ->
> | DESCRIPTION = " A popular first person shooter.  This game requires a
> | license key to play." Simple no?
> 
> Yick. I'd rather see metadata.xml long descriptions becoming more
> useful than cluttering up ebuilds with that nonsense.

Agreed.  The need for a license is *not* a description of the package.
The best fit for it *is* the LICENSE variable, unless it is provided in
metadata.xml, which then precludes it being package-specific and not
ebuild specific, which is exactly what I was trying to avoid.  It also
means that we need an extension of the DTD, unless we just put the
information in the longdescription field somewhere, which I think still
falls under the "It isn't a part of the description" thing.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jason Stubbs]

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

On Friday 23 September 2005 06:09, Chris Gianelloni wrote:
> it would be a good idea to give the user some way of knowing that a
> package requires some additional purchased (or otherwise obtained)
> portion that is not a distfile/tarball. 

It would be a good idea, indeed. RESTRICT="purchase" or somesuch parallel to 
RESTRICT="fetch" would solve this just as well. However, whenever adding 
new stuff like this, as a portage developer, I always ask what use of it 
can be made by portage? I can't see anything other than passing the 
information to a user interface to blink some text at the user...

Overloading RESTRICT="fetch" to include this case seems like the best method 
to me. Really, what's the difference between fetch-restricted and "purchase
-restricted"? From a portage point of view, they both require the user to 
dance through some hoops before getting access and there's not really any 
important difference beyond that.

So, if RESTRICT="fetch" were to be overloaded, there is the issue of both 
fetch-restricted and non-fetch-restricted downloads in the one package. I 
would think this issue exists already for some packages. How is it dealt 
with at the moment?

-- 
Jason Stubbs

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

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

[Chris Gianelloni]

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

On Fri, 2005-09-23 at 10:38 +0900, Jason Stubbs wrote:
> On Friday 23 September 2005 06:09, Chris Gianelloni wrote:
> > it would be a good idea to give the user some way of knowing that a
> > package requires some additional purchased (or otherwise obtained)
> > portion that is not a distfile/tarball. 
> 
> It would be a good idea, indeed. RESTRICT="purchase" or somesuch parallel to 
> RESTRICT="fetch" would solve this just as well. However, whenever adding 
> new stuff like this, as a portage developer, I always ask what use of it 
> can be made by portage? I can't see anything other than passing the 
> information to a user interface to blink some text at the user...

The problem stems from a fetch restriction (of any kind) not being
sufficient to be this marker.  Take my classic doom3 example.  There is
*nothing* restricted, download-wise.  It just requires you have the data
files available, either via a CD, or copied to disk somewhere.  It
*also* requires a CD key.  I don't see where any kind of fetch
restriction-like device would accommodate this, as the restrictions are
on installation/execution, not on fetching.

Also, my proposal was based on several user requests to *have* some kind
of information showing that the package requires a purchase/license.
Since it seems that many are confusing this with the nature of the
package (check out the sun-jdk question), it leads me to believe that
this is best left alone and to simply wait for GLEP23 to be wide-spread,
then to revisit this, since LICENSE definitely isn't the place for it,
and neither is any kind of RESTRICT, as far as I can tell.  The only way
I could see a restriction being useful is if we also added a FEATURE to
go along with it.

FEATURE="non-commercial" RESTRICT="commercial" (in ebuild)
emerge doom3
Calculating dependencies
!!! All ebuilds that could satisfy "doom3" have been masked.
!!! One of the following masked packages is required to complete your
request:
- games-fps/doom3-1.3.1302 (masked by commericial status)

...or some such thing.  Even this wouldn't give the user any idea of the
status of the package until emerge time, even with a pretend.  I think I
was looking for something where a user could tell before they even
decided to merge the package, via emerge -S or packages.gentoo.org, or
preferably both.

> Overloading RESTRICT="fetch" to include this case seems like the best method 
> to me. Really, what's the difference between fetch-restricted and "purchase
> -restricted"? From a portage point of view, they both require the user to 
> dance through some hoops before getting access and there's not really any 
> important difference beyond that.

On the contrary, as I stated above, there's some differences.  I'll give
another example, Neverwinter Nights.  You can install Neverwinter Nights
without using *any* media and using only freely-downloadable tarballs.
To *play* the game, however, you need a CD key.  A fetch restriction
here wouldn't help the user in any way determine that they are going to
need a CD key.  All it would do is force them to jump through hoops to
download 1.5GB+ of data, only to install it and find out that they can't
use the game anyway without a purchase.

> So, if RESTRICT="fetch" were to be overloaded, there is the issue of both 
> fetch-restricted and non-fetch-restricted downloads in the one package. I 
> would think this issue exists already for some packages. How is it dealt 
> with at the moment?

Currently, we just restrict the whole thing, as we have no other choice.
On some packages, it sucks pretty badly if there's only a single
restricted tarball and many unrestricted tarballs.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jason Stubbs]

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

On Friday 23 September 2005 22:28, Chris Gianelloni wrote:
> On Fri, 2005-09-23 at 10:38 +0900, Jason Stubbs wrote:
> > On Friday 23 September 2005 06:09, Chris Gianelloni wrote:
> > > it would be a good idea to give the user some way of knowing that a
> > > package requires some additional purchased (or otherwise obtained)
> > > portion that is not a distfile/tarball.
> >
> > It would be a good idea, indeed. RESTRICT="purchase" or somesuch
> > parallel to RESTRICT="fetch" would solve this just as well. However,
> > whenever adding new stuff like this, as a portage developer, I always
> > ask what use of it can be made by portage? I can't see anything other
> > than passing the information to a user interface to blink some text at
> > the user...
>
> The problem stems from a fetch restriction (of any kind) not being
> sufficient to be this marker.  Take my classic doom3 example.  There is
> *nothing* restricted, download-wise.  It just requires you have the data
> files available, either via a CD, or copied to disk somewhere.  It
> *also* requires a CD key.  I don't see where any kind of fetch
> restriction-like device would accommodate this, as the restrictions are
> on installation/execution, not on fetching.

*Relax!* ;)

I meant extending the fetch-restriction concept to include all cases where 
an ebuild is not fully self-contained; that is, cases where the ebuild is 
not capable of obtaining all necessary components to get a package to a 
fully-functional state.

> Also, my proposal was based on several user requests to *have* some kind
> of information showing that the package requires a purchase/license.

This, I understood.

> Since it seems that many are confusing this with the nature of the
> package (check out the sun-jdk question), it leads me to believe that
> this is best left alone and to simply wait for GLEP23 to be wide-spread,
> then to revisit this, since LICENSE definitely isn't the place for it,
> and neither is any kind of RESTRICT, as far as I can tell.

Deferring discussion about it.. well, it scares me to be completely honest. 
It becomes another one of those "is this going to change the requirements?" 
that's always lurking.

> I think I was looking for something where a user could tell before they 
> even decided to merge the package, via emerge -S or packages.gentoo.org, 
> or preferably both.

Is that the only requirement? Just a boolean attribute that says the user 
will have to pay money in order to make use of the package? If so, it would 
seem that metadata.xml would be the perfect place, but I'll think on that 
and come back to it.

> > So, if RESTRICT="fetch" were to be overloaded, there is the issue of
> > both fetch-restricted and non-fetch-restricted downloads in the one
> > package. I would think this issue exists already for some packages. How
> > is it dealt with at the moment?
>
> Currently, we just restrict the whole thing, as we have no other choice.
> On some packages, it sucks pretty badly if there's only a single
> restricted tarball and many unrestricted tarballs.

Perhaps leave this one for another time? :)

-- 
Jason Stubbs

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

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

[Chris Gianelloni]

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

On Fri, 2005-09-23 at 23:08 +0900, Jason Stubbs wrote:
> *Relax!* ;)

I'm quite calm, actually.

> I meant extending the fetch-restriction concept to include all cases where 
> an ebuild is not fully self-contained; that is, cases where the ebuild is 
> not capable of obtaining all necessary components to get a package to a 
> fully-functional state.

That would be fine.  I'm not sure how extending fetch restriction would
do it, but I'm also not a portage developer.

> Deferring discussion about it.. well, it scares me to be completely honest. 
> It becomes another one of those "is this going to change the requirements?" 
> that's always lurking.

I personally don't see it as a big enough issue to sweat it.  If it
doesn't make it into the next portage version, we shoot for one after
that.

> > I think I was looking for something where a user could tell before they 
> > even decided to merge the package, via emerge -S or packages.gentoo.org, 
> > or preferably both.
> 
> Is that the only requirement? Just a boolean attribute that says the user 
> will have to pay money in order to make use of the package? If so, it would 
> seem that metadata.xml would be the perfect place, but I'll think on that 
> and come back to it.

That is the only requirement that *I* had based on discussion with a
couple users.  They just wanted to know ahead of time that a package
they were looking at wouldn't work without them buying it.

> > > So, if RESTRICT="fetch" were to be overloaded, there is the issue of
> > > both fetch-restricted and non-fetch-restricted downloads in the one
> > > package. I would think this issue exists already for some packages. How
> > > is it dealt with at the moment?
> >
> > Currently, we just restrict the whole thing, as we have no other choice.
> > On some packages, it sucks pretty badly if there's only a single
> > restricted tarball and many unrestricted tarballs.
> 
> Perhaps leave this one for another time? :)

Agreed.  This is best left for later.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] "Commercial" software in portage

[Chris Gianelloni]

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

I had a nice little discussion with someone today about commercial
software in portage.  His basic complaint was that there's no way to
distinguish what software is commercial and what is not.  The licenses
are not always apparent in these things.  Anyway, I had originally
thought this to be something for metadata.xml, and if it is decided that
is still the best place for it, then I'm all for it, but I'd like to
present an alternate proposal.

We could add a license, called "commercial" into the tree.  This license
would look like the following.

"This is a license created by Gentoo to indicate that a package is of a
commercial nature.  The reasoning behind this is so users are aware that
a package might not be in a 100% functional state without some form of
user interaction, such as the addition of data files or a CD key after
installation.

This package, or portions of this package, fall under one or more
commercial licenses and is not free."

Basically, we just add "commercial" to LICENSE in the ebuild, and (if
wanted or necessary) add "check_license $licese_required_to_be_accepted"
to pkg_setup on the ebuild.  While this will break completely
interactive ebuilds until GLEP23 is fully implemented, a user can add
the license to make.conf in an ACCEPT_LICENSE variable, to keep portage
from asking again.  This means when a user does an "emerge -S" they will
see the nice little "commercial" listed under licenses, which will
hopefully trigger to them that this package is not free.  Another
possible addition is a "commercial-free" license, which would cover
things like America's Army and Enemy Territory (I'm sure there are
others, but I know of these two) that are free for users to use, but are
still commercial software.

This would require us to make some modifications to a few ebuilds,
though I know that most of the ebuilds using check_license are
maintained by me.  I'm willing to make all necessary changes in the tree
for this to be seamless for our users.  The only packages which will
interactively ask the user to accept a license are the ones that do so
currently.

So now I ask, can anyone think of a reason not to do this, or a better
way to go about it?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Paweł Madej]

I think that it is very good idea.

As a member of Polish PHP Community, I'm going to try to make ebuild's 
for Zend Company [1] products. It will resolve my problem with what 
license should I enter in ebuild.

[1] http://www.zend.com

Greets
Paul
-- 
gentoo-dev@gentoo.org mailing list

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

[Marius Mauch]

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

On Wed, 21 Sep 2005 09:51:16 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> Basically, we just add "commercial" to LICENSE in the ebuild, and (if
> wanted or necessary) add "check_license
> $licese_required_to_be_accepted" to pkg_setup on the ebuild.  While
> this will break completely interactive ebuilds until GLEP23 is fully
> implemented, a user can add the license to make.conf in an
> ACCEPT_LICENSE variable, to keep portage from asking again.  This
> means when a user does an "emerge -S" they will see the nice little
> "commercial" listed under licenses, which will hopefully trigger to
> them that this package is not free.  Another possible addition is a
> "commercial-free" license, which would cover things like America's
> Army and Enemy Territory (I'm sure there are others, but I know of
> these two) that are free for users to use, but are still commercial
> software.

Can't say that I exactly like this, mainly because "commercial"
wouldn't be a real license and so kinda blurs the meaning of LICENSE.
But then one could say the same about "as-is". My other concern is that
there is no clear criteria for commercial packages, e.g. are sun-jdk /
other fetch restricted packages commercial?
That said, it's probably the best approach that doesn't require portage
changes.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

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

[Thierry Carrez]

Marius Mauch wrote:

> My other concern is that
> there is no clear criteria for commercial packages, e.g. are sun-jdk /
> other fetch restricted packages commercial?

+1
I think the world isn't black and white and we might find things in the
grey area between "commercial" and "non-commercial".

-- 
Koon
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Thu, 2005-09-22 at 10:14 +0200, Thierry Carrez wrote:
> Marius Mauch wrote:
> 
> > My other concern is that
> > there is no clear criteria for commercial packages, e.g. are sun-jdk /
> > other fetch restricted packages commercial?
> 
> +1
> I think the world isn't black and white and we might find things in the
> grey area between "commercial" and "non-commercial".

Not in this case.  I'm not trying to make judgements based on the
license.  I am saying "You need to pay for this."

If you don't have to hand over money, I'm not adding "commercial" to it.
Doing any kind of interpretation of the licenses is GLEP23's territory,
not mine.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

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

On Thu, 2005-09-22 at 00:31 +0200, Marius Mauch wrote:
> On Wed, 21 Sep 2005 09:51:16 -0400
> Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> 
> > Basically, we just add "commercial" to LICENSE in the ebuild, and (if
> > wanted or necessary) add "check_license
> > $licese_required_to_be_accepted" to pkg_setup on the ebuild.  While
> > this will break completely interactive ebuilds until GLEP23 is fully
> > implemented, a user can add the license to make.conf in an
> > ACCEPT_LICENSE variable, to keep portage from asking again.  This
> > means when a user does an "emerge -S" they will see the nice little
> > "commercial" listed under licenses, which will hopefully trigger to
> > them that this package is not free.  Another possible addition is a
> > "commercial-free" license, which would cover things like America's
> > Army and Enemy Territory (I'm sure there are others, but I know of
> > these two) that are free for users to use, but are still commercial
> > software.
> 
> Can't say that I exactly like this, mainly because "commercial"
> wouldn't be a real license and so kinda blurs the meaning of LICENSE.
> But then one could say the same about "as-is". My other concern is that
> there is no clear criteria for commercial packages, e.g. are sun-jdk /
> other fetch restricted packages commercial?

I thought I had made it fairly clear, but I can elaborate.

"commercial" would be anything that requires a purchase to use.  This
could be anything from specific media (such as most games) to a CD key
or license file.

The basic idea is to put in a marker to let people know that "This won't
work without you spending money."

This isn't a marker of whether something is proprietary, but rather a
marker of whether something works out of the box.  Sun's JDK, while it
could be argued whether it would be "commercial" or not, does work out
of the box, once you fetch the sources.  You don't have to purchase it.

> That said, it's probably the best approach that doesn't require portage
> changes.

This is primarily why I proposed it, as it can be done now without any
extra code for portage.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Georgi Georgiev]

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

maillog: 22/09/2005-09:28:53(-0400): Chris Gianelloni types
> I thought I had made it fairly clear, but I can elaborate.
> 
> "commercial" would be anything that requires a purchase to use.  This
> could be anything from specific media (such as most games) to a CD key
> or license file.
> 
> The basic idea is to put in a marker to let people know that "This won't
> work without you spending money."
> 
> This isn't a marker of whether something is proprietary, but rather a
> marker of whether something works out of the box.  Sun's JDK, while it
> could be argued whether it would be "commercial" or not, does work out
> of the box, once you fetch the sources.  You don't have to purchase it.

So, how do you treat icc? It requires a license key, but you can get the
key for free after registering. The package does not cost money and does
not work out of the box.

-- 
 )   Georgi Georgiev    ) Shah, shah! Ayatollah you so!                 )
(     chutz@gg3.net    (                                               (
 )  +81(90)2877-8845    )                                               )

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

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

[Chris Gianelloni]

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

On Fri, 2005-09-23 at 00:37 +0900, Georgi Georgiev wrote:
> maillog: 22/09/2005-09:28:53(-0400): Chris Gianelloni types
> > I thought I had made it fairly clear, but I can elaborate.
> > 
> > "commercial" would be anything that requires a purchase to use.  This
> > could be anything from specific media (such as most games) to a CD key
> > or license file.
> > 
> > The basic idea is to put in a marker to let people know that "This won't
> > work without you spending money."
> > 
> > This isn't a marker of whether something is proprietary, but rather a
> > marker of whether something works out of the box.  Sun's JDK, while it
> > could be argued whether it would be "commercial" or not, does work out
> > of the box, once you fetch the sources.  You don't have to purchase it.
> 
> So, how do you treat icc? It requires a license key, but you can get the
> key for free after registering. The package does not cost money and does
> not work out of the box.

Is that a full license or some kind of demo ala VMWare Workstation?

Oh yeah, and I don't maintain icc, so that would really be up to the
maintainers, but *I* would probably put commercial on it.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Cory Visi]

On Thu, Sep 22, 2005 at 11:54:25AM -0400, Chris Gianelloni wrote:
> On Fri, 2005-09-23 at 00:37 +0900, Georgi Georgiev wrote:
> > maillog: 22/09/2005-09:28:53(-0400): Chris Gianelloni types
> > > I thought I had made it fairly clear, but I can elaborate.
> > > 
> > > "commercial" would be anything that requires a purchase to use.  This
> > > could be anything from specific media (such as most games) to a CD key
> > > or license file.
> > > 
> > > The basic idea is to put in a marker to let people know that "This won't
> > > work without you spending money."
> > > 
> > > This isn't a marker of whether something is proprietary, but rather a
> > > marker of whether something works out of the box.  Sun's JDK, while it
> > > could be argued whether it would be "commercial" or not, does work out
> > > of the box, once you fetch the sources.  You don't have to purchase it.
> > 
> > So, how do you treat icc? It requires a license key, but you can get the
> > key for free after registering. The package does not cost money and does
> > not work out of the box.
> 
> Is that a full license or some kind of demo ala VMWare Workstation?
> 
> Oh yeah, and I don't maintain icc, so that would really be up to the
> maintainers, but *I* would probably put commercial on it.


Maybe "commercial" is just the wrong word. The way I understand the 
concept is to let users know that they have to take a step outside of 
portage (that's not just fetching the download) to get a package to work. 
I think this is a good idea. We just need to call it something that 
doesn't cause endless confusion.

On a related note, keeping with the philosophy here, I would say that 
Opera does not qualify for this new flag, because it works out of the 
box. Even if it has ads, it still works. However, Opera is obviously 
commercial, so this is another reason to perhaps think up another name 
for the flag.

-Cory
-- 
gentoo-dev@gentoo.org mailing list

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

[Matti Bickel]

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

Cory Visi <merlin@gentoo.org> wrote:
> I think this is a good idea. We just need to call it something that 
> doesn't cause endless confusion.

Sticking something like a "non-complete version" sticker on it would
help.

> On a related note, keeping with the philosophy here, I would say that 
> Opera does not qualify for this new flag, because it works out of the 
> box. Even if it has ads, it still works. However, Opera is obviously 
> commercial, so this is another reason to perhaps think up another name 
> for the flag.

<nitpick>
Opera is now ad-free. And while still not open-source, it's now both
free (of charge) and free (of ads)
</nitpick>

Matti
-- 

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

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

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Gianelloni wrote:
| On Fri, 2005-09-23 at 00:37 +0900, Georgi Georgiev wrote:
|>So, how do you treat icc? It requires a license key, but you can get the
|>key for free after registering. The package does not cost money and does
|>not work out of the box.
|
|
| Is that a full license or some kind of demo ala VMWare Workstation?

It's free for noncommercial use. You can buy a license for other use.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDMuQjXVaO67S1rtsRArfRAJwOUMA91QW2hbHcUkypDZ4LxMNCjQCfRuFM
2zN2WV/moA9Qdyeg3wZKUds=
=ySfL
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list