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 --]
next prev 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