Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
Domen Kožar 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 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 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 " > > > > 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 >
Re: [gentoo-dev] council manifesto for ferringb
On Thu, 24 Jun 2010 07:31:07 +0200 "Paweł Hajdan, Jr." wrote: > I'd rather have git soon with longer, but acceptable outage, than in > the future, with a very small outage. I'd like some documentation to be finished before the switch is made. I have no idea how to commit patches using git yet, let alone how to change my workflow or how sources.g.o is going to display these or how packages.g.o is going to be adapted for git use. I could go on. :) jer
Re: [gentoo-dev] council manifesto for ferringb
On 6/24/10 3:42 AM, Brian Harring wrote: > Simplest example, I want the git migration plan finished- since robin > was overloaded and no one was doing it, I chipped in the work I could > do (optimization of the conversion so it wasn't a full day outage). I respect your work on this, and really hope the git migration will go just great. However, I'm wondering why we're delaying the migration to minimize the outage instead of doing the migration earlier? I'd rather have git soon with longer, but acceptable outage, than in the future, with a very small outage. On the other hand, I'm not familiar with the technical side and possibly other reasons that may prevent us from "closing the tree" for a long period of time. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] council manifesto for ferringb
Pardon the delay in sending this folks- been playing w/ the wording a bit more than I should've. Feel free to ask whatever question's you'd like answered- I'll keep a copy of the manifesto at http://pkgcore.org/~ferringb/council-manifesto-2010.txt which will be updated as needed for typo's and point clarifications. Manifesto follows- For those who don't know me, these days I work as a Distro Engineer, although over the last decade I've ran the gamut from basic embedded to web monkey to running OPs. Been a bit varied. For gentoo specifically, I've been active since mid 2003- same thing, my work has been a bit all over the map- split the first prefix branch, created EAPI, wrote the distfiles mirror content manager, founded/wrote pkgcore, and done a fair amount of portage work. Intermixed with that is a similar all over the map involvement in the tree, although these days my main interest/focus on the tree is QA. The point of this brag sheet is twofold; 1) I've got a pretty wide amount of technical experience to bring to the council (ranging from infra to imaging to simple ebuilds to explicit knowledge of package manager internals) 2) When something isn't getting done, I jump in and *get it done* rather than letting it sit. Simplest example, I want the git migration plan finished- since robin was overloaded and no one was doing it, I chipped in the work I could do (optimization of the conversion so it wasn't a full day outage). My purpose in running for the council is to apply the same approach- with due respect to the previous councils, there has been very little real activity that has come from the council. Requests pushed up to them have been ignored at the last minute (or without explanation), things have been voted on with questionable understanding of the actual proposal, and generally, they've not been incredibly useful. Finally, things have passed through the council with very little relation to reality. What I expect of the council, and will push w/in the council if elected is simply the principles of accountability and getting things done. Some examples of changes I'd like to see within the council- 1) Staggered elections- 2 elections a year, for example 3 council members in the summer, 4 in winter. The purpose of this is purely accountability- if the current council is abdicating their responsibilities, we aren't waiting a year, the council's feet are continually held to the fire. This additionally provides stability instead of the jarring once a year swap of the full council. Finally note that if this were accepted, to make it easier to get implemented I'd willingly go through an early election (would just need 2 other council members for it to be pulled off in that case). 2) While hard to enforce (let alone define rules for), sanctions/early election proceedings for members who repeatedly don't read the reference materials for what they're going to be discussing that month. It wastes everyones time, and it stalls decisions yet another month. Pretty much I believe that if you want to be a council member you better be willing to do the work. If you won't/can't, then don't run, simple as that. Please also note that #1 and #2 require community vote to actually accomplish also- I'm listing them since these are changes I'd like to see (and quite likely the process of getting that vote has to go through the council also). 3) Figuring out a way to get the council meeting and making decisions more frequently then once a month, for a single hour. We should strive to do more than just the mininum specified in glep39. 4) Proposals brought forth to the council need an actual plan of implementation- by opensources nature, the council cannot just say "go implement EAPI4"- we're all volunteers. Via requiring people to have at least the semblence of a plan (including patches/devs attached to it), this will allow things to go faster, decisions made by the council to actually become reality within the year. 5) On the flipside, the council should be actively trying to help w/ the things it thinks should go through- if the council thinks the web redesign should go through, actively searching for folk to help, tracing down what has been done, what needs doing, etc. In this respect the council should be active rather than passive- if the ball is being dropped, they should be trying to track it and get it back on course. Now I wish I could promise voters that if I were elected, all of these things would be accomplished- I won't blindly promise things that I cannot gurantee. I can only promise to bring this approach to the council if elected. Finally please understand that while I am critical of preceeding councils, I don't wish to completely tear down what they have accomplished. To improve and move forward requires taking a hard but realistic look at what has led to this point- hopefully I've managed just that in my manifesto. pgpbdgeT7hgnA.pgp Description: PGP signature
Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
This should probably be updated: http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml#flash 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 > > 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 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 " > > 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 a
[gentoo-dev] Lastrite: dev-libs/ccmath sci-calculators/rpc
# Justin Lecher (16 Jun 10) # Masked for removal in 14 days. # quite old, bug #214548 not worth a fix # superseeded by more functional sci-calculators/orpie dev-libs/ccmath sci-calculators/rpc signature.asc Description: OpenPGP digital signature
