1 |
I had a nice little discussion with someone today about commercial |
2 |
software in portage. His basic complaint was that there's no way to |
3 |
distinguish what software is commercial and what is not. The licenses |
4 |
are not always apparent in these things. Anyway, I had originally |
5 |
thought this to be something for metadata.xml, and if it is decided that |
6 |
is still the best place for it, then I'm all for it, but I'd like to |
7 |
present an alternate proposal. |
8 |
|
9 |
We could add a license, called "commercial" into the tree. This license |
10 |
would look like the following. |
11 |
|
12 |
"This is a license created by Gentoo to indicate that a package is of a |
13 |
commercial nature. The reasoning behind this is so users are aware that |
14 |
a package might not be in a 100% functional state without some form of |
15 |
user interaction, such as the addition of data files or a CD key after |
16 |
installation. |
17 |
|
18 |
This package, or portions of this package, fall under one or more |
19 |
commercial licenses and is not free." |
20 |
|
21 |
Basically, we just add "commercial" to LICENSE in the ebuild, and (if |
22 |
wanted or necessary) add "check_license $licese_required_to_be_accepted" |
23 |
to pkg_setup on the ebuild. While this will break completely |
24 |
interactive ebuilds until GLEP23 is fully implemented, a user can add |
25 |
the license to make.conf in an ACCEPT_LICENSE variable, to keep portage |
26 |
from asking again. This means when a user does an "emerge -S" they will |
27 |
see the nice little "commercial" listed under licenses, which will |
28 |
hopefully trigger to them that this package is not free. Another |
29 |
possible addition is a "commercial-free" license, which would cover |
30 |
things like America's Army and Enemy Territory (I'm sure there are |
31 |
others, but I know of these two) that are free for users to use, but are |
32 |
still commercial software. |
33 |
|
34 |
This would require us to make some modifications to a few ebuilds, |
35 |
though I know that most of the ebuilds using check_license are |
36 |
maintained by me. I'm willing to make all necessary changes in the tree |
37 |
for this to be seamless for our users. The only packages which will |
38 |
interactively ask the user to accept a license are the ones that do so |
39 |
currently. |
40 |
|
41 |
So now I ask, can anyone think of a reason not to do this, or a better |
42 |
way to go about it? |
43 |
|
44 |
-- |
45 |
Chris Gianelloni |
46 |
Release Engineering - Strategic Lead |
47 |
Games - Developer |
48 |
Gentoo Linux |