> On Thu, 2 Jan 2014, Ryan Hill wrote:
> In case it's helpful here's what FOSSology[1] has to say about some
> common packages that people have uploaded to their demo server.
I don't get your point here. The licenses of a package have to be
checked in any case. Why would it be more complicate
On Thu, 2 Jan 2014 16:07:22 -0600
Ryan Hill wrote:
> On Thu, 2 Jan 2014 16:20:09 -0500
> Rich Freeman wrote:
> > Personally I don't have any use for ACCEPT_LICENSE at all, and having
> > to specify the LICENSE for every single package in the tree is a lot
> > more work than additionally specify
On Thu, 2 Jan 2014 16:20:09 -0500
Rich Freeman wrote:
> On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill wrote:
> > That's only possible if we enumerate every license in every distfile we
> > distribute, which I don't think is a good idea. Or at least not on the
> > basis of a theoretic user that migh
On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill wrote:
> That's only possible if we enumerate every license in every distfile we
> distribute, which I don't think is a good idea. Or at least not on the
> basis of a theoretic user that might not actually exist.
Why would we need to do that when we don'
On Thu, 02 Jan 2014 11:10:54 -0500
Ian Stakenvicius wrote:
> On 02/01/14 07:50 AM, Ryan Hill wrote:
> >
> > Maybe we could add RESTRICT=srcdist which would cause ebuilds to
> > save their distfiles in a separate directory controlled by
> > PORTDIR_NODIST or something. If the variable is unset t
On Thu, 2 Jan 2014 19:17:50 +0100
Ulrich Mueller wrote:
> > On Thu, 2 Jan 2014, Luis Ressel wrote:
>
> >> RESTRICT is somewhat complementary to LICENSE and cannot provide as
> >> much information. Especially, RESTRICT="mirror" doesn't say under
> >> what license the restricted pieces are, an
> On Thu, 2 Jan 2014, Ulrich Mueller wrote:
> This is not primarily about distfiles mirroring, about about giving
s/about about/but about/
> users a choice what distfiles they will accept on their systems (for
> whatever reasons, e.g. legal or philosophical). Besides, not all
> users are und
On Thu, Jan 2, 2014 at 1:17 PM, Ulrich Mueller wrote:
>
> This is not primarily about distfiles mirroring, about about giving
> users a choice what distfiles they will accept on their systems (for
> whatever reasons, e.g. legal or philosophical). Besides, not all users
> are under the same legisla
On Thu, 02 Jan 2014 12:13:47 -0500
Ian Stakenvicius wrote:
> RESTRICT="fetch" requires the user to do their own fetching; since
> they're doing that, it should be pretty obvious that the distfile is
> restricted somehow. Of course, they are still able to do whatever
> they want, but I expect any
> On Thu, 2 Jan 2014, Luis Ressel wrote:
>> RESTRICT is somewhat complementary to LICENSE and cannot provide as
>> much information. Especially, RESTRICT="mirror" doesn't say under
>> what license the restricted pieces are, and doesn't allow for
>> ACCEPT_LICENSE filtering.
> But is this deta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/01/14 11:28 AM, Luis Ressel wrote:
> On Thu, 02 Jan 2014 11:10:54 -0500 Ian Stakenvicius
> wrote:
>
>> ..or we could just do this, using the existing RESTRICT="mirror"
>> that's already in ebuilds -- have a DISTDIR and a
>> NODISTCACHEDIR, N
On Thu, 2 Jan 2014 17:53:45 +0100
Ulrich Mueller wrote:
> RESTRICT is somewhat complementary to LICENSE and cannot provide as
> much information. Especially, RESTRICT="mirror" doesn't say under
> what license the restricted pieces are, and doesn't allow for
> ACCEPT_LICENSE filtering.
But is thi
On Fri, 3 Jan 2014 05:37:33 +1300
Kent Fredric wrote:
> Fair point. I was more seeing a pattern emerging and exploring where
> that might lead.
>
> Though I figure it a useful distinction for convenience sake.
>
> Consider if you wanted to archive some files to make a subsequent
> gentoo instal
> On Thu, 2 Jan 2014, Luis Ressel wrote:
> IMHO, this is the best solution proposed so far. It doesn't need a
> new USE flag duplicating information which is already in RESTRICT
> (or am I missing some corner cases here?), and it doesn't bother
> those who don't care about this issue with new
On 3 January 2014 05:28, Luis Ressel wrote:
>
> @Kent: Why do you think another distinction for RESTRICT=fetch is
> neccessary? If it really is, it could also be integrated into this
> solution, but I don't get the point -- either you're allowed to
> redistribute it, or you're not. RESTRICT=fetch
On Thu, 02 Jan 2014 11:10:54 -0500
Ian Stakenvicius wrote:
> ..or we could just do this, using the existing RESTRICT="mirror"
> that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR,
> NODISTCACHEDIR defaults to DISTDIR; if RESTRICT="mirror" then
> distfiles are saved to NODISTCACHEDIR
On Thu, Jan 2, 2014 at 10:25 AM, Michael Orlitzky wrote:
> If you think the transition period for that is long, how long do you
> think it will take for people to become aware of the magic USE flag and
> begin populating the other-LICENSE-contained-within-LICENSE variable?
> How long until it has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/01/14 07:50 AM, Ryan Hill wrote:
>
> Maybe we could add RESTRICT=srcdist which would cause ebuilds to
> save their distfiles in a separate directory controlled by
> PORTDIR_NODIST or something. If the variable is unset then it's
> business as
On 01/02/2014 07:54 AM, Ulrich Mueller wrote:
>> On Wed, 01 Jan 2014, Michael Orlitzky wrote:
>
>> As I said in another reply, more license metadata is good and we
>> should make it available. But a USE flag that changes the meaning of
>> an important global variable is a little hacky, especia
On 3 January 2014 02:18, Ulrich Mueller wrote:
> > Maybe we could add RESTRICT=srcdist which would cause ebuilds to
> > save their distfiles in a separate directory controlled by
> > PORTDIR_NODIST or something. If the variable is unset then it's
> > business as usual.
>
> Interesting idea, but h
On 3 January 2014 01:50, Ryan Hill wrote:
> Maybe we could add RESTRICT=srcdist which would cause ebuilds to save
> their distfiles in a separate directory controlled by PORTDIR_NODIST or
> something. If the variable is unset then it's business as usual.
>
I was going to suggest similar.
Thoug
> On Thu, 2 Jan 2014, Ryan Hill wrote:
> I've always believed that when it comes down to it all Gentoo
> basically does is provide a link to some source code and a script
> to build and install it. Unless we violate someone's license by
> redistributing that source then we really don't have to
> On Wed, 01 Jan 2014, Michael Orlitzky wrote:
> As I said in another reply, more license metadata is good and we
> should make it available. But a USE flag that changes the meaning of
> an important global variable is a little hacky, especially if it
> doesn't solve a real problem within Gent
On Thu, 2 Jan 2014 06:50:06 -0600
Ryan Hill wrote:
> I've always believed that when it comes down to it all Gentoo basically does
> is provide a link to some source code and a script to build and install it.
> Unless we violate someone's license by redistributing that source then we
> really don'
> On Thu, 2 Jan 2014, Michał Górny wrote:
> How does this interact with other flags? Say, I have:
> LICENSES="A utils? ( B )"
> Do I do:
> LICENSES="A utils? ( B ) srcdist? ( B )"
Yes.
> if they both are in the same tarball? Similarly, what if they come
> from different tarball, with
On Wed, 1 Jan 2014 23:28:54 +0100
Ulrich Mueller wrote:
> Hi,
> According to GLEP 23 [1], the LICENSE variable regulates the software
> that is installed on a system. There is however some ambiguity in
> this: should it cover the actual files installed on the system, or
> everything that is inclu
> On Wed, 1 Jan 2014, Rich Freeman wrote:
> On Wed, Jan 1, 2014 at 8:51 PM, Michael Orlitzky
> wrote:
>> I think a better solution here, since these files are *installed*,
>> is to introduce a new local flag (e.g. unfreeblobs) for the kernel
>> that would append to LICENSE by the mechanism d
Dnia 2014-01-01, o godz. 23:28:54
Ulrich Mueller napisał(a):
> LICENSE="
> srcdist? ( )"
>
> This idea was discussed within the licenses team, and the overall
> reaction was positive.
>
> What do you think?
How does this interact with other flags? Say, I have:
LICENSES=
28 matches
Mail list logo
