-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.
On Thu, 2005-09-22 at 23:01 +0100, Ciaran McCreesh wrote:
On Thu, 22 Sep 2005 17:57:16 -0400 warnera6 [EMAIL PROTECTED]
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
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.
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
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
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
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
On Thu, 2005-09-22 at 00:31 +0200, Marius Mauch wrote:
On Wed, 21 Sep 2005 09:51:16 -0400
Chris Gianelloni [EMAIL PROTECTED] 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
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
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
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
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
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
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
-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
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
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
On Thu, 22 Sep 2005 17:57:16 -0400 warnera6 [EMAIL PROTECTED]
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
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
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
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
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
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
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.
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
On Wed, 21 Sep 2005 09:51:16 -0400
Chris Gianelloni [EMAIL PROTECTED] 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
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
27 matches
Mail list logo
