From: Thilo Bangert <bangert@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
Date: Thu, 24 Jun 2010 07:59:00 +0200 [thread overview]
Message-ID: <201006240759.03435.bangert@gentoo.org> (raw)
In-Reply-To: <1277318470.5556.0.camel@oblak>
[-- Attachment #1: Type: Text/Plain, Size: 6239 bytes --]
Domen Kožar <domen@dev.si> said:
> This should probably be updated:
>
> http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#flash
Thanks for noticing this. Everybodies input makes Gentoo a great place to
be!
Now, if you want that extra chocolate chip cookie, please head over to
https://bugs.gentoo.org and report the issue there. ;-)
(remember to search for duplicates first).
Thanks
kind regards
Thilo
>
> On Fri, 2010-06-18 at 15:58 +0200, Angelo Arrifano wrote:
> > On 18-06-2010 12:16, Alec Warner wrote:
> > > On Fri, Jun 18, 2010 at 2:08 AM, Lars Wendler <polynomial-
c@gentoo.org> wrote:
> > >> Am Freitag 18 Juni 2010, 03:42:29 schrieb Brian Harring:
> > >>> On Thu, Jun 17, 2010 at 05:14:16PM -0500, Dale wrote:
> > >>>> Lars Wendler wrote:
> > >>>>> Am Mittwoch 16 Juni 2010, 14:45:21 schrieb Angelo Arrifano:
> > >>>>>> On 16-06-2010 14:40, Jim Ramsay wrote:
> > >>>>>>> Chí-Thanh Christopher Nguyễn<chithanh@gentoo.org> wrote:
> > >>>>>>>> One notable section is 7.6 in which Adobe reserves the right
> > >>>>>>>> to download and install additional Content Protection
> > >>>>>>>> software on the user's PC.
> > >>>>>>>
> > >>>>>>> Not like anyone will actually *read* the license before
> > >>>>>>> adding it to their accept group, but if they did this would
> > >>>>>>> indeed be an important thing of which users should be aware.
> > >>>>>>
> > >>>>>> I defend it is our job to warn users about this kind of
> > >>>>>> details. To me it sounds that a einfo at post-build phase
> > >>>>>> would do the job, what do you guys think?
> > >>>>>
> > >>>>> Definitely yes! This is a very dangerous snippet in Adobe's
> > >>>>> license which should be pretty clearly pointed at to every
> > >>>>> user.
> > >>>>
> > >>>> Could that also include a alternative to adobe? If there is
> > >>>> one.
> > >>>
> > >>> The place to advocate free alternatives (or upstreams that are
> > >>> nonsuck) isn't in einfo messages in ebuilds, it's on folks blogs
> > >>> or at best in metadata.xml... einfo should be "this is the
> > >>> things to watch for in using this/setting it up" not "these guys
> > >>> are evil, use one of the free alternatives!".
> >
> > Why? You are running a free and opensource operating system, what's
> > wrong suggesting *other* free and opensource alternatives? You are
> > just providing the user a choice, not to actually oblige him to
> > install anything.
> >
> > Also, I'm pretty sure seeing nvidia-drivers suggesting the use of the
> > kernel driver when using the hardened profile.
> >
> > >> Maybe I expressed myself a bit misinterpretative. I don't want to
> > >> request an elog message telling users about alternative packages.
> > >> But in my opinion an elog message pointing at the bald-faced
> > >> parts of Adobe's license should be added. These parts about
> > >> allowing Adobe to install further content protection software is
> > >> just too dangerous in my opinion.
> > >
> > > I will ignore the technical portion where basically any binary on
> > > your system; even binaries you compiled yourself have the ability
> > > to 'install things you do not like' when run as root (and
> > > sometimes when run as a normal user as well.)
> >
> > For all the years running Linux, I never found that case.
> >
> > > The real meat here is that you want Gentoo to take some kind of
> > > stand on particular licensing terms. I don't think this is a good
> > > precedent[0] to set for our users. It presumes we will
> > > essentially read the license in its entirety and inform users of
> > > the parts that we think are 'scary.'[1] The user is the person
> > > who is installing and running the software. The user is the
> > > person who should be reading and agreeing with any licensing terms
> > > lest they find the teams unappealing. I don't find it
> > > unreasonable to implement a tool as Duncan suggested because it is
> > > not a judgement but a statement of fact. "The license for app/foo
> > > has changed from X to Y. You should review the changes
> > > accordingly by running <blah>"
> >
> > I'm the person who initially proposed warning users on elog. The
> > initial proposal only states about:
> > 1) A warning about change of licensing terms.
> > 2) A warning that "additional Content Protection software" might be
> > installed without users consent.
> >
> > In fact, portage already warns the users about bad coding practices,
> > install of executables with runtime text relocations, etc.. How is
> > this different?
> > If me, as a user, didn't know about such detail (who reads software
> > license agreements anyway?) and someday I hypothetically find a
> > executable running without my permission as my user account and I'm
> > able to associate it with Adobe's flash, I would be pissed off to no
> > extent. And guess what? First thing I would *blame* is flash
> > maintainers. I expect package maintainers to be more familiar with
> > the packages they maintain than me. As consequence, I expect them to
> > advice me about non-obvious details on those packages. At least
> > that's what I try to do on the packages I maintain.
> > GNU/Linux is all about choice. Stating, during install, that a
> > package might later install additional stuff will just provide a
> > choice to the user, not conditioning it.
> >
> > Regards,
> > - Angelo
> >
> > > [0] There is an existing precedent for reading the license and
> > > ensuring Gentoo itself is not violating the license by distributing
> > > said software. Gentoo takes measures to reduce its own liability
> > > in case a lawsuit arises; however this is a pretty narrow case.
> > > [1] The other bad part here is that 'scary' is itself a judgement
> > > call about licensing terms. I do not want to have arguments with
> > > users about which terms I should have to warn them about versus
> > > not. Users should (ideally) be reading the software licenses for
> > > software they choose to use.
> > >
> > > -A
> > >
> > >>> Grok?
> > >>>
> > >>> ~harring
> > >>
> > >> --
> > >> Lars Wendler (Polynomial-C)
> > >> Gentoo developer and bug-wrangler
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-06-24 5:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-14 21:20 [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group Chí-Thanh Christopher Nguyễn
2010-06-16 12:40 ` Jim Ramsay
2010-06-16 12:45 ` Angelo Arrifano
2010-06-17 22:06 ` Lars Wendler
2010-06-17 22:14 ` Dale
2010-06-17 22:37 ` Chí-Thanh Christopher Nguyễn
2010-06-17 23:20 ` Lars Wendler
2010-06-18 1:42 ` Brian Harring
2010-06-18 6:10 ` Dale
2010-06-18 9:08 ` Lars Wendler
2010-06-18 10:16 ` Alec Warner
2010-06-18 13:58 ` Angelo Arrifano
2010-06-18 17:56 ` Brian Harring
2010-06-19 2:29 ` [gentoo-dev] " Duncan
2010-06-23 18:41 ` [gentoo-dev] " Domen Kožar
2010-06-24 5:59 ` Thilo Bangert [this message]
2010-06-19 2:25 ` [gentoo-dev] " Duncan
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=201006240759.03435.bangert@gentoo.org \
--to=bangert@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