public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Patrick Lauer <patrick@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Questions about licenses
Date: Wed, 15 Jun 2005 13:44:12 +0200	[thread overview]
Message-ID: <1118835852.6572.5.camel@localhost> (raw)
In-Reply-To: <87u0jzhnrh.fsf@veller.net>

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

On Wed, 2005-06-15 at 13:18 +0200, Torsten Veller wrote:
> Why do we add a license to the licenses/ dir?
Because there should be an easy way to find licenses?
And you can do "emerge search foo", then read the license and decide
wether you want to install foo.

> And in addition: When should a license be added to licenses/ ?
When at least one ebuild uses a license that is not already there?

> Do we only add those licenses to define valid names for the LICENSE
> variable?
AFAIK the license variable is not really used (someone correct me if I'm mistakne, please)

> There are over 3MB in nearly 500 files. How will those licenses be
> classified if ACCEPT_LICENSES (GLEP 23) is implemented?
I guess groups ... OSI approved, "free", commercial, ...

> Does the language of the license matter? (selfhtml is in german)
I think licenses in English are preferred, but if it's only licensed with a german license ...
> Aren't MIT and MetaKit and ... the same license?
> Aren't X11 and cdegood and JamesClark and ... the same license?
Maybe there's one paragraph changed - I haven't looked at them yet.
> Should the licenses/ dir be cleaned?
If by cleaned you mean unused licenses removed yes. If by cleaned you
mean "reduced to the bare minimum" I'd say no.
> (Should placeholders be used as in MIT?)
> 
> What about all these /usr/share/doc/*/COPYING* files? Are they
> necessary if all licenses are in licenses/ ?
See first point. You want to read the license _before_ installing stuff
> (Am i asking too many questions? 
No ;-)
> Sorry, but i have the feeling that
> this whole license stuff is not useful atm and i don't see how we
> can deal with the great number of files in the future.)
I haven't seen this as a problem - it has worked quite well up to now.
Your concerns are valid, but as long as nobosy offers an alternative for
managing licenses, I wouldn't change our policy - doesn't seem broken to
me.

Patrick
-- 
Stand still, and let the rest of the universe move

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

  parent reply	other threads:[~2005-06-15 11:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-15 11:18 [gentoo-dev] Questions about licenses Torsten Veller
2005-06-15 11:31 ` Krzysiek Pawlik
2005-06-15 11:39   ` Jon Portnoy
2005-06-15 12:00     ` Krzysiek Pawlik
2005-06-15 12:14       ` Jon Portnoy
2005-06-15 12:29         ` Krzysiek Pawlik
2005-06-15 14:02   ` Chris Gianelloni
2005-06-15 14:07     ` Krzysiek Pawlik
2005-06-15 11:44 ` Patrick Lauer [this message]
2005-06-15 14:04   ` Chris Gianelloni
2005-06-15 16:26     ` Maurice van der Pot
2005-06-15 18:38       ` Chris Bainbridge
2005-06-15 19:06         ` Chris Gianelloni
2005-06-16 22:12   ` [gentoo-dev] " Torsten Veller
2005-06-16 23:06     ` Marius Mauch
2005-06-17 10:09       ` Chris Bainbridge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1118835852.6572.5.camel@localhost \
    --to=patrick@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox