1 |
Domen Kožar <domen@×××.si> said: |
2 |
> This should probably be updated: |
3 |
> |
4 |
> http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#flash |
5 |
|
6 |
Thanks for noticing this. Everybodies input makes Gentoo a great place to |
7 |
be! |
8 |
|
9 |
Now, if you want that extra chocolate chip cookie, please head over to |
10 |
https://bugs.gentoo.org and report the issue there. ;-) |
11 |
(remember to search for duplicates first). |
12 |
|
13 |
Thanks |
14 |
kind regards |
15 |
Thilo |
16 |
|
17 |
|
18 |
> |
19 |
> On Fri, 2010-06-18 at 15:58 +0200, Angelo Arrifano wrote: |
20 |
> > On 18-06-2010 12:16, Alec Warner wrote: |
21 |
> > > On Fri, Jun 18, 2010 at 2:08 AM, Lars Wendler <polynomial- |
22 |
c@g.o> wrote: |
23 |
> > >> Am Freitag 18 Juni 2010, 03:42:29 schrieb Brian Harring: |
24 |
> > >>> On Thu, Jun 17, 2010 at 05:14:16PM -0500, Dale wrote: |
25 |
> > >>>> Lars Wendler wrote: |
26 |
> > >>>>> Am Mittwoch 16 Juni 2010, 14:45:21 schrieb Angelo Arrifano: |
27 |
> > >>>>>> On 16-06-2010 14:40, Jim Ramsay wrote: |
28 |
> > >>>>>>> Chí-Thanh Christopher Nguyễn<chithanh@g.o> wrote: |
29 |
> > >>>>>>>> One notable section is 7.6 in which Adobe reserves the right |
30 |
> > >>>>>>>> to download and install additional Content Protection |
31 |
> > >>>>>>>> software on the user's PC. |
32 |
> > >>>>>>> |
33 |
> > >>>>>>> Not like anyone will actually *read* the license before |
34 |
> > >>>>>>> adding it to their accept group, but if they did this would |
35 |
> > >>>>>>> indeed be an important thing of which users should be aware. |
36 |
> > >>>>>> |
37 |
> > >>>>>> I defend it is our job to warn users about this kind of |
38 |
> > >>>>>> details. To me it sounds that a einfo at post-build phase |
39 |
> > >>>>>> would do the job, what do you guys think? |
40 |
> > >>>>> |
41 |
> > >>>>> Definitely yes! This is a very dangerous snippet in Adobe's |
42 |
> > >>>>> license which should be pretty clearly pointed at to every |
43 |
> > >>>>> user. |
44 |
> > >>>> |
45 |
> > >>>> Could that also include a alternative to adobe? If there is |
46 |
> > >>>> one. |
47 |
> > >>> |
48 |
> > >>> The place to advocate free alternatives (or upstreams that are |
49 |
> > >>> nonsuck) isn't in einfo messages in ebuilds, it's on folks blogs |
50 |
> > >>> or at best in metadata.xml... einfo should be "this is the |
51 |
> > >>> things to watch for in using this/setting it up" not "these guys |
52 |
> > >>> are evil, use one of the free alternatives!". |
53 |
> > |
54 |
> > Why? You are running a free and opensource operating system, what's |
55 |
> > wrong suggesting *other* free and opensource alternatives? You are |
56 |
> > just providing the user a choice, not to actually oblige him to |
57 |
> > install anything. |
58 |
> > |
59 |
> > Also, I'm pretty sure seeing nvidia-drivers suggesting the use of the |
60 |
> > kernel driver when using the hardened profile. |
61 |
> > |
62 |
> > >> Maybe I expressed myself a bit misinterpretative. I don't want to |
63 |
> > >> request an elog message telling users about alternative packages. |
64 |
> > >> But in my opinion an elog message pointing at the bald-faced |
65 |
> > >> parts of Adobe's license should be added. These parts about |
66 |
> > >> allowing Adobe to install further content protection software is |
67 |
> > >> just too dangerous in my opinion. |
68 |
> > > |
69 |
> > > I will ignore the technical portion where basically any binary on |
70 |
> > > your system; even binaries you compiled yourself have the ability |
71 |
> > > to 'install things you do not like' when run as root (and |
72 |
> > > sometimes when run as a normal user as well.) |
73 |
> > |
74 |
> > For all the years running Linux, I never found that case. |
75 |
> > |
76 |
> > > The real meat here is that you want Gentoo to take some kind of |
77 |
> > > stand on particular licensing terms. I don't think this is a good |
78 |
> > > precedent[0] to set for our users. It presumes we will |
79 |
> > > essentially read the license in its entirety and inform users of |
80 |
> > > the parts that we think are 'scary.'[1] The user is the person |
81 |
> > > who is installing and running the software. The user is the |
82 |
> > > person who should be reading and agreeing with any licensing terms |
83 |
> > > lest they find the teams unappealing. I don't find it |
84 |
> > > unreasonable to implement a tool as Duncan suggested because it is |
85 |
> > > not a judgement but a statement of fact. "The license for app/foo |
86 |
> > > has changed from X to Y. You should review the changes |
87 |
> > > accordingly by running <blah>" |
88 |
> > |
89 |
> > I'm the person who initially proposed warning users on elog. The |
90 |
> > initial proposal only states about: |
91 |
> > 1) A warning about change of licensing terms. |
92 |
> > 2) A warning that "additional Content Protection software" might be |
93 |
> > installed without users consent. |
94 |
> > |
95 |
> > In fact, portage already warns the users about bad coding practices, |
96 |
> > install of executables with runtime text relocations, etc.. How is |
97 |
> > this different? |
98 |
> > If me, as a user, didn't know about such detail (who reads software |
99 |
> > license agreements anyway?) and someday I hypothetically find a |
100 |
> > executable running without my permission as my user account and I'm |
101 |
> > able to associate it with Adobe's flash, I would be pissed off to no |
102 |
> > extent. And guess what? First thing I would *blame* is flash |
103 |
> > maintainers. I expect package maintainers to be more familiar with |
104 |
> > the packages they maintain than me. As consequence, I expect them to |
105 |
> > advice me about non-obvious details on those packages. At least |
106 |
> > that's what I try to do on the packages I maintain. |
107 |
> > GNU/Linux is all about choice. Stating, during install, that a |
108 |
> > package might later install additional stuff will just provide a |
109 |
> > choice to the user, not conditioning it. |
110 |
> > |
111 |
> > Regards, |
112 |
> > - Angelo |
113 |
> > |
114 |
> > > [0] There is an existing precedent for reading the license and |
115 |
> > > ensuring Gentoo itself is not violating the license by distributing |
116 |
> > > said software. Gentoo takes measures to reduce its own liability |
117 |
> > > in case a lawsuit arises; however this is a pretty narrow case. |
118 |
> > > [1] The other bad part here is that 'scary' is itself a judgement |
119 |
> > > call about licensing terms. I do not want to have arguments with |
120 |
> > > users about which terms I should have to warn them about versus |
121 |
> > > not. Users should (ideally) be reading the software licenses for |
122 |
> > > software they choose to use. |
123 |
> > > |
124 |
> > > -A |
125 |
> > > |
126 |
> > >>> Grok? |
127 |
> > >>> |
128 |
> > >>> ~harring |
129 |
> > >> |
130 |
> > >> -- |
131 |
> > >> Lars Wendler (Polynomial-C) |
132 |
> > >> Gentoo developer and bug-wrangler |