ACCEPT_LICENSE revisited

classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

ACCEPT_LICENSE revisited

Marius Mauch
Hi,

in the past weeks Jason, Zac and myself have been working to implement
license based visibility fitlering (aka ACCEPT_LICENSE). This is also
discussed in GLEP 23, however the original versions of that document
didn't quite go along with the implementation and lacked some details.

So here is a new version of it, the main changes are:
- added definition of license group files
- added license group negation semantics
- updated proposed portage behavior to match current implementation
(using visibility filtering system instead of blocker system)
- added requirement for default ACCEPT_LICENSE in profiles

Anyone interested in this feature should review the attached version.
Unless there are major objections (or we find large problems in the
implementation) this will be merged in one of the next portage releases
(definitely not in 2.1.2 though).

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.

glep-0023.txt (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Ciaran McCreesh-3
On Sat, 18 Nov 2006 08:53:36 +0100 Marius Mauch <[hidden email]>
wrote:
| Anyone interested in this feature should review the attached version.
| Unless there are major objections (or we find large problems in the
| implementation) this will be merged in one of the next portage
| releases (definitely not in 2.1.2 though).

133594 will need to be fixed before this is usable for most users.

--
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Mike Doty
Ciaran McCreesh wrote:
> On Sat, 18 Nov 2006 08:53:36 +0100 Marius Mauch <[hidden email]>
> wrote:
> | Anyone interested in this feature should review the attached version.
> | Unless there are major objections (or we find large problems in the
> | implementation) this will be merged in one of the next portage
> | releases (definitely not in 2.1.2 though).
>
> 133594 will need to be fixed before this is usable for most users.
>
I'm sure it's been talked about before, but the ability to group
licenses would solve that.  Just create a X.Org license group and add
all the individual modular X licenses to it.

--Mike
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Brian Harring-2
In reply to this post by Marius Mauch
On Sat, Nov 18, 2006 at 08:53:36AM +0100, Marius Mauch wrote:
> Anyone interested in this feature should review the attached version.
> Unless there are major objections (or we find large problems in the
> implementation) this will be merged in one of the next portage releases
> (definitely not in 2.1.2 though).

Gleps have to be approved prior to being merged mind you
(ain't process fun?).

> To accomodate these cases, LICENSE syntax should accomodate all
> functionality offered by a DEPEND string.  To keep things simple, this
> GLEP proposes that the syntax be identical.  For example:

Would label that 'offered by a DepSet', although requires codifying
the rules of it (referencing depend string only always struck me as
odd since it implies that rdepends/pdepends differ, which they don't).


> License Groups
> --------------
>
> Almost all users are willing to install any software that is
> FSF-approved.  Other users are willing to install any software and
> implicitly accept its license.  To this end, portage will also need to
> handle grouping of licenses.
>
> At a minimum, there needs to be the groups ``GPL-COMPATIBLE``,
> ``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-INTERACTIVE``.  
> ``NON-INTERACTIVE`` licenses are those that don't require interactive
> acceptance for to be considered legally binding.  This is the current
> behaviour of portage.
>
> These groups are defined in a new file ``license_groups`` in
> the ``profiles`` subdirectory of the tree (or overlays).
> The format of this file is
Resurrecting an old arguement, but profiles is the wrong location for
this; it's repository metadata (global), not specific to the profile,
thus should be in metadata/.


> <groupname> <license1> <license2> ... <licenseN>
>
> Also any line starting with # is ignored and may be used for comments.
> License groups may not contain negated elements, so a group
>
> ::
>
> mygroup foo -bar -bla
>
> is illegal.
Route of a bit of duplication I'd think; since you're disallowing
groups to be used in defining other groups, negation isn't needed;
that said, I don't see why groups aren't allowed (if they were,
negation must be allowed)...

If you're going to disallow groups used to define other groups, should
lay out the reasoning in the glep.


> ACCEPT_LICENSE
> --------------
>
> This GLEP proposes that a user be able to explicitly accept or decline
> licenses by editing a new variable ``ACCEPT_LICENSE`` in
> ``/etc/make.conf``.  Again, to keep things simple, the syntax should be
> similar to that of other incrementals.  For example:
>
> ::
>
> ACCEPT_LICENSE="-* accepted-license -declined-license"
>
> As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.  
> This GLEP proposes that the license group be prepended by the special
> character "``@``".  For example:
>
> ::
>
> ACCEPT_LICENSE="-* @FSF-APPROVED"
>
> License groups may be negated with the result that all elements of that group
> are also negated.
Left out that if it's unset, it should default to ACCEPT_LICENSE=* ,
meaning no license filtering.


> Portage Behaviour
> -----------------
>
> Unaccepted licenses will be treated like any other masked package, that is
> emerge will display a message listing any license that has to be accepted
> before the package can be merged with a pointer to the exact license text.

Glep doesn't say anything about overlay stacking of it; know I'll be
implementing it such that overlay specific license groups only affect
that overlay, but also know that portage will collapse that and have
it affect the full repository stack (meaning a redefine in an overlay
changes the group for PORTDIR).

Would suggest clarifying that.


> Backwards Compatibility
> =======================
>
> There should be no change to the user experience without the user
> explicitly choosing to do so.  This mandates that the
> configuration variable be named ``ACCEPT_LICENSE`` as some users may
> already have it set due to ebuilds using ``eutil.eclass``'s
> implementation.  It also mandates that the default ``ACCEPT_LICENSE`` be
> set to ``@NON-INTERACTIVE`` in the main gentoo repository as there will
> be no internal default in portage.
The current default in portage however is that of ACCEPT_LICENSE=*;
since portage doesn't yet filter on licenses, and since interactive
ebuilds already exist, _that_ is the default.

Finally, NON-INTERACTIVE shouldn't be a license group;
RESTRICT=interactive is the route there; you can have gpl software
distributed on cds that must be interactive (feed cds in as
requested).

The only solution there would to be to invent a fake license group for
it and tag it in... which is not what license is about.

Interactivity is a seperate thing from license; keep it that way.


Finally... stupid, but s/portage/package manager/; should be
an agnostic specification ('specially considering the other two
already do non-group license filtering since their respective
inceptions).

~harring

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Ciaran McCreesh-3
In reply to this post by Mike Doty
On Sat, 18 Nov 2006 15:22:36 -0600 Mike Doty <[hidden email]>
wrote:
| Ciaran McCreesh wrote:
| > On Sat, 18 Nov 2006 08:53:36 +0100 Marius Mauch <[hidden email]>
| > wrote:
| > | Anyone interested in this feature should review the attached
| > | version. Unless there are major objections (or we find large
| > | problems in the implementation) this will be merged in one of the
| > | next portage releases (definitely not in 2.1.2 though).
| >
| > 133594 will need to be fixed before this is usable for most users.
| >
| I'm sure it's been talked about before, but the ability to group
| licenses would solve that.  Just create a X.Org license group and add
| all the individual modular X licenses to it.

And then create a KDE licence group, and a Gnome licence group, and so
on? Remember that there are only a few X licences once you ignore
copyright line differences, just as there are only a few KDE licences
once you ignore copyright line differences.

--
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Brian Harring-2
In reply to this post by Brian Harring-2
On Sat, Nov 18, 2006 at 01:25:57PM -0800, Brian Harring wrote:
> > <groupname> <license1> <license2> ... <licenseN>

Minor addendum here (dotting the i's as it were), but valid license
names aren't actually defined anywhere; would suggest nailing down the
exact rules of it.

[a-Z][0-9]-_. looks to roughly cover it.

~harring

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Mike Doty
In reply to this post by Ciaran McCreesh-3
Ciaran McCreesh wrote:

> On Sat, 18 Nov 2006 15:22:36 -0600 Mike Doty <[hidden email]>
> wrote:
> | Ciaran McCreesh wrote:
> | > On Sat, 18 Nov 2006 08:53:36 +0100 Marius Mauch <[hidden email]>
> | > wrote:
> | > | Anyone interested in this feature should review the attached
> | > | version. Unless there are major objections (or we find large
> | > | problems in the implementation) this will be merged in one of the
> | > | next portage releases (definitely not in 2.1.2 though).
> | >
> | > 133594 will need to be fixed before this is usable for most users.
> | >
> | I'm sure it's been talked about before, but the ability to group
> | licenses would solve that.  Just create a X.Org license group and add
> | all the individual modular X licenses to it.
>
> And then create a KDE licence group, and a Gnome licence group, and so
> on? Remember that there are only a few X licences once you ignore
> copyright line differences, just as there are only a few KDE licences
> once you ignore copyright line differences.
>
The other option is to submit patches for X and KDE and Gnome to use a
unified license.  At least in the X case, it's not that the patches
arn't welcome, it's that the maintainers have things more important to
do than cleaning up after the mess upstream made of the licenses.

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Diego Elio Pettenò-3
On Saturday 18 November 2006 22:49, Mike Doty wrote:
> The other option is to submit patches for X and KDE and Gnome to use a
> unified license.
Would like to precise that KDE team reports correctly as GPL-2 or LGPL-2.1 the
licenses for every package. The only problem there is that there's no way to
differentiate between GPL-2 and GPL-2+ but that's beside the point.

So no, there's no need to submit patches to the KDE team. I think the same
applies to GNOME, but I'll leave those who handle that to answer by
theirselves.

--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Ciaran McCreesh-3
In reply to this post by Mike Doty
On Sat, 18 Nov 2006 13:49:12 -0800 Mike Doty <[hidden email]>
wrote:
| The other option is to submit patches for X and KDE and Gnome to use
| a unified license.  At least in the X case, it's not that the patches
| arn't welcome, it's that the maintainers have things more important
| to do than cleaning up after the mess upstream made of the licenses.

So you're saying that the X maintainers have more important things to
do than fixing their ebuilds to follow policy?

--
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Ciaran McCreesh-3
In reply to this post by Diego Elio Pettenò-3
On Sat, 18 Nov 2006 22:59:36 +0100 "Diego 'Flameeyes' Pettenò"
<[hidden email]> wrote:
| So no, there's no need to submit patches to the KDE team. I think the
| same applies to GNOME, but I'll leave those who handle that to answer
| by theirselves.

Right. Gnome is also correct, despite having lots of packages that use
maybe a dozen licences between them. Which was my point... Everyone
else manages to get it right...

--
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Stephen P. Becker
In reply to this post by Mike Doty
> > And then create a KDE licence group, and a Gnome licence group, and
> > so on? Remember that there are only a few X licences once you ignore
> > copyright line differences, just as there are only a few KDE
> > licences once you ignore copyright line differences.
> >
> The other option is to submit patches for X and KDE and Gnome to use
> a unified license.  At least in the X case, it's not that the patches
> arn't welcome, it's that the maintainers have things more important
> to do than cleaning up after the mess upstream made of the licenses.
>

The problem is being overlooked here.  Fact is, a feature
which *is* being added to portage in the next few releases will be very
problematic for folks wishing to install X using portage.  Whether the
X maintainers feel they have time or not is irrelevant if the portage
devs go ahead with this.

-Steve

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Jason Stubbs
In reply to this post by Brian Harring-2
On Sunday 19 November 2006 06:25, Brian Harring wrote:
> Left out that if it's unset, it should default to ACCEPT_LICENSE=* ,
> meaning no license filtering.

[...]

> > Backwards Compatibility
> > =======================
> >
> > There should be no change to the user experience without the user
> > explicitly choosing to do so.  This mandates that the
> > configuration variable be named ``ACCEPT_LICENSE`` as some users may
> > already have it set due to ebuilds using ``eutil.eclass``'s
> > implementation.  It also mandates that the default ``ACCEPT_LICENSE`` be
> > set to ``@NON-INTERACTIVE`` in the main gentoo repository as there will
> > be no internal default in portage.
>
> The current default in portage however is that of ACCEPT_LICENSE=*;
> since portage doesn't yet filter on licenses, and since interactive
> ebuilds already exist, _that_ is the default.
>
> Finally, NON-INTERACTIVE shouldn't be a license group;
> RESTRICT=interactive is the route there; you can have gpl software
> distributed on cds that must be interactive (feed cds in as
> requested).
>
> The only solution there would to be to invent a fake license group for
> it and tag it in... which is not what license is about.
>
> Interactivity is a seperate thing from license; keep it that way.

You're missing the point. It is nothing to do with interactivity. It is to do
with check_license and ebuilds for packages that must have their license
explicitly accepted. In other words there should be no "*" and the default
ACCEPT_LICENSE should default to everything except ebuilds that are currently
using check_license. The NON-INTERACTIVE group specified in the original GLEP
specified that set.

--
Jason Stubbs
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Brian Harring-2
On Mon, Nov 20, 2006 at 08:05:03PM +0900, Jason Stubbs wrote:

> On Sunday 19 November 2006 06:25, Brian Harring wrote:
> > The current default in portage however is that of ACCEPT_LICENSE=*;
> > since portage doesn't yet filter on licenses, and since interactive
> > ebuilds already exist, _that_ is the default.
> >
> > Finally, NON-INTERACTIVE shouldn't be a license group;
> > RESTRICT=interactive is the route there; you can have gpl software
> > distributed on cds that must be interactive (feed cds in as
> > requested).
> >
> > The only solution there would to be to invent a fake license group for
> > it and tag it in... which is not what license is about.
> >
> > Interactivity is a seperate thing from license; keep it that way.
>
> You're missing the point. It is nothing to do with interactivity.
*Cough*, you do realize you're saying that 'NON-INTERACTIVE' has
nothing to do with interactivity, right?  If that's the case, I'd
suggest y'all find a better name for "NON-INTERACTIVE" ;-)

Meanwhile, the point that interactivty requires a seperate mechanism
still stands (see gpl example above).

Read on please, despite the jokes what I'm trying to make y'all see is
that interactivity (literal, the ebuild waits on stdin) is a seperate
thing from LICENSE (even if a specific license may always require
interactive confirmation), as such using such a name (let alone it as
default) doesn't make much sense.


> It is to do
> with check_license and ebuilds for packages that must have their license
> explicitly accepted.

And what of cdrom_get_cds and friends?  They're going to require a
restrict due to them being interactive, unless y'all are proposing a
special case addition to the ebuilds restrict for when its license is
a member of NON-INTERACTIVE...

ACCEPT_LICENSE is just a visibility filter on what the user is willing
to deal with; it's not a binding agreement to that particular license
(wouldn't have to use check_license for EULAs if that were the case),
as such the mechanism of actually *accepting* the license is outside
of ACCEPT_LICENSE's purview.

It's just a filter on *licenses*, not on the mechanism of accepting a
license.  Try to cram interactivity into it (even if just a badly
labeled license group name), give more meaning to the group then what
LICENSE is actually about.  Label it EULA's if you like.

Short and sweet, you still need a matching restrict; as such such a
default/name is bleeding restrict into license; again, they're
seperate things.


> In other words there should be no "*" and the default
> ACCEPT_LICENSE should default to everything except ebuilds that are currently
> using check_license.

Again... what of cdrom_load_next_cd and friends?  That functionality
(which can require interactivity) may be dealing strictly in GPL code.

Do you really think a user who hits that is going to care that
NON-INTERACTIVE actually means "non click through EULA licenses"?  
They're going to be annoyed that the set NON-INTERACTIVE, came back 4
hours later to find that portage is hung waiting on interactive input.

In other words... the name at the very least seriously sucks, but
wait, theres more! :)


> The NON-INTERACTIVE group specified in the original GLEP
> specified that set.

Then the glep is inconsistant, since the backwards compatibility
claims-
"There should be no change to the user experience without the user
explicitly choosing to do so."

NON-INTERACTIVE obviously is not accept all licenses, as such there
*is* a change in the behaviour.

Further, if you think through the implications of such a label, you're
going to realize that without the matching restrict (which is the
*real* filtering of interactive ebuilds), someone is going to wind up
shoving a fake license into NON-INTERACTIVE for a license that doesn't
require user click through.

My suggestion would be to drop the NON-INTERACTIVE crap, go back to
the '*' original assumptino folks had, and finish off glep52; either
that or find a helluva lot better name for NON-INTERACTIVE since it's
duplication of what glep52 should address.

~harring

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Donnie Berkholz-2
In reply to this post by Ciaran McCreesh-3
Ciaran McCreesh wrote:
> On Sat, 18 Nov 2006 13:49:12 -0800 Mike Doty <[hidden email]>
> wrote:
> | The other option is to submit patches for X and KDE and Gnome to use
> | a unified license.  At least in the X case, it's not that the patches
> | arn't welcome, it's that the maintainers have things more important
> | to do than cleaning up after the mess upstream made of the licenses.
>
> So you're saying that the X maintainers have more important things to
> do than fixing their ebuilds to follow policy?

You keep saying it breaks policy but you've never actually cited any
policy it breaks.

And yes, I do have better things to do than incredibly boring tasks like
this. I do Gentoo stuff because it's interesting. If this interests you,
submit a patch -- it would probably take less time than all the
complaining you've done about it.

Thanks,
Donnie
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Duncan-42
In reply to this post by Marius Mauch
Marius Mauch <[hidden email]> posted
[hidden email], excerpted below, on
Sat, 18 Nov 2006 08:53:36 +0100:

> ACCEPT_LICENSE
> --------------
>
> This GLEP proposes that a user be able to explicitly accept or decline
> licenses by editing a new variable ``ACCEPT_LICENSE`` in
> ``/etc/make.conf``.

> As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.
> This GLEP proposes that the license group be prepended by the special
> character "``@``".

> Portage Behaviour
> -----------------
>
> Unaccepted licenses will be treated like any other masked package, that
> is emerge will display a message listing any license that has to be
> accepted before the package can be merged with a pointer to the exact
> license text.

Suggested that a per-package user-override file be specified as well,
along with its format. Call it package.license or whatever.  The idea being
that a user may wish to accept a specific license for a specific package,
but not globally.

This being Gentoo, this is likely to be implemented anyway, but specifying
it and its format in the glep standardizes it, useful when multiple
package managers are a factor.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Ciaran McCreesh-3
In reply to this post by Donnie Berkholz-2
On Sun, 19 Nov 2006 00:10:59 -0800 Donnie Berkholz
<[hidden email]> wrote:
| > So you're saying that the X maintainers have more important things
| > to do than fixing their ebuilds to follow policy?
|
| You keep saying it breaks policy but you've never actually cited any
| policy it breaks.

It breaks GLEP 23, which is an accepted GLEP and thus policy.

It also flies in the face of how everyone else does their thing. You
don't see one licence per package for anything else.

| And yes, I do have better things to do than incredibly boring tasks
| like this. I do Gentoo stuff because it's interesting.

That is not an excuse to commit broken things that hurt the users.

--
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Donnie Berkholz-2
Ciaran McCreesh wrote:
> On Sun, 19 Nov 2006 00:10:59 -0800 Donnie Berkholz
> <[hidden email]> wrote:
> | > So you're saying that the X maintainers have more important things
> | > to do than fixing their ebuilds to follow policy?
> |
> | You keep saying it breaks policy but you've never actually cited any
> | policy it breaks.
>
> It breaks GLEP 23, which is an accepted GLEP and thus policy.

Which part of GLEP 23 does it break? Please show me the text.

Thanks,
Donnie
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Alec Warner-2
Ciaran McCreesh wrote:

> On Sun, 19 Nov 2006 12:13:33 -0800 Donnie Berkholz
> <[hidden email]> wrote:
> | Ciaran McCreesh wrote:
> | > On Sun, 19 Nov 2006 00:10:59 -0800 Donnie Berkholz
> | > <[hidden email]> wrote:
> | > | > So you're saying that the X maintainers have more important
> | > | > things to do than fixing their ebuilds to follow policy?
> | > |
> | > | You keep saying it breaks policy but you've never actually cited
> | > | any policy it breaks.
> | >
> | > It breaks GLEP 23, which is an accepted GLEP and thus policy.
> |
> | Which part of GLEP 23 does it break? Please show me the text.
>
> Cut the crap, Donnie. We all know you're not that stupid, so stop
> pretending you are.
>

I'd ask that you not give him the runaround and just answer the
question; that or drop it.

Thanks,
Alec Warner
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Donnie Berkholz-2
In reply to this post by Donnie Berkholz-2
Ciaran McCreesh wrote:
> On Sun, 19 Nov 2006 12:13:33 -0800 Donnie Berkholz
> <[hidden email]> wrote:
> | Which part of GLEP 23 does it break? Please show me the text.
>
> Cut the crap, Donnie. We all know you're not that stupid, so stop
> pretending you are.

How is it stupid to ask that you cite actual text from a policy when you
say I'm violating it? I think this makes the third time I've asked now
without ever seeing any concrete evidence.

I've read through GLEP 23 a few times now and frankly I'm sick of
dealing with licensing. If I gave a crap about it, I'd be using Debian.

Thanks,
Donnie
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: ACCEPT_LICENSE revisited

Ciaran McCreesh-3
In reply to this post by Alec Warner-2
On Sun, 19 Nov 2006 19:17:35 -0500 Alec Warner <[hidden email]>
wrote:
| I'd ask that you not give him the runaround and just answer the
| question; that or drop it.

What, you really think that Donnie doesn't know how the X licence
handling situation breaks GLEP 23? Just how exactly is ACCEPT_LICENSE
usable when you have this?

ciaranm@snowdrop licenses 0 0.05 $ fdupes . | tr $'\n' '~' | sed -e
's,~~,\n\n,g' -e 's,~, ,g' -e 's~\./~~g'

xorg-sgml-doctools xf86-video-v4l encodings font-alias gccmakedep
mkfontdir

xplsprinters libXprintAppUtil

xfindproxy xproxymanagementprotocol proxymngr

font-misc-misc font-micro-misc

font-bitstream-type1 LICENSE-BITSTREAM

font-bitstream-75dpi font-bitstream-100dpi

font-bh-lucidatypewriter-75dpi font-bh-lucidatypewriter-100dpi

font-bh-ttf font-bh-type1

font-bh-75dpi font-bh-100dpi

font-adobe-utopia-type1 font-adobe-utopia-100dpi font-adobe-utopia-75dpi

font-adobe-100dpi font-adobe-75dpi

xwud appres bdftopcf editres fslsfonts fstobdf oclock smproxy
xclipboard xbitmaps xconsole xf86dga xfd xfsinfo xlsclients xkill xlogo
xlsatoms xlsfonts xmag xmodmap xset xsm xstdcmap xwd xwininfo

xvinfo xf86-input-magictouch xf86-input-palmax xf86-video-apm
xf86-video-dummy xf86-video-fbdev xf86-video-vmware

xsetmode xsetpointer

xload xcalc

xgc xditview xeyes

xf86miscproto resourceproto xf86dgaproto xf86bigfontproto

xf86-video-vga xf86-video-rendition

xf86-video-suntcx xf86-video-sunleo

xf86-video-suncg6 xf86-video-sunbw2 xf86-video-suncg14 xf86-video-suncg3

xf86-input-spaceorb xf86-input-magellan

xbiff listres viewres

libdmx dmxproto

And that's just the start. Many of those groups differ only by
whitespace or copyright lines.

If you really want policy, though, try [1]:

"If your package's license is not already in the tree, you must add the
license before committing the package."

Now, you can argue semantics and claim that it doesn't say "don't add
it if it's already there". If you're playing that game, however, then
it's entirely ok to add twenty new packages to the tree all of which
install exactly the same thing, or ten identical eclasses that differ
only by the ECLASS name.

[1] http://devmanual.gentoo.org/general-concepts/licenses/index.html

--
Ciaran McCreesh
Mail                : ciaranm at ciaranm.org
Web                 : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13


signature.asc (196 bytes) Download Attachment
1234