10:09 a.m.
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Please see:
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
and direct any comments to FESCo in a ticket or via the devel list.
Thanks, and sorry for the oversight. ;(
kevin
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
10:45 a.m.
On Mon, May 18, 2009 at 9:09 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Please see:
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
and direct any comments to FESCo in a ticket or via the devel list.
Thanks, and sorry for the oversight. ;(
kevin
The title of this policy didn't convey the correct meaning to my
software-oriented brain. I was wondering why the setting of boolean
values needed a policy. :-) In fact, I've got two problems with this
title:
1. The word "flags" has a well-established use in the software world; and
2. The "in Fedora" part is redundant since the policy document is
hosted on a Fedora-specific wiki.
Might I suggest changing the title to "Policy for Handling
Geopolitical Flags"? Even that is a bit wordy. How about
"Geopolitical Flag Policy"? I think you need "Geopolitical" in there
somewhere to avoid confusing software geeks like me.
--
Jerry James
http://www.jamezone.org/
10:52 a.m.
Jerry James wrote:
On Mon, May 18, 2009 at 9:09 AM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
1. The word "flags" has a well-established use in the software world; and
2. The "in Fedora" part is redundant since the policy document is
hosted on a Fedora-specific wiki.
Might I suggest changing the title to "Policy for Handling
Geopolitical Flags"? Even that is a bit wordy. How about
"Geopolitical Flag Policy"? I think you need "Geopolitical" in
there
somewhere to avoid confusing software geeks like me.
Country Flags\National Emblems ?
Frank
12:14 p.m.
On 05/18/2009 11:45 AM, Jerry James wrote:
On Mon, May 18, 2009 at 9:09 AM, Kevin Fenzi<kevin(a)scrye.com>
wrote:
> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in
> Fedora was approved.
>
> Due to an oversight, this policy was not announced here. ;(
>
> Please see:
>
> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
>
> and direct any comments to FESCo in a ticket or via the devel list.
>
> Thanks, and sorry for the oversight. ;(
>
> kevin
This policy tries to please everyone and in the end pleases no one.
There are two possibilities:
A) You cannot display certain flags in your country
B) You are free to display whichever country flags you want
In the first case (read China), you can't use fedora because it
includes -flag packages. Are we going to make a separate yum repo for
-flag as well? It's more likely that countries like these already
roll their own distros anyway. After all, it's free software. If you
don't like it, change it.
http://en.wikipedia.org/wiki/Red_Flag_Linux
In the second case, you create a lot more work for volunteers and
raise the ire of -devel-list (see 15k posts above this). Sure, there
was a debian developer that quit because the RoC flag didn't get
cleaned from the repo. The questions that still has yet to be asked
is, "How many volunteer maintainers didn't quit because of draconian
packaging guidelines?" I hope whomever makes the ultimate decision
keeps this in mind.
--
James M. Leddy
2:04 p.m.
Just some thoughts.
I would ask people, take time for your answers.
Go for a walk even.
After Reading:
https://www.redhat.com/archives/fedora-advisory-board/2009-May/msg00153.html
1: Has the flags policy, anything to do with RH becoming more prominent
on the site?
No problem with them becoming more prominent, they do sponsor a lot.
If yes, say so, likewise no
2: Would our main Sponsor, suffer financially.
As a result of inclusion of certain flags?
3: Would the fedora project survive, if there was no main sponsor?
4: What do our International Ambassadors feel on the ground?
Does anyone outside the project give a toss.
Frank
3:17 p.m.
On Fri, 2009-05-22 at 20:04 +0100, Frank Murphy wrote:
2: Would our main Sponsor, suffer financially.
As a result of inclusion of certain flags?
As far as Red Hat is concerned, a complete "no flags" policy in Fedora
would benefit Red Hat as it would save work removing flags from packages
at the Red Hat stage. The policy previously approved by FESCo would not
have helped Red Hat much, as Red Hat's policy is "no flags", and the
previous FESCo policy was substantially different, so significant
changes would still have been needed at the Red Hat level.
However, Red Hat isn't going to take its ball and leave if Fedora
doesn't approve a 'no flags' policy, it would just have to work a bit
harder.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:26 a.m.
On 05/22/2009 03:04 PM, Frank Murphy wrote:
1: Has the flags policy, anything to do with RH becoming more
prominent
on the site?
No problem with them becoming more prominent, they do sponsor a lot.
If yes, say so, likewise no
No. The fact that I authored the original flag policy had more to do
with my awareness of the prior unwritten "no flags" policy, and nothing
at all to do with Red Hat. Red Hat Legal did offer advice as to some of
the wording, but they did not mandate it, nor did Red Hat instigate the
creation of the flag policy.
2: Would our main Sponsor, suffer financially.
As a result of inclusion of certain flags?
No. As Adam said, having a "no flags" policy would make things slightly
simpler for Red Hat to compose RHEL, but not enough to suffer any
significant financial consequence.
3: Would the fedora project survive, if there was no main sponsor?
Thankfully, this is a problem we do not have to be concerned about for
the time being.
~spot
10:53 a.m.
On Mon, May 18, 2009 at 5:09 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Please see:
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
and direct any comments to FESCo in a ticket or via the devel list.
May I kindly ask what is the reason behind this decision? Or, even
better, can someone update the above wiki page explaining the reason?
Thanks.
Andrea.
11:04 a.m.
Andrea Musuruane schrieb:
May I kindly ask what is the reason behind this decision? Or, even
better, can someone update the above wiki page explaining the reason?
Yes, I find this guideline anouyance. So a explaination, why we need this
policy may be helpful.
Best Regards:
Jochen Schmitt
11:08 a.m.
Jochen Schmitt wrote:
Andrea Musuruane schrieb:
> May I kindly ask what is the reason behind this decision? Or, even
> better, can someone update the above wiki page explaining the reason?
>
>
Yes, I find this guideline anouyance. So a explaination, why we need this
policy may be helpful.
Best Regards:
Jochen Schmitt
I was wondering as well. If it's a disk space issue, like the new font
guidelines, it makes sense, but otherwise at first blush it looks like a
solution in search of a problem. Not flaming, just drawing a blank on
the intended benefit. I agree that it should be on the wiki page.
--
in your fear, speak only peace
in your fear, seek only love
-d. bowie
11:31 a.m.
Jon Ciesla schrieb:
I was wondering as well. If it's a disk space issue, like the
new
font guidelines, it makes sense, but otherwise at first blush it looks
like a solution in search of a problem. Not flaming, just drawing a
blank on the intended benefit. I agree that it should be on the wiki
page.
Either we have a good reason for this guideline or we should throw it away.
We don't need a overregulation for creating packages.
Best Regards:
Jochen Schmitt
12:17 p.m.
On 05/18/2009 11:53 AM, Andrea Musuruane wrote:
May I kindly ask what is the reason behind this decision? Or, even
better, can someone update the above wiki page explaining the reason?
As the person who drafted the flags policy, let me try to explain the
rationale:
In January, Roozbeh Pournader posted to fedora-legal-list where he said
the following:
I recently found that Deluge is using country flags to indicate the
location of bittorrent peers. Flags are cute and nice of course (and a
mental exercise), but are geopolitical hot spots.
Upstream didn't like the concern, calling some people (including me?)
"crazy ideologists". But the Fedora maintainer (Peter Gordon) fixed
the bug in Rawhide (but we're still shipping flags in F9 and F10):
https://bugzilla.redhat.com/show_bug.cgi?id=479265
But this is not why I'm writing. I'm writing because during the
report, I found that we really don't have any official policy on
flags. All I found in the wiki was what I had written myself a while
ago, here, which is just based on my own experience as an i18n guy:
http://fedoraproject.org/wiki/Languages
#I_wish_to_use_my_country.27s_flag_to_refer_to_my_language
But we really need a policy. And I thought this list is the best forum
to get it into shape. The history is like this: With RHL 8.0, Red Hat
decided to remove the Taiwan/Republic of China flag from KDE because
of sensitivities/legal requirements of mainland/People's Rebublic of
China. That created some public unease, including people stopping to
use RHL because of that. Red Hat went a bit further of course, and
removed all national flags in a later version.
He raised some specific concerns, it is worth reading his original email:
http://www.mail-archive.com/fedora-legal-list@redhat.com/msg00206.html
At the time, the only policy in place was the informal, unwritten, no
flags policy that we inherited from Red Hat Linux. I consulted with Red
Hat Legal to codify that into a more formal policy for Fedora to use.
Red Hat Legal felt that there was minimal legal risk to including flags,
although, by having them, it may prevent Fedora from being
available/acceptable in some countries (China being a notable example).
Based on his original request (and his repeated reminders), I drafted
this policy and submitted it to FESCo for review. I did not tell FESCo
that they had to pass this for legal reasons (those sorts of things I'm
empowered to simply implement), nor did Red Hat require this. If FESCo
decides that they are not concerned about the possible geopolitical
controversy or possible international restrictions, there's no skin off
my back. I just drafted it upon the request of Fedora Community members.
Tom "spot" Callaway, Fedora Legal
11:12 a.m.
Am Montag, den 18.05.2009, 09:09 -0600 schrieb Kevin Fenzi:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
As such things have become more and more frequent I think we need to
figure out why it was not announce, who was responsible for announcing
it and how we can make sure it wont happen again.
Why are so many meeting minutes missing recently? Looking through my
mail for 2009 I see:
* 2009-05-15
* 2009-05-07 was in fact 2008-05-08 but never mind
* 2009-05-01 missing
* 2009-04-24 missing
* 2009-04-07 missing
* 2009-04-10
* 2009-04-03
* 2009-03-27 missing
* 2009-03-20 missing, this is the one with the flag proposal
* 2009-03-13 missing
* 2009-03-11 missing
* 2009-03-06
* 2009-03-03
* 2009-02-27
* 2009-02-20
* 2009-02-13
* 2009-02-06 missing
* 2009-02-05
* 2009-01-30
* 2009-01-16
* 2009-01-07
The wiki page at
https://fedoraproject.org/wiki/Development/SteeringCommittee/Meetings is
even more incomplete, only http://bpepple.fedorapeople.org/fesco/ is
complete, but has no summaries.
No on the topic itself:
In addition to the questions Toshio already raised in trac
(https://fedorahosted.org/fesco/ticket/110 ) and which
were left unanswered, there are a more questions coming to my mind:
1. What is the rationale behind this policy? I understand there are
political issues with flags but I think they are not addressed properly
with this guideline. For example according to the policy the "Nazi flag"
can be shipped in Fedora, as long is in a separate package . Not sure
about the US, but here in Germany it's not allowed (only under certain
circumstances).
2. As I don't understand the rationale I don't understand the benefit of
the guideline. What is the advantage for Fedora as a project? I only see
needless work for our volunteer maintainers. Also it is very likely that
we need to fork with our patches and this is a contradiction to our
upstream mantra.
3. What is "technically or substantively essential to the package"? E.g.
I'm maintaining xfce4-xkb-plugin, which (by default) uses flags to
indicate the keyboard layout. Is this essential and who decides?
4. Who defines the terms used in the policy, for e. g. what is an
"ethnocultural concept" or what a "religion"?
5. Speaking of religions: Are other religions symbols or pieces of
software like sword (bible study tool, used to be in Fedora) or glosung
(daily watchwords) allowed? What is the difference between a christian
cross and and a cross on a flag?
6. How do we make sure users are aware of the flags packages?
7. What to do with a package that wont work without flags?
Regards,
Christoph
11:41 a.m.
Hello All!
2009/5/18 Kevin Fenzi <kevin(a)scrye.com>:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Please see:
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
and direct any comments to FESCo in a ticket or via the devel list.
Useless policy. Maybe all other issues are already resolved and that's
why FESCo members have too much free time to create such jokes?
--
With best regards!
11:56 a.m.
On 05/18/2009 10:11 PM, Peter Lemenkov wrote:
Hello All!
2009/5/18 Kevin Fenzi <kevin(a)scrye.com>:
> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in
> Fedora was approved.
>
> Due to an oversight, this policy was not announced here. ;(
>
> Please see:
>
> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
>
> and direct any comments to FESCo in a ticket or via the devel list.
Useless policy. Maybe all other issues are already resolved and that's
why FESCo members have too much free time to create such jokes?
Hold on folks. There is no need to be rude. Let someone explain what is
happening first.
Rahul
11:52 a.m.
On Mon, 2009-05-18 at 22:26 +0530, Rahul Sundaram wrote:
On 05/18/2009 10:11 PM, Peter Lemenkov wrote:
> Hello All!
>
> 2009/5/18 Kevin Fenzi <kevin(a)scrye.com>:
>> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in
>> Fedora was approved.
>>
>> Due to an oversight, this policy was not announced here. ;(
>>
>> Please see:
>>
>> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
>>
>> and direct any comments to FESCo in a ticket or via the devel list.
>
> Useless policy. Maybe all other issues are already resolved and that's
> why FESCo members have too much free time to create such jokes?
Hold on folks. There is no need to be rude. Let someone explain what is
happening first.
Agreed, even if I'm not (yet) convince how useful is this policy being
insulting is the last thing to be...
Best regards,
Pierre
12:07 p.m.
Rahul Sundaram <sundaram(a)fedoraproject.org> writes:
On 05/18/2009 10:11 PM, Peter Lemenkov wrote:
> Useless policy. Maybe all other issues are already resolved and that's
> why FESCo members have too much free time to create such jokes?
Hold on folks. There is no need to be rude. Let someone explain what
is
happening first.
It would be a good idea if the policy page itself contained some
justification. Otherwise, anyone looking at it is going to think
pretty much the same things expressed in this thread.
For most of us this is a no-op, but for anyone actually affected,
complying with this policy is going to be a serious PITA. You'd better
provide a convincing justification, or you will not get (voluntary)
compliance.
regards, tom lane
12:11 p.m.
On Mon, 18 May 2009, Kevin Fenzi wrote:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
https://fedorahosted.org/fesco/ticket/154
According to Jon Stanly this should come up on the meeting on friday,
1700 UTC.
Instead of further discussing this on the mailinglist, I'd suggest showing
up at the meeting and getting your point across there.
regards,
andreas
12:28 p.m.
Andreas Thienemann schrieb:
https://fedorahosted.org/fesco/ticket/154
According to Jon Stanly this should come up on the meeting on friday,
1700 UTC.
+1
Best Regards:
Jochen Schmitt
12:18 p.m.
On 05/18/2009 05:09 PM, Kevin Fenzi wrote:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Please see:
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
Surely, this needs to go through FPC first.
12:36 p.m.
Denis Leroy (denis(a)poolshark.org) said:
> Due to an oversight, this policy was not announced here. ;(
>
> Please see:
>
> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
Surely, this needs to go through FPC first.
Given that it's (essentially) a legal issue (affecting distribution/
availability of Fedora), I don't see that. In much the same way that
patents aren't a FPC consideration.
Bill
12:39 p.m.
On 05/18/2009 07:36 PM, Bill Nottingham wrote:
Given that it's (essentially) a legal issue (affecting
distribution/
availability of Fedora), I don't see that. In much the same way that
patents aren't a FPC consideration.
Whether such a policy is necessary or not may be a legal issue, but the
technical implementation of it is very much an FPC consideration.
12:40 p.m.
On 05/18/2009 01:39 PM, Denis Leroy wrote:
On 05/18/2009 07:36 PM, Bill Nottingham wrote:
> Given that it's (essentially) a legal issue (affecting distribution/
> availability of Fedora), I don't see that. In much the same way that
> patents aren't a FPC consideration.
Whether such a policy is necessary or not may be a legal issue, but the
technical implementation of it is very much an FPC consideration.
Well, in this case, Red Hat Legal specifically recommended the technical
implementation. I admit it is a weird gray area, which is why I sent it
to FESCo.
~spot
12:44 p.m.
On Mon, 2009-05-18 at 19:39 +0200, Denis Leroy wrote:
Whether such a policy is necessary or not may be a legal issue, but
the
technical implementation of it is very much an FPC consideration.
Sure, if you really want to get into a jurisdiction pissing match, FESCo
can determine that flags shouldn't be installed as part of the base
package, and leave it up to the packaging committee to figure out how
else they could be installed.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:18 p.m.
Bill Nottingham wrote:
Denis Leroy (denis(a)poolshark.org) said:
>> Due to an oversight, this policy was not announced here. ;(
>>
>> Please see:
>>
>> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
> Surely, this needs to go through FPC first.
Given that it's (essentially) a legal issue (affecting distribution/
availability of Fedora),
I don't see that this is a legal issue, but a
political one.
It would only be a legal issue to Fedora, if using "flags" was a subject
to US laws.
I don't see that. In much the same way that
patents aren't a FPC consideration.
ACK. Not FPC's business.
Ralf
4:26 a.m.
On 05/18/2009 07:36 PM, Bill Nottingham wrote:
Denis Leroy (denis(a)poolshark.org) said:
>> Due to an oversight, this policy was not announced here. ;(
>>
>> Please see:
>>
>> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
> Surely, this needs to go through FPC first.
Given that it's (essentially) a legal issue (affecting distribution/
availability of Fedora), I don't see that.
It is not really a legal issue, as Tom mentioned. You cannot get sued
for putting "Free Tibet" on your web page. But back to the topic,
putting all flags blindly into the same "controversial" category is
simply silly, and an overreaction. As was mentioned in another post,
let's stick with UN-recognized countries, and let packagers deal with
other cases based on specific user complaints or feedback.
I am not saying we should not deal with packages containing
intentionally provocative political contents (I don't know, some sort of
easter egg feature displaying political propaganda, has that ever
happened ?), but the torrent package is a far cry from that scenario. At
worst, isolate the deemed-offensive flags in a separate RPM (so that
people who want to create a PRC-friendly Fedora spin can do so easily),
but please don't put ALL flags in the same category.
The drafted policy is overreaching.
5:39 a.m.
On Tue, 2009-05-19 at 11:26 +0200, Denis Leroy wrote:
On 05/18/2009 07:36 PM, Bill Nottingham wrote:
> Denis Leroy (denis(a)poolshark.org) said:
>>> Due to an oversight, this policy was not announced here. ;(
>>>
>>> Please see:
>>>
>>> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
>> Surely, this needs to go through FPC first.
>
> Given that it's (essentially) a legal issue (affecting distribution/
> availability of Fedora), I don't see that.
It is not really a legal issue, as Tom mentioned. You cannot get sued
for putting "Free Tibet" on your web page.
You want to go live in China and try that, then?
You're probably right -- you wouldn't get _sued_ ...
There _are_ real problems with distributing certain flags, in certain
jurisdictions -- and that means problems distributing _Fedora_ if it
contains those flags. And we _really_ don't want to start removing
_only_ the affected flags, which makes it look like we're taking sides
in the issue.
I don't much like the reasons that we have to do it -- but I do agree
that it's best just to stay out of the political debate by not shipping
_any_ flags. That's why I voted for the policy.
I see a very strong parallel between this issue and the issue of
"profanity". The first book of the Bible makes it clear that to be
ashamed of nakedness and natural bodily function is a sign of sin -- so
I believe that anyone who is offended by the word "fuck" is going to
burn in hell, and anyone striving to be sinless should ensure that they
are _not_ irrationally affected by such simple and natural things.
But since some people _are_ offended, it's best for us to avoid the
issue; to bowdlerise our fortune files and screensavers etc.
Some trivial things offend some strange people, beyond all reason and
proportion. It's just best for us to avoid shipping those things, unless
the lack of them is a _real_ technical problem. Which it _isn't_, in the
case of flags.
--
dwmw2
6:10 a.m.
On Tue, May 19, 2009 at 11:39:39AM +0100, David Woodhouse wrote:
Some trivial things offend some strange people, beyond all reason and
proportion. It's just best for us to avoid shipping those things, unless
the lack of them is a _real_ technical problem. Which it _isn't_, in the
case of flags.
It is for some packages. I can't see any sane way to package FreeCiv,
for example, without using flags. At that point, do we just accept the
package (Tibettan nation and flag and all) or drop perfectly good Free
software from the distribution?
Ewan
6:32 a.m.
> Some trivial things offend some strange people, beyond all reason
and
> proportion. It's just best for us to avoid shipping those things, unless
> the lack of them is a _real_ technical problem. Which it _isn't_, in the
> case of flags.
>
It is for some packages. I can't see any sane way to package FreeCiv,
for example, without using flags. At that point, do we just accept the
package (Tibettan nation and flag and all) or drop perfectly good Free
software from the distribution?
As per the original posting you'd raise the issue with FESCO for their review.
Peter
8:56 a.m.
On Tue, May 19, 2009 at 12:32:25PM +0100, Peter Robinson wrote:
>> Some trivial things offend some strange people, beyond all
reason and
>> proportion. It's just best for us to avoid shipping those things, unless
>> the lack of them is a _real_ technical problem. Which it _isn't_, in the
>> case of flags.
>>
>
> It is for some packages. I can't see any sane way to package FreeCiv,
> for example, without using flags. At that point, do we just accept the
> package (Tibettan nation and flag and all) or drop perfectly good Free
> software from the distribution?
As per the original posting you'd raise the issue with FESCO for their review.
Which is a fine procedural answer, but doesn't really help unless we
have some idea of what their decision would be. I can only see a few
feasable outcomes:
- The package stays in, flags, and textual mentions of Tibettan
nationhood intact. In which case Fedora is still not 'China safe'.
- The controversial flags are removed, others stay in, and FESCO have to
make the call as to who's flags count as controversial.
- The flags are split out as per the policy, and the default install of
FreeCiv is crippled for anyone that doesn't realise the -flags package
exists.
- The whole package is dropped from Fedora.
There does seem to be an assumption in the acceptance of this policy
that flags are easily removed, and that's not always the case. It's easy
to say 'refer the hard cases to FESCO', but if the end result is that
the difficult cases just have their flags left in, then there seems
little point in going to the trouble of removing them from the easier
cases. Alternatively, if the end result is that hard cases just get
dropped from Fedora, then I think that's reasonable cause to object to
the policy.
Ewan
5:51 p.m.
Ewan Mac Mahon wrote:
It is for some packages. I can't see any sane way to package
FreeCiv,
for example, without using flags. At that point, do we just accept the
package (Tibettan nation and flag and all) or drop perfectly good Free
software from the distribution?
A non-game example would be an application to teach geography. That clearly
has concrete educational value. But even if you remove the Taiwanese flag,
you still end up with Taiwan shown as a country. Now if you patch the app
to consider it part of China, how's that not a political stand (and very
likely to offend people in Taiwan, too)? Are we now banned from teaching
our children geography?
Kevin Kofler
6:04 p.m.
On Wed, 2009-05-20 at 00:51 +0200, Kevin Kofler wrote:
A non-game example would be an application to teach geography. That clearly
has concrete educational value. But even if you remove the Taiwanese flag,
you still end up with Taiwan shown as a country. Now if you patch the app
to consider it part of China, how's that not a political stand (and very
likely to offend people in Taiwan, too)? Are we now banned from teaching
our children geography?
Depends on what version of geography you want to teach them, and where
you live.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
7:26 a.m.
On Tue, May 19, 2009 at 12:39 PM, David Woodhouse <dwmw2(a)infradead.org> wrote:
There _are_ real problems with distributing certain flags, in
certain
jurisdictions -- and that means problems distributing _Fedora_ if it
contains those flags. And we _really_ don't want to start removing
_only_ the affected flags, which makes it look like we're taking sides
in the issue.
I don't much like the reasons that we have to do it -- but I do agree
that it's best just to stay out of the political debate by not shipping
_any_ flags. That's why I voted for the policy.
I wonder what will happen in the long run if we continue to remove
everything that anyone on the planet can consider "inappropriate".
If we follow your argument we will do it to be an appealing
distribution for everybody. But this is a contradiction because we
will have less applications and less features than other distributions
thus we will be very less appealing.
Just my 2c.
Bye,
Andrea.
7:52 a.m.
On Tue, 2009-05-19 at 14:26 +0200, Andrea Musuruane wrote:
> I don't much like the reasons that we have to do it -- but I
do agree
> that it's best just to stay out of the political debate by not shipping
> _any_ flags. That's why I voted for the policy.
I wonder what will happen in the long run if we continue to remove
everything that anyone on the planet can consider "inappropriate".]
I agree -- I'm dismayed by the tide of political correctness which
blights our society. But even _I_ am not quixotic enough to want to
stand up to it _all_ the time. Especially when I'm making decision as a
representative of the Fedora project, rather than purely for myself.
I think it's mildly hypocritical of anyone to demand that we restore
flags without also restoring the missing bits of fortune files and the
'random image' screensavers. The principle is the same -- some stupid
people choose to be offended, and we're pandering to them because we
want an easy life.
--
dwmw2
8:16 a.m.
On 05/19/2009 02:52 PM, David Woodhouse wrote:
I think it's mildly hypocritical of anyone to demand that we
restore
flags without also restoring the missing bits of fortune files and the
'random image' screensavers. The principle is the same -- some stupid
people choose to be offended, and we're pandering to them because we
want an easy life.
I use the educational suite GCompris with my 2-year old daughter, which
I really enjoy doing. The configuration menu uses flag countries to let
you select the language of the various games. A French flag for French,
a Portugal flag for portuguese, even a Catalan flag for people from
Barcelona. Now the burden is on the packager to figure out how to patch
the application to work without the images (tough sell to get upstream
help on this).
If you agree to the absurdity of the broad effects caused by the policy
you voted for, you need to resign from FeSCo immediately.
-denis
8:25 a.m.
On Tue, 19 May 2009, Denis Leroy wrote:
On 05/19/2009 02:52 PM, David Woodhouse wrote:
> I think it's mildly hypocritical of anyone to demand that we restore
> flags without also restoring the missing bits of fortune files and the
> 'random image' screensavers. The principle is the same -- some stupid
> people choose to be offended, and we're pandering to them because we
> want an easy life.
I use the educational suite GCompris with my 2-year old daughter, which I
really enjoy doing. The configuration menu uses flag countries to let you
select the language of the various games. A French flag for French, a
Portugal flag for portuguese, even a Catalan flag for people from Barcelona.
Now the burden is on the packager to figure out how to patch the application
to work without the images (tough sell to get upstream help on this).
If you agree to the absurdity of the broad effects caused by the policy you
voted for, you need to resign from FeSCo immediately.
I don't think that particular leap is logical.
What do the flags specify for a country like the US? Or China? or
Switzerland?
If a program means to say "choose your language" then they should say
"choose your language". Not "choose a flag from a linguistically
homogenous country".
-sv
8:33 a.m.
On Tue, May 19, 2009 at 3:25 PM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
If a program means to say "choose your language" then they
should say
"choose your language". Not "choose a flag from a linguistically
homogenous
country".
I don't agree. Usually if you have to choose a language is mainly
because you cannot understand what is written on the screen. Therefore
an ideographic form to represent a language is needed. Flags is an
obvious choice. If we cannot use them, what else?
Bye,
Andrea.
8:48 a.m.
Andrea Musuruane wrote:
On Tue, May 19, 2009 at 3:25 PM, Seth Vidal
<skvidal(a)fedoraproject.org> wrote:
> If a program means to say "choose your language" then they should say
> "choose your language". Not "choose a flag from a linguistically
homogenous
> country".
I don't agree. Usually if you have to choose a language is mainly
because you cannot understand what is written on the screen. Therefore
an ideographic form to represent a language is needed. Flags is an
obvious choice. If we cannot use them, what else?
Firefox language packs have no flags ;o)
8:59 a.m.
Andrea Musuruane wrote:
On Tue, May 19, 2009 at 3:25 PM, Seth Vidal
<skvidal(a)fedoraproject.org>
wrote:
> If a program means to say "choose your language" then
they should say
> "choose your language". Not "choose a flag from a linguistically
> homogenous country".
I don't agree. Usually if you have to choose a language is mainly
because you cannot understand what is written on the screen. Therefore
an ideographic form to represent a language is needed. Flags is an
obvious choice. If we cannot use them, what else?
Here's a list of languages that have articles on a certain topic in Wikipedia.
Do you have any problem finding your choice?
العربية
Bosanski
Brezhoneg
Български
Català
Česky
Dansk
Deutsch
Eesti
Ελληνικά
English
Español
Esperanto
Euskara
فارسی
Français
Galego
한국어
हिन्दी
Hornjoserbsce
Hrvatski
Bahasa Indonesia
Íslenska
Italiano
עברית
Latviešu
Lëtzebuergesch
Lietuvių
Lumbaart
Magyar
Bahasa Melayu
Nederlands
日本語
Norsk (bokmål)
Norsk (nynorsk)
Piemontèis
Polski
Português
Română
Русский
Shqip
Sicilianu
Simple English
Slovenčina
Slovenščina
Српски / Srpski
Basa Sunda
Suomi
Svenska
Tagalog
ไทย
Türkçe
Українська
اردو
Tiếng Việt
ייִדיש
粵語
中文
Björn Persson
9:51 a.m.
2009/5/19 Björn Persson <bjorn(a)xn--rombobjrn-67a.se>:
Here's a list of languages that have articles on a certain topic
in Wikipedia.
Do you have any problem finding your choice?
No, I don't but it is time consuming. After all, icons are made to
access information faster. If I have to overemphasize your argument, I
would ask you why should we use a graphical environment at all, after
all we can all read inside a terminal.
I think this is a really practical matter. There may not be the space
for a text. Flags are icons if the guidelines tell us to remove them,
we have to substitute them with some other icon set. What is this
other icon set?
Bye,
Andrea.
5:04 p.m.
Seth Vidal wrote:
If a program means to say "choose your language" then they
should say
"choose your language". Not "choose a flag from a linguistically
homogenous country".
and Matthew Garrett wrote:
There isn't a 1:1 mapping between flags and languages, and
arguably an
educational suite should be avoiding encouraging that confusion in
children.
And how do you expect a child below reading age to read what you're writing
on the screen? Because that's the target userbase of GCompris.
Kevin Kofler
5:29 p.m.
On Wed, 20 May 2009, Kevin Kofler wrote:
Seth Vidal wrote:
> If a program means to say "choose your language" then they should say
> "choose your language". Not "choose a flag from a linguistically
> homogenous country".
and Matthew Garrett wrote:
> There isn't a 1:1 mapping between flags and languages, and arguably an
> educational suite should be avoiding encouraging that confusion in
> children.
And how do you expect a child below reading age to read what you're writing
on the screen? Because that's the target userbase of GCompris.
But you expect the child to recognize the flag of their country? sigh,
cmon..
A child who can't read needs to be taught by an adult, who, in theory,
can.
-sv
9:04 a.m.
Kevin Kofler (kevin.kofler(a)chello.at) said:
> There isn't a 1:1 mapping between flags and languages, and
arguably an
> educational suite should be avoiding encouraging that confusion in
> children.
And how do you expect a child below reading age to read what you're writing
on the screen? Because that's the target userbase of GCompris.
To give a counter example - are the millions of children in the United States
that speak Spanish at home really going to know to look for a flag of
*Spain* if they're already too young to know the word Spanish (or Español,
which the UI doesn't even offer)? For the overwhelming majority of them,
they're not going to identify with Spain as a nation.
It's just not a good UI to use flags for this.
Bill
8:28 a.m.
On Tue, May 19, 2009 at 03:16:32PM +0200, Denis Leroy wrote:
I use the educational suite GCompris with my 2-year old daughter,
which
I really enjoy doing. The configuration menu uses flag countries to let
you select the language of the various games. A French flag for French,
a Portugal flag for portuguese, even a Catalan flag for people from
Barcelona. Now the burden is on the packager to figure out how to patch
the application to work without the images (tough sell to get upstream
help on this).
There isn't a 1:1 mapping between flags and languages, and arguably an
educational suite should be avoiding encouraging that confusion in
children.
If you agree to the absurdity of the broad effects caused by the
policy
you voted for, you need to resign from FeSCo immediately.
Please keep the conversation civil.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10:41 a.m.
On Tue, 2009-05-19 at 14:28 +0100, Matthew Garrett wrote:
On Tue, May 19, 2009 at 03:16:32PM +0200, Denis Leroy wrote:
> If you agree to the absurdity of the broad effects caused by the policy
> you voted for, you need to resign from FeSCo immediately.
The policy said 'come to FESCo if you want an exception', but sets the
standard that we should avoid shipping flags where it's not necessary.
I think that's a perfectly acceptable and pragmatic solution.
Please keep the conversation civil.
That was civil enough. He disagrees strongly with the decision which
FESCo took, and presumably wants _all_ of us who voted for this policy
to resign, rather than just myself. He stated that desire quite
politely, and I think he's perfectly entitled to do so.
As it happens, my seat and the seats of a few others who voted for this
policy are coming up for re-election soon anyway. So Denis gets his
wish :)
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
1:52 p.m.
On 05/19/2009 05:41 PM, David Woodhouse wrote:
> Please keep the conversation civil.
That was civil enough. He disagrees strongly with the decision which
FESCo took, and presumably wants _all_ of us who voted for this policy
to resign, rather than just myself. He stated that desire quite
politely, and I think he's perfectly entitled to do so.
As it happens, my seat and the seats of a few others who voted for this
policy are coming up for re-election soon anyway. So Denis gets his
wish :)
Indeed :-) I'm left with the choice of either leaving Fedora or running
for Fesco :-) Well we shall see, but it'll wait after F-11 release.
5 p.m.
David Woodhouse wrote:
I think it's mildly hypocritical of anyone to demand that we
restore
flags without also restoring the missing bits of fortune files and the
'random image' screensavers. The principle is the same -- some stupid
people choose to be offended, and we're pandering to them because we
want an easy life.
Indeed, that stuff should also be readded.
Kevin Kofler
5:01 p.m.
Andrea Musuruane wrote:
I wonder what will happen in the long run if we continue to remove
everything that anyone on the planet can consider "inappropriate".
We'll end up with not shipping anything at all. I'm sure even the kernel can
offend someone somewhere. (Maybe: "Hey, 'kernel' is the same word
as 'testicle' in my language, it's sexual!") Censorship is stupid.
Kevin Kofler
5:21 p.m.
-------- Original Message --------
Subject: Re: Package Maintainers Flags policy
From: Kevin Kofler <kevin.kofler(a)chello.at>
To: fedora-devel-list(a)redhat.com
Date: 05/19/2009 05:01 PM
Censorship is stupid.
Until I saw your comments in this thread, I thought I was the only one
who thought this.
Fedora ~= Freedom
Last I recall...
Heck, it was even a Fedora 10 feature! Already forgotten...
http://fedoraproject.org/wiki/Features/FedoraFreedom
Sure, pull the "oh but that's software not political" card, but it is
the same argument. Politics are best left for the pigs, and pigs make
good bacon. MMMmmm bacon.
6:32 p.m.
Kevin Kofler <kevin.kofler(a)chello.at> writes:
We'll end up with not shipping anything at all. I'm sure even
the kernel can
offend someone somewhere. (Maybe: "Hey, 'kernel' is the same word
as 'testicle' in my language, it's sexual!") Censorship is stupid.
I don't know about "kernel" but "root" - certainly. In English
BTW.
--
Krzysztof Halasa
7:38 a.m.
On 05/19/2009 12:39 PM, David Woodhouse wrote:
I don't much like the reasons that we have to do it -- but I do
agree
that it's best just to stay out of the political debate by not shipping
_any_ flags.
Will you also stay out of the profanity debate and blacklist all
packages contains any textual occurrence of a profane word ? Or ship
them in a separate "-adult" subpackage ? This is completely ridiculous,
and the fact you are a member of FeSCO is plain scary. This can only be
excused by lack of time and/or interest to think about a better solution.
Worst of all, this "policy" is forced on us, without any sort of valid
legal reason for it, or even chance for discussion on the mailing list.
This is just plain terrible, and an embarassement for Fedora as a whole.
Frankly this gives me doubt about even being involved with this...
What is Paul Frields take on this ?
-denis
7:59 a.m.
On Tue, 2009-05-19 at 14:38 +0200, Denis Leroy wrote:
On 05/19/2009 12:39 PM, David Woodhouse wrote:
> I don't much like the reasons that we have to do it -- but I do agree
> that it's best just to stay out of the political debate by not shipping
> _any_ flags.
Will you also stay out of the profanity debate and blacklist all
packages contains any textual occurrence of a profane word ? Or ship
them in a separate "-adult" subpackage ? This is completely ridiculous,
and the fact you are a member of FeSCO is plain scary. This can only be
excused by lack of time and/or interest to think about a better solution.
I believe we do remove profanity where it's visible to the user, such as
in fortune files. We also removed the 'random image' screensaver, didn't
we?
I don't really _approve_ of those changes, just as I don't really
approve of removing flags. But it's not that I disagree with the Fedora
decision -- it's more that I disagree with the screwed-up society which
makes it necessary. I do reluctantly concede that it's the most
appropriate decision for Fedora. As did an overwhelming majority of my
colleagues on FESCo, iirc.
Worst of all, this "policy" is forced on us, without any
sort of valid
legal reason for it, or even chance for discussion on the mailing list.
I'm sorry if that impression was given. I thought we actually postponed
the discussion and vote on it for a week so that it could get more
visibility -- do I misremember that?
And my understanding is that there _is_ a valid legal reason for it.
Distributing Fedora in some countries is _illegal_ if it contains
certain flags, and can lead to extremely uncomfortable repercussions.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
8:27 a.m.
On Tue, May 19, 2009 at 01:59:06PM +0100, David Woodhouse wrote:
On Tue, 2009-05-19 at 14:38 +0200, Denis Leroy wrote:
> On 05/19/2009 12:39 PM, David Woodhouse wrote:
> > I don't much like the reasons that we have to do it -- but I do agree
> > that it's best just to stay out of the political debate by not shipping
> > _any_ flags.
>
> Will you also stay out of the profanity debate and blacklist all
> packages contains any textual occurrence of a profane word ? Or ship
> them in a separate "-adult" subpackage ? This is completely ridiculous,
> and the fact you are a member of FeSCO is plain scary. This can only be
> excused by lack of time and/or interest to think about a better solution.
I believe we do remove profanity where it's visible to the user, such as
in fortune files. We also removed the 'random image' screensaver, didn't
we?
I don't really _approve_ of those changes, just as I don't really
approve of removing flags. But it's not that I disagree with the Fedora
decision -- it's more that I disagree with the screwed-up society which
makes it necessary. I do reluctantly concede that it's the most
appropriate decision for Fedora. As did an overwhelming majority of my
colleagues on FESCo, iirc.
> Worst of all, this "policy" is forced on us, without any sort of valid
> legal reason for it, or even chance for discussion on the mailing list.
I'm sorry if that impression was given. I thought we actually postponed
the discussion and vote on it for a week so that it could get more
visibility -- do I misremember that?
And my understanding is that there _is_ a valid legal reason for it.
Distributing Fedora in some countries is _illegal_ if it contains
certain flags, and can lead to extremely uncomfortable repercussions.
And since I was asked for my opinion, I think David stated it pretty
clearly. But frankly I don't think my opinion is needed or, indeed,
that relevant. I do feel strongly that FESCo, as a community elected
body, needs to be empowered to make these kinds of decisions without
worrying about the FPL second-guessing them constantly.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
9:23 a.m.
Paul W. Frields wrote:
On Tue, May 19, 2009 at 01:59:06PM +0100, David Woodhouse wrote:
> On Tue, 2009-05-19 at 14:38 +0200, Denis Leroy wrote:
>> On 05/19/2009 12:39 PM, David Woodhouse wrote:
> And my understanding is that there _is_ a valid legal reason for
it.
> Distributing Fedora in some countries is _illegal_ if it contains
> certain flags, and can lead to extremely uncomfortable repercussions.
Shipping
Fedora is always at risk to contain componets which may be
considered illegal somewhere due to the nature of "nationalism",
"cultural backgrounds", "national laws" and the dynamic nature of such
kind of problems.
This problem isn't restricted to national symbols (such as flags) but is
subject to many topics (E.g. "uncertified games" in Europe, mp3 in the US).
And since I was asked for my opinion, I think David stated it pretty
clearly. But frankly I don't think my opinion is needed or, indeed,
that relevant.
Didn't you state to be intending to "lead by
example"?
If so, you're probably better of to have an opinion.
I do feel strongly that FESCo, as a community elected
body,
1/2 community elected.
Ralf
9:56 a.m.
On Tue, May 19, 2009 at 04:23:21PM +0200, Ralf Corsepius wrote:
Paul W. Frields wrote:
> On Tue, May 19, 2009 at 01:59:06PM +0100, David Woodhouse wrote:
>> On Tue, 2009-05-19 at 14:38 +0200, Denis Leroy wrote:
>>> On 05/19/2009 12:39 PM, David Woodhouse wrote:
>> And my understanding is that there _is_ a valid legal reason for it.
>> Distributing Fedora in some countries is _illegal_ if it contains
>> certain flags, and can lead to extremely uncomfortable repercussions.
Shipping Fedora is always at risk to contain componets which may be
considered illegal somewhere due to the nature of "nationalism",
"cultural backgrounds", "national laws" and the dynamic nature of
such
kind of problems.
This problem isn't restricted to national symbols (such as flags) but is
subject to many topics (E.g. "uncertified games" in Europe, mp3 in the
US).
> And since I was asked for my opinion, I think David stated it pretty
> clearly. But frankly I don't think my opinion is needed or, indeed,
> that relevant.
Didn't you state to be intending to "lead by example"?
If so, you're probably better of to have an opinion.
I think you've inferred something incorrectly from my comments. I
didn't say that I had no opinion. David already posted an identical
opinion and I had nothing to add.
> I do feel strongly that FESCo, as a community elected
> body,
1/2 community elected.
It's a fully elected body. Half the seats are up for election after
this release of Fedora, the other half after the next one. This is
similar to the succession method for many other elected bodies.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
10:02 p.m.
Toshio Kuratomi said the following on 05/19/2009 08:10 AM Pacific Time:
On 05/19/2009 07:23 AM, Ralf Corsepius wrote:
> Paul W. Frields wrote:
>> I do feel strongly that FESCo, as a community elected
>> body,
> 1/2 community elected.
>
The Board is half elected, half appointed. FESCo is wholly elected.
-Toshio
Where "half elected" is 5 of 9 seats :)
https://fedoraproject.org/wiki/Board
John
5:10 p.m.
David Woodhouse wrote:
And my understanding is that there _is_ a valid legal reason for it.
Distributing Fedora in some countries is _illegal_ if it contains
certain flags, and can lead to extremely uncomfortable repercussions.
And distributing games or some kind of games is illegal in some countries
(e.g. I've read that card and dice games are considered betting in some
Muslim countries, and the status of non-child-safe games or even not
certified child-safe games is dubious in other, even Western, countries),
some countries ban Internet use, so web browsers, e-mail clients and even
updating software might be a problem etc. We're left with nothing to ship
if we remove everything banned in some country.
Kevin Kofler
8:30 a.m.
On Tue, 19 May 2009, Denis Leroy wrote:
Will you also stay out of the profanity debate and blacklist all
packages
contains any textual occurrence of a profane word ? Or ship them in a
separate "-adult" subpackage ? This is completely ridiculous, and the fact
you are a member of FeSCO is plain scary. This can only be excused by lack of
time and/or interest to think about a better solution.
Worst of all, this "policy" is forced on us, without any sort of valid legal
reason for it, or even chance for discussion on the mailing list.
The simple reality is China. The Chinese gov't was not happy about
taiwanese flags being marked on Taiwan - or the Tibetan flag on Tibet.
Now, your next question is "why is that our problem?" And the answer is -
if we are banned from distribution in china then we have lost a bunch of
potential contributors.
And then your next question is "does the Chinese gov't really care about a
linux distro having a Taiwanese or Tibetan flag in some programs it
ships?" and the answer to that question is yes, very much.
So, of course does this mean we are siding with china? No, we're not
siding with anyone, that's the whole point.
Flags mean a lot to a lot of people. They carry a lot of patriotic crap
w/them.
-sv
8:50 a.m.
And then your next question is "does the Chinese gov't
really care about a
linux distro having a Taiwanese or Tibetan flag in some programs it ships?"
and the answer to that question is yes, very much.
So, of course does this mean we are siding with china? No, we're not siding
with anyone, that's the whole point.
Flags mean a lot to a lot of people. They carry a lot of patriotic crap
w/them.
But what is the official internationally recognized status of Taiwan ?
If that's a part of china, then it's not an actual country, then we
can remove its flag.
If that's an independent country, then it has a flag, and we can use it.
I really wonder why we are trying to solve those geopolitical
international issues. Those are for the governments and the UN to
solve. They agree on a list of officially recognized countries, and we
use it.
I really can't understand where the problem comes from :-/
Are there countries not agreeing with each others regarding the
official status of other countries (not like country A says country B
is inside country A, but rather country A and country B disagree on
the status of country C) ? Are there countries that disagree with the
UN regarding the official status of a "geographic area" ?
----------
Mathieu Bridon (bochecha)
8:50 a.m.
On 05/19/2009 09:50 AM, Mathieu Bridon (bochecha) wrote:
Are there countries not agreeing with each others regarding the
official status of other countries (not like country A says country B
is inside country A, but rather country A and country B disagree on
the status of country C) ? Are there countries that disagree with the
UN regarding the official status of a "geographic area" ?
To answer your questions, yes, and yes.
~spot
9:05 a.m.
On Tue, May 19, 2009 at 15:50, Tom "spot" Callaway <tcallawa(a)redhat.com>
wrote:
On 05/19/2009 09:50 AM, Mathieu Bridon (bochecha) wrote:
> Are there countries not agreeing with each others regarding the
> official status of other countries (not like country A says country B
> is inside country A, but rather country A and country B disagree on
> the status of country C) ? Are there countries that disagree with the
> UN regarding the official status of a "geographic area" ?
To answer your questions, yes, and yes.
Then we're totally doomed :)
I mean, how could we hope to solve this kind of issue on our level if
even those of the world can't ?
Anyway, sticking to the official internation standard list of
countries maintained by UN (if such a list exists) seems much more
neutral to me. We don't decide anything on countries, we use the
decision of an official organization empowered to make such a
decision.
By abandoning flags alltogether, we actually make a decision: we
choose to side with those who don't agree with the UN.
----------
Mathieu Bridon (bochecha)
9:11 a.m.
On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote:
On Tue, May 19, 2009 at 15:50, Tom "spot" Callaway
<tcallawa(a)redhat.com> wrote:
> On 05/19/2009 09:50 AM, Mathieu Bridon (bochecha) wrote:
>> Are there countries not agreeing with each others regarding the
>> official status of other countries (not like country A says country B
>> is inside country A, but rather country A and country B disagree on
>> the status of country C) ? Are there countries that disagree with the
>> UN regarding the official status of a "geographic area" ?
>
> To answer your questions, yes, and yes.
Then we're totally doomed :)
Why yes, yes we are.
I mean, how could we hope to solve this kind of issue on our level if
even those of the world can't ?
We muddle through.
Anyway, sticking to the official internation standard list of
countries maintained by UN (if such a list exists) seems much more
neutral to me. We don't decide anything on countries, we use the
decision of an official organization empowered to make such a
decision.
Afaict there is no such list. I'd be happy to be wrong about this, though.
By abandoning flags alltogether, we actually make a decision: we
choose to side with those who don't agree with the UN.
No, we don't.
and afaict, the UN just muddles through, too. It flags lots of different
flags but gives in to various powers when asked to.
Fun, huh?
Here's a short list of some of the flags which will cause problems in the
world:
http://commons.wikimedia.org/wiki/Flags_of_active_autonomist_and_secessio...
-sv
3:56 p.m.
2009/5/19 Seth Vidal <skvidal(a)fedoraproject.org>:
On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote:
>
> Anyway, sticking to the official internation standard list of
> countries maintained by UN (if such a list exists) seems much more
> neutral to me. We don't decide anything on countries, we use the
> decision of an official organization empowered to make such a
> decision.
Afaict there is no such list. I'd be happy to be wrong about this, though.
Does this one suit you:
http://www.un.org/en/members/index.shtml
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
3:56 p.m.
On Tue, 19 May 2009, Martín Marqués wrote:
2009/5/19 Seth Vidal <skvidal(a)fedoraproject.org>:
>
> On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote:
>
>>
>> Anyway, sticking to the official internation standard list of
>> countries maintained by UN (if such a list exists) seems much more
>> neutral to me. We don't decide anything on countries, we use the
>> decision of an official organization empowered to make such a
>> decision.
>
> Afaict there is no such list. I'd be happy to be wrong about this, though.
Does this one suit you:
http://www.un.org/en/members/index.shtml
It might suit me - but it does not suit folks from Tibet or Taiwan.
-sv
9:25 a.m.
On Tue, May 19, 2009 at 10:05 AM, Mathieu Bridon (bochecha)
<bochecha(a)fedoraproject.org> wrote:
Anyway, sticking to the official internation standard list of
countries maintained by UN (if such a list exists) seems much more
neutral to me.
A list of current countries doesn't solve the problem. Let's take for
example Freeciv, which was cited earlier as having flags as a core
part of the experience (I'd disagree, but anyways). Do we allow
historical flags or not? I can think of more than one past historical
leader and flag that are likely to be controversial, and definitely
one which is banned in a perfectly democractic country (this is what
Seth was hinting at earlier).
By abandoning flags alltogether, we actually make a decision: we
choose to side with those who don't agree with the UN.
Every decision has tradeoffs and ramifications. The point is, are
flags/symbols a core part of the value Fedora is delivering in most of
these cases? No.
Note that we aren't taking away anyone's freedom here - anyone is free
to create a localized spin which includes some flags or other changes
as they desire.
9:47 a.m.
On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote:
A list of current countries doesn't solve the problem. Let's take for
example Freeciv, which was cited earlier as having flags as a core
part of the experience (I'd disagree, but anyways).
The problem with FreeCiv is that the only distinction between a city or
unit of one nation and one of another is the flag[1], so there doesn't
seem to be any simple way to remove them. They could be replaced with
different flags graphics, but they'd all have to be distinct; you
couldn't just use (e.g.) the Fedora logo for every nation.
There's also the fact that FreeCiv in particular contains Tibet as a
playable nation; even if the flag were removed, I don't think refering
to the Tibetan nation would pass muster in China. That being the case
we're either going to need to go a lot further than removing just flags,
or accept that generic Fedora won't be 'China safe', in which case we
might as well leave the flags alone.
Ewan
[1] e.g: <http://freeciv.wikia.com/wiki/File:Big_window.png
9:59 a.m.
On Tue, May 19, 2009 at 10:47 AM, Ewan Mac Mahon <ewan(a)macmahon.me.uk> wrote:
The problem with FreeCiv is that the only distinction between a city or
unit of one nation and one of another is the flag[1], so there doesn't
seem to be any simple way to remove them.
Hmm, right I forgot they're on the units too, I was just thinking of
the civilization selection screen.
Well, the fix for Freeciv might have to be that civilizations get
randomly assigned block colors.
There's also the fact that FreeCiv in particular contains Tibet
as a
playable nation; even if the flag were removed, I don't think refering
to the Tibetan nation would pass muster in China. That being the case
we're either going to need to go a lot further than removing just flags,
or accept that generic Fedora won't be 'China safe', in which case we
might as well leave the flags alone.
Here's the problem though, there are some obvious gaps in the Freeciv
civilization list as I mentioned before. Some of which would be
offensive to a large swath of the Western world, some which would be
extremely controversial in smaller areas of the world, etc. What
happens if one of those items gets added to the civilization list
upstream? (Do they have a policy?)
Actually let's be practical here and admit Freeciv is a pretty special
case. The main thing we want to squash is things like flags in input
method selection which is very prominent in the UI, and flags in
bittorrent clients whose removal doesn't at all substantially affect
the operation of the software.
Maybe we need a flag in the RPM .spec to say "this package contains
geopolitical symbols" and mark all of Freeciv as that.
10:09 a.m.
On Tue, 19 May 2009, Colin Walters wrote:
Actually let's be practical here and admit Freeciv is a pretty special
case. The main thing we want to squash is things like flags in input
method selection which is very prominent in the UI, and flags in
bittorrent clients whose removal doesn't at all substantially affect
the operation of the software.
It's also completely possible that freeciv may not be a package we can
ship.
If someone packaged a "free taiwan" game where you protested the PRC and
wheeled and dealed to get various world gov'ts to officially recognize
taiwan (an amusing game premise, actually) I think we'd probably have to
not ship it. Just as if someone packaged a game adaptation of "springtime
for hitler and germany." (from the producers musical/movie for anyone who
doesn't get the reference) we'd probably not ship it.
-sv
10:27 a.m.
On Tue, May 19, 2009 at 11:09 AM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
It's also completely possible that freeciv may not be a package we can ship.
Not have at all in RPM form on the mirrors and in the repo list you
mean? That's a pretty harsh solution. There's degrees here. I could
imagine for example that for some consumers of Fedora, being able to
automatically strip out the controversial packages when
redistributing, and have yum be able to skip listing
-flags/controversial packages would be enough for them. That seems to
be some of the logic behind the current flags policy, though please
correct me if I'm wrong.
If someone packaged a "free taiwan" game where you
protested the PRC and
wheeled and dealed to get various world gov'ts to officially recognize
taiwan (an amusing game premise, actually) I think we'd probably have to not
ship it. Just as if someone packaged a game adaptation of "springtime for
hitler and germany." (from the producers musical/movie for anyone who
doesn't get the reference) we'd probably not ship it.
Well, luckily for us the vast majority of these kinds of things are
Flash games on the web now, so they're not our problem.
10:34 a.m.
On Tue, 19 May 2009, Colin Walters wrote:
On Tue, May 19, 2009 at 11:09 AM, Seth Vidal
<skvidal(a)fedoraproject.org> wrote:
>
> It's also completely possible that freeciv may not be a package we can ship.
Not have at all in RPM form on the mirrors and in the repo list you
mean? That's a pretty harsh solution. There's degrees here. I could
imagine for example that for some consumers of Fedora, being able to
automatically strip out the controversial packages when
redistributing, and have yum be able to skip listing
-flags/controversial packages would be enough for them. That seems to
be some of the logic behind the current flags policy, though please
correct me if I'm wrong.
We'd need:
1. some kind of plugin to handle it
2. some sort of provides tag in the rpm
that's a lot of crap to do in lieu of just not shipping the pkg.
> If someone packaged a "free taiwan" game where you
protested the PRC and
> wheeled and dealed to get various world gov'ts to officially recognize
> taiwan (an amusing game premise, actually) I think we'd probably have to not
> ship it. Just as if someone packaged a game adaptation of "springtime for
> hitler and germany." (from the producers musical/movie for anyone who
> doesn't get the reference) we'd probably not ship it.
Well, luckily for us the vast majority of these kinds of things are
Flash games on the web now, so they're not our problem.
yet.
-sv
11:01 a.m.
On Tue, May 19, 2009 at 11:34 AM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
We'd need:
1. some kind of plugin to handle it
2. some sort of provides tag in the rpm
that's a lot of crap to do in lieu of just not shipping the pkg.
OK, yeah I understand it's not simple to tweak the infrastructure. On
the other hand I do think Freeciv is a good example of a free software
game of the kind we'd like Fedora to have available, and the flags are
not trivial to remove. I guess this one comes down to the
case-by-case for FESCo.
Again though it would be useful though if someone involved in the
policy could explain how the -flags subpackages are planned to be
consumed. I'm just guessing that the goal is for derived
distributions to be able to automatically strip them out, and as I
said in that case it seems like it would be fine for them if they
could also strip out Freeciv given some tag in the package (along with
cases like the educational games with flags), while keeping it
available (i.e. on the mirrors) in Fedora "upstream".
10:55 a.m.
On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote:
On Tue, May 19, 2009 at 10:47 AM, Ewan Mac Mahon
<ewan(a)macmahon.me.uk> wrote:
>
> The problem with FreeCiv is that the only distinction between a city or
> unit of one nation and one of another is the flag[1], so there doesn't
> seem to be any simple way to remove them.
Hmm, right I forgot they're on the units too, I was just thinking of
the civilization selection screen.
Actually let's be practical here and admit Freeciv is a pretty
special
case.
That's true, but if the no flags policy is intended to cover the whole
distribution then it needs to take account of the hard cases as well as
the easy ones.
The main thing we want to squash is things like flags in input
method selection which is very prominent in the UI, and flags in
bittorrent clients whose removal doesn't at all substantially affect
the operation of the software.
That's a reasonable postion, but it's not quite the same as the current
policy.
We really do need to decide whether the response to a package that can't
feasably have it's flags removed is to drop the package, or live with
the flags. If we go for the latter then we're not actually solved the
problem of distributing Fedora in places like China, and I'm not sure
that the former is an attractive trade-off for what seems a fairly
marginal benefit.
Ewan
11:10 a.m.
On Tue, 2009-05-19 at 16:55 +0100, Ewan Mac Mahon wrote:
We really do need to decide whether the response to a package that
can't
feasably have it's flags removed is to drop the package, or live with
the flags. If we go for the latter then we're not actually solved the
problem of distributing Fedora in places like China, and I'm not sure
that the former is an attractive trade-off for what seems a fairly
marginal benefit.
We really do need to decide whether the response to a package that can't
feasibly have its patented algorithms removed is to drop the package, or
live with the patents.
If we go for the latter then we've not actually solved the problem of
distributing Fedora in places like the US.
The former _is_ a simple enough trade-off. We have a "Fedora Free World"
repository already...
Seriously, folks -- we're only doing for flags the _same_ thing we've
done for a bunch of other things that would make it problematic to ship
Fedora in certain places.
Just because it isn't an issue where _you_ live, that doesn't mean we
shouldn't care about it. I wish people would stop being so parochial.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
5:28 p.m.
David Woodhouse wrote:
Seriously, folks -- we're only doing for flags the _same_ thing
we've
done for a bunch of other things that would make it problematic to ship
Fedora in certain places.
The thing is, the US is where Fedora is located, so it has no other choice
than to respect its laws (even where this sucks – crippleware due to
software patents is annoying!), China is not.
If we tried to be legal in all countries, we'd have to remove a lot more
stuff than just flags.
Kevin Kofler
1:18 a.m.
於 二，2009-05-19 於 16:55 +0100，Ewan Mac Mahon 提到：
On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote:
> The main thing we want to squash is things like flags in input
> method selection which is very prominent in the UI, and flags in
> bittorrent clients whose removal doesn't at all substantially affect
> the operation of the software.
>
That's a reasonable postion, but it's not quite the same as the current
policy.
Using flags in input methods along is not very informative.
For example, there are dozens (if not hundreds) of Chinese IMs.
How do you know which one should be associated with China flags?
Should it be pinyin? wubi? cangjie3? cangjie5?
It's a good thing that almost all input methods already have their own
icons.
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
2:07 a.m.
On Wednesday 20 May 2009 11:18:47 Ding-Yi Chen wrote:
於 二，2009-05-19 於 16:55 +0100，Ewan Mac Mahon 提到：
> On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote:
> > The main thing we want to squash is things like flags in input
> > method selection which is very prominent in the UI, and flags in
> > bittorrent clients whose removal doesn't at all substantially affect
> > the operation of the software.
>
> That's a reasonable postion, but it's not quite the same as the current
> policy.
Using flags in input methods along is not very informative.
For example, there are dozens (if not hundreds) of Chinese IMs.
How do you know which one should be associated with China flags?
Should it be pinyin? wubi? cangjie3? cangjie5?
It's a good thing that almost all input methods already have their own
icons.
That's true if someone is trying to find a language from the full list.
But if someone (e.g. me) has already chosen 3 he will be using (e.g. English,
Armenian, Russian) it will be much more comfortable for him to see a flag and
not a greyish box with greyish white letters (us, am, ru) in it.
Suren
2:49 a.m.
於 三，2009-05-20 於 12:07 +0500，Suren Karapetyan 提到：
On Wednesday 20 May 2009 11:18:47 Ding-Yi Chen wrote:
> 於 二，2009-05-19 於 16:55 +0100，Ewan Mac Mahon 提到：
>
> > On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote:
> > > The main thing we want to squash is things like flags in input
> > > method selection which is very prominent in the UI, and flags in
> > > bittorrent clients whose removal doesn't at all substantially affect
> > > the operation of the software.
> >
> > That's a reasonable postion, but it's not quite the same as the
current
> > policy.
>
> Using flags in input methods along is not very informative.
> For example, there are dozens (if not hundreds) of Chinese IMs.
> How do you know which one should be associated with China flags?
> Should it be pinyin? wubi? cangjie3? cangjie5?
>
> It's a good thing that almost all input methods already have their own
> icons.
>
That's true if someone is trying to find a language from the full list.
But if someone (e.g. me) has already chosen 3 he will be using (e.g. English,
Armenian, Russian)
I have 5 Chinese IMs (mainly for development) pinyin, wubi, Cangjie3,
Quick3, and chewing.
How could I distinguish these in "Flag-only" schema?
Quite a lot of Chinese desktops installed multiple input methods for
various reasons. It can be the preferences are differ among family
members, or learning/testing some new input methods.
Some IMs are capable of input multiple languages, what flags should they
use?
it will be much more comfortable for him to see a flag and
not a greyish box with greyish white letters (us, am, ru) in it.
Suren
That's what icons for.
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
3:07 a.m.
On Wednesday 20 May 2009 09:49:40 Ding-Yi Chen wrote:
於 三，2009-05-20 於 12:07 +0500，Suren Karapetyan 提到：
> On Wednesday 20 May 2009 11:18:47 Ding-Yi Chen wrote:
> > 於 二，2009-05-19 於 16:55 +0100，Ewan Mac Mahon 提到：
> >
> > > On Tue, May 19, 2009 at 10:59:07AM -0400, Colin Walters wrote:
> > > > The main thing we want to squash is things like flags in input
> > > > method selection which is very prominent in the UI, and flags in
> > > > bittorrent clients whose removal doesn't at all substantially
> > > > affect the operation of the software.
> > >
> > > That's a reasonable postion, but it's not quite the same as the
> > > current policy.
> >
> > Using flags in input methods along is not very informative.
> > For example, there are dozens (if not hundreds) of Chinese IMs.
> > How do you know which one should be associated with China flags?
> > Should it be pinyin? wubi? cangjie3? cangjie5?
> >
> > It's a good thing that almost all input methods already have their own
> > icons.
>
> That's true if someone is trying to find a language from the full list.
> But if someone (e.g. me) has already chosen 3 he will be using (e.g.
> English, Armenian, Russian)
I have 5 Chinese IMs (mainly for development) pinyin, wubi, Cangjie3,
Quick3, and chewing.
How could I distinguish these in "Flag-only" schema?
We all know flags : language is not 1:1 relation, but it can help in situations
where you use more different languages (mostly english and native language).
If flags make it difficult for someone to chose:
1) there is still text over the flag
2) you can use check box in configuration to turn flags off
11:43 p.m.
於 三，2009-05-20 於 10:07 +0200，Michal Hlavinka 提到：
On Wednesday 20 May 2009 09:49:40 Ding-Yi Chen wrote:
> 於 三，2009-05-20 於 12:07 +0500，Suren Karapetyan 提到：
>
> > On Wednesday 20 May 2009 11:18:47 Ding-Yi Chen wrote:
> > > 於 二，2009-05-19 於 16:55 +0100，Ewan Mac Mahon 提到：
> > >
> > > Using flags in input methods along is not very informative.
> > > For example, there are dozens (if not hundreds) of Chinese IMs.
> > > How do you know which one should be associated with China flags?
> > > Should it be pinyin? wubi? cangjie3? cangjie5?
> > >
> > > It's a good thing that almost all input methods already have their
own
> > > icons.
> >
> > That's true if someone is trying to find a language from the full list.
> > But if someone (e.g. me) has already chosen 3 he will be using (e.g.
> > English, Armenian, Russian)
>
> I have 5 Chinese IMs (mainly for development) pinyin, wubi, Cangjie3,
> Quick3, and chewing.
> How could I distinguish these in "Flag-only" schema?
We all know flags : language is not 1:1 relation, but it can help in situations
where you use more different languages (mostly english and native language).
But it does not help in my case.
Using input method icons, however, solves your case and mine.
Note that you might be able to use flag as icon in your input method,
providing no other people develop other input methods in your country
and challenge you.
And how about multilingual countries such as India and Switzerland?
What language should be associate their flags?
If flags make it difficult for someone to chose:
1) there is still text over the flag
2) you can use check box in configuration to turn flags off
In order to know which input method is activated, in your setting, I
have to either:
1. Hover the mouse to the flag icon and see the tooltip
2. Type a few key and find out I am at wrong input method.
Both ways are not as convenient as using an input method icons.
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
12:23 a.m.
Ding-Yi Chen wrote:
Using input method icons, however, solves your case and mine.
What icons? There may be standard icons for Chinese input methods, but there
are no standard icons for keyboard layouts. The language code is nonsense,
as e.g. English and German have different keyboards depending on the
country.
And how about multilingual countries such as India and Switzerland?
For Switzerland, the different layouts are implemented as variants of the ch
layout, so putting the ch layout up with a Swiss flag and then letting you
pick the variant (which is what KDE does) is the best way to handle it. If
you disagree with them being handled as variants, complain to the xkb
folks, they're setting it up that way.
India is a much more complex case though.
Kevin Kofler
8:52 p.m.
於 四，2009-05-21 於 07:23 +0200，Kevin Kofler 提到：
Ding-Yi Chen wrote:
> Using input method icons, however, solves your case and mine.
What icons? There may be standard icons for Chinese input methods, but there
are no standard icons for keyboard layouts. The language code is nonsense,
as e.g. English and German have different keyboards depending on the
country.
There are no such "standard Chinese IM icons", IM developers can use
whatever icons they like to distinguish their input methods.
key layout icons can do the similar way, icons can be either designed by
the key-layout switch developers or community. This also solve the
problem related to US-qwerty and US-dvorak.
> And how about multilingual countries such as India and Switzerland?
For Switzerland, the different layouts are implemented as variants of the ch
layout, so putting the ch layout up with a Swiss flag and then letting you
pick the variant (which is what KDE does) is the best way to handle it. If
you disagree with them being handled as variants, complain to the xkb
folks, they're setting it up that way.
India is a much more complex case though.
Kevin Kofler
Actually the ibus do the similar way:
You can enable the IMs by their languages, but without showing flags.
But I quite doubt the KDE's country oriented scheme is better.
For example, English and Australian might be somewhat disappointed that
their flags are not in the list, while language oriented scheme does not
have such problems.
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
9:58 p.m.
Ding-Yi Chen wrote:
There are no such "standard Chinese IM icons", IM
developers can use
whatever icons they like to distinguish their input methods.
And where do they come from and how do they make the user understand what
they're about to select?
key layout icons can do the similar way, icons can be either designed
by
the key-layout switch developers or community.
But the icons need to be recognizable by the user! If I draw a beautiful
flower to represent, say, the German keyboard layout, how do people know
the flower corresponds to a German keyboard layout? Well, I could use an
Edelweiss which is common in Austria (which uses the same layout) and
Bavaria (part of Germany), but it's also common in Alpine regions of Italy,
in Switzerland and in a few other countries which all do not use the same
keyboard layout. That kind of regional symbols doesn't work any better than
flags. A picture of the keyboard with keys printed on it isn't going to
work either, at the size of a systray icon the letters are all condensed at
best to single pixels, you can't recognize anything at all.
2-letter layout names are the best we can have without flags, but 1. it's
text, not an icon and 2. the layout names aren't really any more neutral
than the flags (they are mostly country names, sometimes language names).
For example, English and Australian might be somewhat disappointed
that
their flags are not in the list, while language oriented scheme does not
have such problems.
* The United Kingdom is actually in the list.
* Language-oriented does not work. German and English are both spoken in
different countries with different keyboard layouts! While Austria and
Germany use the same layout, Switzerland uses a different one. And the UK
layout is also significantly different from the US one. Ireland also has
its own layout (and no, Irish is not the native language of most people
there, English is). The list of keyboard layouts is neither per country nor
per language.
Kevin Kofler
11:13 p.m.
於 五，2009-05-22 於 04:58 +0200，Kevin Kofler 提到：
Ding-Yi Chen wrote:
> There are no such "standard Chinese IM icons", IM developers can use
> whatever icons they like to distinguish their input methods.
And where do they come from and how do they make the user understand what
they're about to select?
No problem. Normally we just pick the first or significant character of
the input method name. Like "拼" "五", "酷", "倉", or
input method
specific icon like "ㄅ".
Smaller characters on the bottom right to show the variance.
If your script is horizontal like English, you can either stretch the
text or leave the button space to show the variance.
> key layout icons can do the similar way, icons can be either
designed by
> the key-layout switch developers or community.
But the icons need to be recognizable by the user! If I draw a beautiful
flower to represent, say, the German keyboard layout, how do people know
the flower corresponds to a German keyboard layout? Well, I could use an
Edelweiss which is common in Austria (which uses the same layout) and
Bavaria (part of Germany), but it's also common in Alpine regions of Italy,
in Switzerland and in a few other countries which all do not use the same
keyboard layout. That kind of regional symbols doesn't work any better than
flags. A picture of the keyboard with keys printed on it isn't going to
work either, at the size of a systray icon the letters are all condensed at
best to single pixels, you can't recognize anything at all.
I agree with your first sentence. But no worry, icons that cannot be
recognized by its users will not get into the package if the developers
and community are sensible.
2-letter layout names are the best we can have without flags, but 1.
it's
text, not an icon and 2. the layout names aren't really any more neutral
than the flags (they are mostly country names, sometimes language names).
Flags do have issues. Haven't you seen the whole thread?
But 2-letter layout name don't. Have you seen any article mention about
it?
BTW, where does the 2-letter layout came from?
> For example, English and Australian might be somewhat
disappointed that
> their flags are not in the list, while language oriented scheme does not
> have such problems.
* The United Kingdom is actually in the list.
But Australia and New zealand are not.
The list of keyboard layouts is neither per country nor
per language.
Kevin Kofler
If the list of keyboard layouts is neither per country nor per language,
how come there is a "Show country flags" option?
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
12:26 p.m.
Suren Karapetyan wrote:
That's true if someone is trying to find a language from the full
list.
But if someone (e.g. me) has already chosen 3 he will be using (e.g.
English, Armenian, Russian) it will be much more comfortable for him to
see a flag and not a greyish box with greyish white letters (us, am, ru)
in it.
Those are keyboard layouts, not input methods, and there are indeed no
standard icons for those, which is why those flags are used. Of course,
flags are a bad match for them, as are language names (!). For example, the
Swiss German-language keyboard is vastly different from the German and
Austrian German-language keyboard. And Swiss keyboards for French and
Italian are different from those for German. Whereas Germany and Austria
use both the same language and the same keyboard, so a German flag is kinda
annoying for users in Austria (the language name is slightly more correct,
but see Switzerland…). It really looks like there's no good solution for
this mess.
Kevin Kofler
2:11 a.m.
On Wed, 2009-05-20 at 16:18 +1000, Ding-Yi Chen wrote:
Using flags in input methods along is not very informative.
For example, there are dozens (if not hundreds) of Chinese IMs.
How do you know which one should be associated with China flags?
Should it be pinyin? wubi? cangjie3? cangjie5?
It's a good thing that almost all input methods already have their own
icons.
That's essentially irrelevant to this debate. All sorts of things are
bad design decisions (or bad coding decisions) but we don't implement a
blanket ban on them in Fedora and patch them all out...it's true that
flags are a bad idea for various things, but the appropriate place to
discuss that is in improvement reports to the upstream developers.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:14 a.m.
On 05/19/2009 07:47 AM, Ewan Mac Mahon wrote:
On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote:
> A list of current countries doesn't solve the problem. Let's take for
> example Freeciv, which was cited earlier as having flags as a core
> part of the experience (I'd disagree, but anyways).
>
The problem with FreeCiv is that the only distinction between a city or
unit of one nation and one of another is the flag[1], so there doesn't
seem to be any simple way to remove them. They could be replaced with
different flags graphics, but they'd all have to be distinct; you
couldn't just use (e.g.) the Fedora logo for every nation.
There's also the fact that FreeCiv in particular contains Tibet as a
playable nation; even if the flag were removed, I don't think refering
to the Tibetan nation would pass muster in China. That being the case
we're either going to need to go a lot further than removing just flags,
or accept that generic Fedora won't be 'China safe', in which case we
might as well leave the flags alone.
So here's a possibility of how a compromise could be structured. This
is assuming that FESCo doesn't just decide that flags can be kept
because spot's explanation in this thread clarified the legal situation:
Currently, the FESCo Policy mandates that:
1) If use of flags "is not technically or substantively essential" to a
package, they must be in subpackages or not included.
2) Programs which require the flags must have a fallback mechanism
because they are prohibited from Requiring the flags subpackage.
3) Exceptions are granted for programs which feel they need to violate this.
New Proposal:
[current definition of flags remains]
* Packages that include flags must show that they do this by having a
virtual Provides: Politics(flags).
* If a package is on the main spin (or required by something on the main
spin in the case of updates that pull in different packages), it cannot
Provides: Politics(flags).
* If a program is needed for the main spin but Provides:
Politics(flags), someone must do the work to move the flags into a
subpackage that Provides the flags and patch the program to make
existence of the flags optional. As noted above, that subpackage cannot
be Required from the package that is on the main spin.
Several notes:
* I divided this up a bit from the current policy. So there's a
political decision, no flags on the main spin, and an implementation
decision: Use a virtual Provides to mark the packages. I don't know if
FESCo wants to decide the whole thing or if they want to hand off the
second half to FPC for a solution by a certain deadline.
* Packages not on the main spin have minimal burden under this proposal
* Packages on the main spin (or packages that understand the issues and
decide they want to be distributable in countries where some flags are
banned) will still need to do the work, possibly carry patches, etc.
* This ties the policy to the existence of a "main spin". I don't
believe there's serious plans to get rid of that but if we do, this
policy will need to be revised.
* There's no exception process like the current Policy. The anticipated
answer to a problematic package is: "Don't put that program on the main
spin".
* Distributing Fedora in countries that ban certain flags is somewhat
harder:
- Before, a mirror could exclude subpackages that ended in -flags.
Now the mirror would need to exclude packages that Provides:
Politics(flags) and, to be nice to their consumers, the packages that
depend on them. The mirror might have gotten away with not regenerating
the repodata with the current policy because installing an optional
-flags package wouldn't be that common but they would definitely need to
regenerate the repodata if the exclusion of Politics(flags): packages
was leading to programs users might want not ending in the repository.
- Note that you *can* still distribute the main Fedora spin without
difficulty.
-Toshio
11:28 a.m.
On Tue, 19 May 2009, Toshio Kuratomi wrote:
* If a program is needed for the main spin but Provides:
Politics(flags),
someone must do the work to move the flags into a subpackage that Provides
the flags and patch the program to make existence of the flags optional. As
noted above, that subpackage cannot be Required from the package that is on
the main spin.
If we end up needing yum plugin of some kind to handle this can I call it
the free-randomstan plugin?
-sv
11:32 a.m.
Seth Vidal (skvidal(a)fedoraproject.org) said:
> * If a program is needed for the main spin but Provides:
> Politics(flags), someone must do the work to move the flags into a
> subpackage that Provides the flags and patch the program to make
> existence of the flags optional. As noted above, that subpackage
> cannot be Required from the package that is on the main spin.
If we end up needing yum plugin of some kind to handle this can I call
it the free-randomstan plugin?
We don't have a yum-patents plugin, or Provides(patents). Why are we
going to such lengths here?
Bill
11:50 a.m.
On 05/19/2009 09:32 AM, Bill Nottingham wrote:
Seth Vidal (skvidal(a)fedoraproject.org) said:
>> * If a program is needed for the main spin but Provides:
>> Politics(flags), someone must do the work to move the flags into a
>> subpackage that Provides the flags and patch the program to make
>> existence of the flags optional. As noted above, that subpackage
>> cannot be Required from the package that is on the main spin.
> If we end up needing yum plugin of some kind to handle this can I call
> it the free-randomstan plugin?
We don't have a yum-patents plugin, or Provides(patents). Why are we
going to such lengths here?
Wouldn't a policy on Provides: Policy(patents) have to originate with
rpmfusion?
-Toshio
12:01 p.m.
On Tue, 19 May 2009, Bill Nottingham wrote:
Seth Vidal (skvidal(a)fedoraproject.org) said:
>> * If a program is needed for the main spin but Provides:
>> Politics(flags), someone must do the work to move the flags into a
>> subpackage that Provides the flags and patch the program to make
>> existence of the flags optional. As noted above, that subpackage
>> cannot be Required from the package that is on the main spin.
>
> If we end up needing yum plugin of some kind to handle this can I call
> it the free-randomstan plugin?
We don't have a yum-patents plugin, or Provides(patents). Why are we
going to such lengths here?
How would we have a Provides(patents) on pkgs in fedora? If the pkgs had
patent issues we couldn't ship them at all, could we?
-sv
12:42 p.m.
Seth Vidal (skvidal(a)fedoraproject.org) said:
>> If we end up needing yum plugin of some kind to handle this
can I call
>> it the free-randomstan plugin?
>
> We don't have a yum-patents plugin, or Provides(patents). Why are we
> going to such lengths here?
How would we have a Provides(patents) on pkgs in fedora? If the pkgs had
patent issues we couldn't ship them at all, could we?
What I'm saying is that in the amount of tossing around of ideas in this
thread, and the amount of work that would be required to sanely implement
this (and explain it in a way that makes sense to the users) we could
have fixed 99.9% of the packages to not ship flags about 5 times over.
Bill
12:46 p.m.
On Tue, 19 May 2009, Bill Nottingham wrote:
Seth Vidal (skvidal(a)fedoraproject.org) said:
>>> If we end up needing yum plugin of some kind to handle this can I call
>>> it the free-randomstan plugin?
>>
>> We don't have a yum-patents plugin, or Provides(patents). Why are we
>> going to such lengths here?
>
> How would we have a Provides(patents) on pkgs in fedora? If the pkgs had
> patent issues we couldn't ship them at all, could we?
What I'm saying is that in the amount of tossing around of ideas in this
thread, and the amount of work that would be required to sanely implement
this (and explain it in a way that makes sense to the users) we could
have fixed 99.9% of the packages to not ship flags about 5 times over.
I thought this thread was about explaining it in a way that our developers
understand it.
I'm sorry you feel your time has been wasted.
-sv
1:14 p.m.
Seth Vidal (skvidal(a)fedoraproject.org) said:
>>>> If we end up needing yum plugin of some kind to
handle this can I call
>>>> it the free-randomstan plugin?
>>>
>>> We don't have a yum-patents plugin, or Provides(patents). Why are we
>>> going to such lengths here?
>>
>> How would we have a Provides(patents) on pkgs in fedora? If the pkgs had
>> patent issues we couldn't ship them at all, could we?
>
> What I'm saying is that in the amount of tossing around of ideas in this
> thread, and the amount of work that would be required to sanely implement
> this (and explain it in a way that makes sense to the users) we could
> have fixed 99.9% of the packages to not ship flags about 5 times over.
>
I thought this thread was about explaining it in a way that our
developers understand it.
Which 'it' here are you referring to?
I'm sorry you feel your time has been wasted.
I just feel that once you've gotten to the point where we have to define
packaging policies around magic provides, rel-eng checks to make sure that
packages with magic provides don't end up in specific places, and then
we may need special plugins to handle them... we've gone beyond reasonable
solutions to the problem, and solutions that probably outweigh in effort
and complexity the amount of work required to package things to just not
use flags.
Bill
2:07 p.m.
On Tue, May 19, 2009 at 2:14 PM, Bill Nottingham <notting(a)redhat.com> wrote:
I just feel that once you've gotten to the point where we have to define
packaging policies around magic provides, rel-eng checks to make sure that
packages with magic provides don't end up in specific places, and then
we may need special plugins to handle them... we've gone beyond reasonable
solutions to the problem, and solutions that probably outweigh in effort
and complexity the amount of work required to package things to just not
use flags.
Do we have any kind of (even approximate) list of affected packages?
2:27 p.m.
On 05/19/2009 11:14 AM, Bill Nottingham wrote:
Seth Vidal (skvidal(a)fedoraproject.org) said:
>>>>> If we end up needing yum plugin of some kind to handle this can I
call
>>>>> it the free-randomstan plugin?
>>>> We don't have a yum-patents plugin, or Provides(patents). Why are we
>>>> going to such lengths here?
>>> How would we have a Provides(patents) on pkgs in fedora? If the pkgs had
>>> patent issues we couldn't ship them at all, could we?
>> What I'm saying is that in the amount of tossing around of ideas in this
>> thread, and the amount of work that would be required to sanely implement
>> this (and explain it in a way that makes sense to the users) we could
>> have fixed 99.9% of the packages to not ship flags about 5 times over.
>>
> I thought this thread was about explaining it in a way that our
> developers understand it.
Which 'it' here are you referring to?
> I'm sorry you feel your time has been wasted.
I just feel that once you've gotten to the point where we have to define
packaging policies around magic provides, rel-eng checks to make sure that
packages with magic provides don't end up in specific places, and then
we may need special plugins to handle them... we've gone beyond reasonable
solutions to the problem, and solutions that probably outweigh in effort
and complexity the amount of work required to package things to just not
use flags.
As far as I can see, these are the differences from the current policy:
1) magic provides vs magic package names
2) rel-eng checks that the magic provides aren't on the spin vs rel-eng
checks that -flags subpackages aren't required by anything else unless
it's in a whitelist of exceptions granted by FESCo (and rel-eng has to
check comps to make sure there are no -flags packages listed explicitly)
3) Adding a provides to packages that have flags vs porting packages to
make flags optional.
4) Porting packages in the main spin to make flags an optional
subpackage -- same for each.
5) possibly a yum plugin to handle the provides vs
nobody-thought-far-enough-ahead-to-see-that-we'd-need-a-yum-plugin-to-cover-that-case-with-naming-as-a-solution-as-well.
End result of both policies: Fedora Everything is not distributable in
flag banning countries. Specific Fedora spins may be. Without a yum
plugin, Fedora users have access to banned flag content if they want it.
With a yum plugin, this can be prevented... unless the user disables
the plugin.
With provides, releng's script has to be more complex in #2. With the
current policy, #3 is more work for every packager that has a package
containing flags (including maintainance to forward port our patches).
With the current policy we end up with lots of exceptions. For
instance, freeciv should fall under: "technically or substantively
essential to the package". The policy doesn't require marking these
packages as containing flags so it needs to be updated in some manner if
we want releng to be able to detect flag containing packages.
-Toshio
2:55 p.m.
On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote:
As far as I can see, these are the differences from the current
policy:
There is an easier option 3, which is no flags in Fedora period,
regardless of what spin. Far easier to implement.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:57 p.m.
On Tue, 19 May 2009, Jesse Keating wrote:
On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote:
> As far as I can see, these are the differences from the current
> policy:
There is an easier option 3, which is no flags in Fedora period,
regardless of what spin. Far easier to implement.
I like this one.
-sv
3:11 p.m.
Seth Vidal pisze:
On Tue, 19 May 2009, Jesse Keating wrote:
> On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote:
>> As far as I can see, these are the differences from the current
>> policy:
>
> There is an easier option 3, which is no flags in Fedora period,
> regardless of what spin. Far easier to implement.
>
I like this one.
-sv
This means that political correctness madness wins :(
Julian
3:22 p.m.
On Tue, May 19, 2009 at 12:55:36PM -0700, Jesse Keating wrote:
On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote:
> As far as I can see, these are the differences from the current
> policy:
There is an easier option 3, which is no flags in Fedora period,
regardless of what spin. Far easier to implement.
Or there's option 4, which is to not have a 'no flags' policy in Fedora.
It's even easier to implement, requires no package changes, and no
carrying of Fedora specific patches for ever more, and no loss of
perfectly good software from the distribution.
This sort of decision is always going to be a balance; on the one hand
there are clearly real costs to Fedora in having a blanket ban on flags,
and on the other we have (according to spot[1]) "no specific legal issue
at this time". It seems to me that that balance comes down squarely on
the side of leaving the flags alone.
Ewan
[1] https://fedorahosted.org/fesco/ticket/110
3:37 p.m.
Ewan Mac Mahon (ewan(a)macmahon.me.uk) said:
This sort of decision is always going to be a balance; on the one
hand
there are clearly real costs to Fedora in having a blanket ban on flags,
and on the other we have (according to spot[1]) "no specific legal issue
at this time".
They specifically stated that it may/will prevent Fedora from being
available or acceptable in some countries. That's not insignificant.
Bill
3:51 p.m.
On Di Mai 19 2009, Bill Nottingham wrote:
Ewan Mac Mahon (ewan(a)macmahon.me.uk) said:
> This sort of decision is always going to be a balance; on the one hand
> there are clearly real costs to Fedora in having a blanket ban on flags,
> and on the other we have (according to spot[1]) "no specific legal issue
> at this time".
They specifically stated that it may/will prevent Fedora from being
available or acceptable in some countries. That's not insignificant.
If there really are that much of people who will contribute to Fedora if they
can remove flags they dislike from Fedora, why don't they do the work required
for this, i.e. writing patches, adding support for this to rpm and yum, ...?
But I also doubt that people who would not use Fedora because some included
software uses a flag they hate are people one can work in a FOSS-oriented or
cooperative way with. So maybe this is also the reason for this.
Regards
Till
4:03 p.m.
On 05/19/2009 01:37 PM, Bill Nottingham wrote:
Ewan Mac Mahon (ewan(a)macmahon.me.uk) said:
> This sort of decision is always going to be a balance; on the one hand
> there are clearly real costs to Fedora in having a blanket ban on flags,
> and on the other we have (according to spot[1]) "no specific legal issue
> at this time".
They specifically stated that it may/will prevent Fedora from being
available or acceptable in some countries. That's not insignificant.
The current proposal doesn't fix this.
Flags are not banned by the current policy. Fedora can carry them:
1) in a separate flags subpackage as long as the main package does not
require it.
2) if the flag is "technically or substantively essential to the package".
-Toshio
4:29 p.m.
On Tue, May 19, 2009 at 04:37:22PM -0400, Bill Nottingham wrote:
Ewan Mac Mahon (ewan(a)macmahon.me.uk) said:
> This sort of decision is always going to be a balance; on the one hand
> there are clearly real costs to Fedora in having a blanket ban on flags,
> and on the other we have (according to spot[1]) "no specific legal issue
> at this time".
They specifically stated that it may/will prevent Fedora from being
available or acceptable in some countries. That's not insignificant.
I'm not sure I see that in the fesco trac ticket, but even so, I don't
think it necessarily follows from that that we should be stripping
flags. There are two basic questions (I think):
- Will stripping the flags make Fedora acceptable everywhere? We know
that various governments doesn't get on with certain flags, but how do
they feel about tor, gnupg, sword, or FreeCiv's text-based references to
Tibet? While the flags may be unacceptable, it's not clear that they're
the only thing that's unacceptable, and there's no advantage in
stripping the flags if Fedora remains off-limits in these countries
for other reasons.
- Even if a no flags policy would suffice to make Fedora acceptable in
certain countries, then is that benefit worth the costs in increases
package maintanance overhead, and removal of software from Fedora,
particularly given the relative ease of creating localised spins or
derivatives.
My guess is that simply removing flags isn't enough to make Fedora
acceptable the world over, and my opinion is that the benefits it does
bring are outweighed by the costs.
Ewan
4:44 p.m.
On 05/19/2009 10:37 PM, Bill Nottingham wrote:
Ewan Mac Mahon (ewan(a)macmahon.me.uk) said:
> This sort of decision is always going to be a balance; on the one hand
> there are clearly real costs to Fedora in having a blanket ban on flags,
> and on the other we have (according to spot[1]) "no specific legal issue
> at this time".
They specifically stated that it may/will prevent Fedora from being
available or acceptable in some countries. That's not insignificant.
That's a pretty vague sentence. Do we have something more specific to
work with, to justify this whole fiasco ? Have people complained ? Were
threats made ? Bugzilla tickets filed ? Did the PRC threaten to add
fedoraproject.org to the big firewall if we don't stop shipping FreeCIV
immediately (a CeasePackage-and-desist letter :-) ) ?
4:51 p.m.
On 05/19/2009 05:44 PM, Denis Leroy wrote:
That's a pretty vague sentence. Do we have something more
specific to
work with, to justify this whole fiasco ? Have people complained ? Were
threats made ? Bugzilla tickets filed ? Did the PRC threaten to add
fedoraproject.org to the big firewall if we don't stop shipping FreeCIV
immediately (a CeasePackage-and-desist letter :-) ) ?
People complained. I was asked to write a policy draft to handle flags.
Well, to be specific, I was asked to document the unwritten "no flags"
policy that we'd had from the Red Hat Linux days, but after giving it
thought and consulting with Red Hat Legal, I came up with the current
policy which:
* permits flags in optional subpackages
* permits flags when their use is not technically or substantively
essential to the package
* gives an explicit exception to flags when they are generic (fictional
countries count as generic)
* has an exception clause where a packager can plead their case to FESCo
This is substantially divergent from "No Flags".
~spot
5:13 p.m.
On 05/19/2009 11:51 PM, Tom "spot" Callaway wrote:
On 05/19/2009 05:44 PM, Denis Leroy wrote:
> That's a pretty vague sentence. Do we have something more specific to
> work with, to justify this whole fiasco ? Have people complained ? Were
> threats made ? Bugzilla tickets filed ? Did the PRC threaten to add
> fedoraproject.org to the big firewall if we don't stop shipping FreeCIV
> immediately (a CeasePackage-and-desist letter :-) ) ?
People complained.
How many ? Or is it just that one user from
https://bugzilla.redhat.com/show_bug.cgi?id=479265
versus the "a lot of users were asking for flags. a lot."
5:55 p.m.
On 05/19/2009 02:51 PM, Tom "spot" Callaway wrote:
On 05/19/2009 05:44 PM, Denis Leroy wrote:
> That's a pretty vague sentence. Do we have something more specific to
> work with, to justify this whole fiasco ? Have people complained ? Were
> threats made ? Bugzilla tickets filed ? Did the PRC threaten to add
> fedoraproject.org to the big firewall if we don't stop shipping FreeCIV
> immediately (a CeasePackage-and-desist letter :-) ) ?
People complained. I was asked to write a policy draft to handle flags.
Well, to be specific, I was asked to document the unwritten "no flags"
policy that we'd had from the Red Hat Linux days, but after giving it
thought and consulting with Red Hat Legal, I came up with the current
policy which:
* permits flags in optional subpackages
* permits flags when their use is not technically or substantively
essential to the package
s/not//
?
* gives an explicit exception to flags when they are generic
(fictional
countries count as generic)
Note that this one is tricky. A generic flag is fine. But if a real
group (not necessarily a country) associates themselves with the flag,
it would become banned under the current policy.
* has an exception clause where a packager can plead their case to
FESCo
This is substantially divergent from "No Flags".
<nod>
-Toshio
6:24 p.m.
Toshio Kuratomi wrote:
Note that this one is tricky. A generic flag is fine. But if a
real
group (not necessarily a country) associates themselves with the flag,
it would become banned under the current policy.
Then what would a "generic" flag be? Single-color flags are often used by
political groups (e.g. all black = fascist, so if you thought to avoid the
issue by using that, you've just made it worse).
The only reasonable definition of "generic" I can see is "this flag is not
used to represent a country", e.g. a set of flags being used as an icon
for "localization".
Kevin Kofler
6:42 p.m.
On 05/19/2009 04:24 PM, Kevin Kofler wrote:
Toshio Kuratomi wrote:
> Note that this one is tricky. A generic flag is fine. But if a real
> group (not necessarily a country) associates themselves with the flag,
> it would become banned under the current policy.
Then what would a "generic" flag be? Single-color flags are often used by
political groups (e.g. all black = fascist, so if you thought to avoid the
issue by using that, you've just made it worse).
"""
Flag images which are not specific to any location, country, nation,
geopolitical entity, language, ethnocultural concept, religion,
political movement, or institutions are permitted
"""
So yep, as you point out, the generic flag exception is somewhat hard to
work with.
The only reasonable definition of "generic" I can see is
"this flag is not
used to represent a country", e.g. a set of flags being used as an icon
for "localization".
That's unfortunately not the definition being used here. If it was, it
would be a more helpful clause.
-Toshio
3:15 p.m.
I wrote:
The only reasonable definition of "generic" I can see is
"this flag is not
used to represent a country", e.g. a set of flags being used as an icon
for "localization".
More on localization icons: I looked at the icon for
preferences-desktop-locale in several of our icon themes:
* gnome -> UN flag
* Mist -> inherited from gnome (UN flag)
* Fedora (GNOME) -> inherited from Mist (UN flag)
* oxygen -> UN flag
* crystalsvg -> US and German flags (uses KDE 3 icon naming, just "locale")
* Fedora-KDE -> inherits oxygen (UN flag), crystalsvg (KDE 3 name, 2 flags)
* Bluecurve -> US, Italian and Czech flags
Not a single of those icon themes is compliant with our policy (which says
the UN flag is to be treated like country flags)! Neither our default
themes in the 2 primary desktops are (including GNOME which supposedly has
a "no flags" policy, apparently that doesn't cover the UN flag unlike ours;
GNOME's UN flag is low-res only, so it ends up a bit stilized, but it's
recognizable as a UN flag), nor the theme coming to us from RHL which
supposedly didn't allow flags (and that one's not even a UN flag, but 3
country flags).
Kevin Kofler
3:57 p.m.
Arnaud Gomes-do-Vale pisze:
Jesse Keating <jkeating(a)redhat.com> writes:
> There is an easier option 3, which is no flags in Fedora period,
> regardless of what spin. Far easier to implement.
Am I the only one to think yellow is a particularly offensive color?
Please remove it from Fedora!
Or number 4. I heard it symbolises death in some Asian cultures.
Julian
3:26 p.m.
On Di Mai 19 2009, Jesse Keating wrote:
On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote:
> As far as I can see, these are the differences from the current
> policy:
There is an easier option 3, which is no flags in Fedora period,
regardless of what spin. Far easier to implement.
This is not easier for package maintainers who want to maintain a package in
Fedora that contains flags, because additional work has to be done by the
package maintainer. Adding some flag to the spec that indicates that the
package contains political flags is a log easier.
Regards
Till
3:37 p.m.
> There is an easier option 3, which is no flags in Fedora period,
> regardless of what spin. Far easier to implement.
This is not easier for package maintainers who want to maintain a package in
Fedora that contains flags, because additional work has to be done by the
package maintainer. Adding some flag to the spec that indicates that the
package contains political flags is a log easier.
Or a lot of packages will move from Fedora to RPMFusion-Free ?
Patents encombered packages are forbidden in Fedora, even if the
software is free, so we put them in RPMFusion.
Why not with flags ?
----------
Mathieu Bridon (bochecha)
4:08 p.m.
Till Maas (opensource(a)till.name) said:
> There is an easier option 3, which is no flags in Fedora
period,
> regardless of what spin. Far easier to implement.
This is not easier for package maintainers who want to maintain a package in
Fedora that contains flags, because additional work has to be done by the
package maintainer. Adding some flag to the spec that indicates that the
package contains political flags is a log easier.
We carry patches all the time, and if people can't manage to apply patches
to their packages when necessary, then co-maintainers may be in order.
And I'll be willing to pitch into help fix things that need fixing.
(drifiting afield from this specific issue now, but it's related)
And really... it's not about being 'easier for package maintainers'. I'm
really tired of hearing that trope applied any time any sort of policy
is applied or suggested, whether it be:
- not having flags in packages
- having actual update notes in bodhi (or even using bodhi at all)
- not pushing new libraries to every release immediately
- not cursing out your fellow developers
The entire point of joining a community like Fedora is to work together
towards some common goals.
To suggest as prima facie evidence that anything that makes things not
as easy for packagers is bad implies a view where the package maintainer
feels that his needs, his preferred workflow, or his convenience somehow
supercedes the needs of the project itself, or the needs of its users.
Frankly, such an attitude is just wrong. It smacks of elitism and an
overinflated sense of ego. In the context of the project, none of us is more
important than the project itself. Sometimes you have to do *actual work*
that can't be reduced to a three line perl script; it's part of pitching in
towards something greater than yourself. And in the grand scheme of things,
I'd suggest that a billion potential users and contributors far outweighs
the convenience of a few packagers (really, this will affect only a
small number of packagers, anyway.)
If maintainers can't handle that, well, then maybe they need to find a
comaintainer, or maybe Fedora isn't for them.
Bill
4:23 p.m.
On 05/19/2009 02:08 PM, Bill Nottingham wrote:
Till Maas (opensource(a)till.name) said:
>> There is an easier option 3, which is no flags in Fedora period,
>> regardless of what spin. Far easier to implement.
> This is not easier for package maintainers who want to maintain a package in
> Fedora that contains flags, because additional work has to be done by the
> package maintainer. Adding some flag to the spec that indicates that the
> package contains political flags is a log easier.
We carry patches all the time, and if people can't manage to apply patches
to their packages when necessary, then co-maintainers may be in order.
And I'll be willing to pitch into help fix things that need fixing.
(drifiting afield from this specific issue now, but it's related)
And really... it's not about being 'easier for package maintainers'. I'm
really tired of hearing that trope applied any time any sort of policy
is applied or suggested, whether it be:
- not having flags in packages
- having actual update notes in bodhi (or even using bodhi at all)
- not pushing new libraries to every release immediately
- not cursing out your fellow developers
The entire point of joining a community like Fedora is to work together
towards some common goals.
To suggest as prima facie evidence that anything that makes things not
as easy for packagers is bad implies a view where the package maintainer
feels that his needs, his preferred workflow, or his convenience somehow
supercedes the needs of the project itself, or the needs of its users.
Frankly, such an attitude is just wrong. It smacks of elitism and an
overinflated sense of ego. In the context of the project, none of us is more
important than the project itself. Sometimes you have to do *actual work*
that can't be reduced to a three line perl script; it's part of pitching in
towards something greater than yourself. And in the grand scheme of things,
I'd suggest that a billion potential users and contributors far outweighs
the convenience of a few packagers (really, this will affect only a
small number of packagers, anyway.)
I agree with this sentiment 100%. We're here to make better packages,
not whine about how making better packages is hard. However, I'd point
out that in this specifc case Jesse raised the "easier" argument and
Till was just replying to that.
-Toshio
4:36 p.m.
On Tue, 2009-05-19 at 14:23 -0700, Toshio Kuratomi wrote:
I agree with this sentiment 100%. We're here to make better
packages,
not whine about how making better packages is hard. However, I'd point
out that in this specifc case Jesse raised the "easier" argument and
Till was just replying to that.
I think that my point was that it is an easier to understand policy. It
may be more difficult to enact, but it is a far sight easier than trying
to figure out what other packages might require your flags, and if any
of those packages are on something called a "default spin", which can
change it's contents at any time.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:56 p.m.
On 05/19/2009 02:36 PM, Jesse Keating wrote:
On Tue, 2009-05-19 at 14:23 -0700, Toshio Kuratomi wrote:
> I agree with this sentiment 100%. We're here to make better packages,
> not whine about how making better packages is hard. However, I'd point
> out that in this specifc case Jesse raised the "easier" argument and
> Till was just replying to that.
I think that my point was that it is an easier to understand policy.
It came across as implementable, not as understandability:
""""
There is an easier option 3, which is no flags in Fedora period,
regardless of what spin. Far easier to implement.
"""
It
may be more difficult to enact, but it is a far sight easier than trying
to figure out what other packages might require your flags, and if any
of those packages are on something called a "default spin", which can
change it's contents at any time.
And here you're again arguing about implementation, not about
understandability.
Where we deal with implementation, we deal with Bill's note about
"easy". It's easier to trust that your packagers haven't packaged
anything that has flags than to write a script that looks for the
Provides (or filename) in the package set but it's not necessarily right
for Fedora.
-Toshio
5:09 p.m.
On Tue, 2009-05-19 at 14:56 -0700, Toshio Kuratomi wrote:
It came across as implementable, not as understandability:
""""
There is an easier option 3, which is no flags in Fedora period,
regardless of what spin. Far easier to implement.
"""
Sorry, I obviously typed without thinking (:
> It
> may be more difficult to enact, but it is a far sight easier than trying
> to figure out what other packages might require your flags, and if any
> of those packages are on something called a "default spin", which can
> change it's contents at any time.
And here you're again arguing about implementation, not about
understandability.
Where we deal with implementation, we deal with Bill's note about
"easy". It's easier to trust that your packagers haven't packaged
anything that has flags than to write a script that looks for the
Provides (or filename) in the package set but it's not necessarily right
for Fedora.
--
Jesse Keating RHCE (http://jkeating.livejournal.com)
Fedora Project (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca (http://identi.ca/jkeating)
5:45 p.m.
Bill Nottingham wrote:
(really, this will affect only a small number of packagers, anyway.)
I think you (and others) are significantly underestimating the number of
affected packages. The previous unwritten policy (from RHL times) not to
ship any flags wasn't enforced for community-maintained packages, several
packages include flags and some (e.g. freeciv) need them for proper
operation.
Kevin Kofler
9:05 a.m.
Kevin Kofler (kevin.kofler(a)chello.at) said:
Bill Nottingham wrote:
> (really, this will affect only a small number of packagers, anyway.)
I think you (and others) are significantly underestimating the number of
affected packages. The previous unwritten policy (from RHL times) not to
ship any flags wasn't enforced for community-maintained packages, several
packages include flags and some (e.g. freeciv) need them for proper
operation.
All you've mentioned are the same packages I already know about:
- kdebase (or some similar package in KDE)
- gcompris
- freeciv
If there's really a lot of packages, I'd like actual data as to what they
are; vague descriptions of 'several' doesn't really help frame the
discussion of the amount of work.
Bill
9:34 a.m.
-------- Original Message --------
Subject: Package Maintainers Flags policy
From: Bill Nottingham <notting(a)redhat.com>
To: Development discussions related to Fedora <fedora-devel-list(a)redhat.com>
Date: 05/20/2009 09:05 AM
All you've mentioned are the same packages I already know about:
- kdebase (or some similar package in KDE)
- gcompris
- freeciv
If there's really a lot of packages, I'd like actual data as to what they
are; vague descriptions of 'several' doesn't really help frame the
discussion of the amount of work.
Ah, so a (previously unwritten) policy was written in stone without any
real data to back it up and with zero discussion on a public forum.
Sounds like politics to me. I guess my dreams of running for FESCo are
crushed because I would never be able to do something like this.
11:29 a.m.
On Wed, 20 May 2009 10:05:38 -0400
Bill Nottingham <notting(a)redhat.com> wrote:
Kevin Kofler (kevin.kofler(a)chello.at) said:
> Bill Nottingham wrote:
> > (really, this will affect only a small number of packagers,
> > anyway.)
>
> I think you (and others) are significantly underestimating the
> number of affected packages. The previous unwritten policy (from
> RHL times) not to ship any flags wasn't enforced for
> community-maintained packages, several packages include flags and
> some (e.g. freeciv) need them for proper operation.
All you've mentioned are the same packages I already know about:
- kdebase (or some similar package in KDE)
- gcompris
- freeciv
- xfce4-xkb-plugin
is another one.
If there's really a lot of packages, I'd like actual data as
to what
they are; vague descriptions of 'several' doesn't really help frame
the discussion of the amount of work.
Totally agreed.
Bill
kevin
5:54 p.m.
On Tue, 2009-05-19 at 17:08 -0400, Bill Nottingham wrote:
(drifiting afield from this specific issue now, but it's
related)
And really... it's not about being 'easier for package maintainers'. I'm
really tired of hearing that trope applied any time any sort of policy
is applied or suggested, whether it be:
- not having flags in packages
- having actual update notes in bodhi (or even using bodhi at all)
- not pushing new libraries to every release immediately
- not cursing out your fellow developers
Those cases are different. In those cases (arguably except for the
last), the 'difficult' bit increases the actual quality of the product
we are producing. Carrying eternal patches to remove certain images for
reasons of political appeasement does not improve the actual quality of
Fedora. It is fine to impose burdens on maintainers where that leads to
a reasonable improvement in the quality of the product they're building,
but placing significant burdens on maintainers in order to please
certain external bodies is a far tougher sell.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:05 a.m.
On Di Mai 19 2009, Bill Nottingham wrote:
Till Maas (opensource(a)till.name) said:
> > There is an easier option 3, which is no flags in Fedora period,
> > regardless of what spin. Far easier to implement.
>
> This is not easier for package maintainers who want to maintain a package
> in Fedora that contains flags, because additional work has to be done by
> the package maintainer. Adding some flag to the spec that indicates that
> the package contains political flags is a log easier.
We carry patches all the time, and if people can't manage to apply patches
And in other cases we strictly stick to upstream or push patches to upstream.
And really... it's not about being 'easier for package
maintainers'. I'm
really tired of hearing that trope applied any time any sort of policy
is applied or suggested, whether it be:
- not having flags in packages
Not having flags in Fedora is not a technical improvement. Also does having
flags in Fedora not stop its existence in its current way, which would happen
if it violates US law.
- having actual update notes in bodhi (or even using bodhi at all)
I guess there is no majority of packagers that says that actual update notes
are bad. But still the process of creating these update notes could be
improved to make it easier for packagers. E.g. changes are tracked in three
disjunct places, the CVS changelog, the rpm changelog and the bodhi updates
notes, which are also disjunct for each Fedora release of the same NVR update
in different Fedora releases. Easy workflows will make mistakes less likely
and therefore improve the quality of packages or Fedora. With making it easy
for package maintainers I do not mean to remove all rules or policies, but to
make it as easy as possible to follow to them.
And about not using bodhi at all: When bodhi and koji were enrolled, they made
package maintainance a lot harder, without these obstacles improving packages.
E.g. buildlogs were hidden after a lot more links in koji (and the patch to
fix this took several months to be applied) and there was no commandline
client for bodhi.
- not pushing new libraries to every release immediately
The problem are not new libraries per se, but the problems that they way
produce, e.g. broken dependencies. Here it would also help to make it easier
for package maintainers to detect these problems to avoid them.
To suggest as prima facie evidence that anything that makes things
not
as easy for packagers is bad implies a view where the package maintainer
feels that his needs, his preferred workflow, or his convenience somehow
supercedes the needs of the project itself, or the needs of its users.
This is not what I am suggesting. I suggest that if there is anything that can
be changed to make Fedora or its packages better, it should be made as easy as
possible for packagers to do this.
And there were several suggestions to improve this for the flag policy here in
this thread.
- use a good name for the wiki page
- mark packages that use flags in an easier way than to move the flag images
to a -flag subpackage
- use a yum plugin to make it easier for users to install or not install flags
- make the wiki page visible in the wik, mention and link it in the right
places
Regards
Till
3:59 p.m.
On 05/19/2009 12:55 PM, Jesse Keating wrote:
On Tue, 2009-05-19 at 12:27 -0700, Toshio Kuratomi wrote:
> As far as I can see, these are the differences from the current
> policy:
There is an easier option 3, which is no flags in Fedora period,
regardless of what spin. Far easier to implement.
That's easier for releng but just as hard for the packager.
If you want something that's truly easier, then I propose, "flags are
just another piece of data provided by upstream unless US law makes us
care."
-Toshio
4:17 p.m.
On Tue, 2009-05-19 at 13:59 -0700, Toshio Kuratomi wrote:
That's easier for releng but just as hard for the packager.
Yes, it is unfortunate that our package set got to the point where flags
existed in some of the packages, and that the unwritten rule from RHL
and Fedora Core didn't make it forward into Fedora, the no flags rule.
We'd have to do some clean up, and potentially lose some software in the
process. We have to decide if we want to trade some software (and
likely some packagers) for the ability for our software to be
distributed to rather large targets, such as China, and potentially gain
contributors, not just packagers.
If you want something that's truly easier, then I propose,
"flags are
just another piece of data provided by upstream unless US law makes us
care."
There is another concern here. Red Hat Enterprise Linux (RHEL) will
likely continue the "no flags" policy, which means that any software
within Fedora that RHEL would like to ship, the packaging will have to
fork, and patches will have to be created. This isn't Fedora's problem,
but something for RHT to note when it is deciding what software to take
and how much work will be necessary to make it RHEL worthy.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:48 p.m.
On 05/19/2009 02:17 PM, Jesse Keating wrote:
On Tue, 2009-05-19 at 13:59 -0700, Toshio Kuratomi wrote:
> If you want something that's truly easier, then I propose, "flags are
> just another piece of data provided by upstream unless US law makes us
> care."
There is another concern here. Red Hat Enterprise Linux (RHEL) will
likely continue the "no flags" policy, which means that any software
within Fedora that RHEL would like to ship, the packaging will have to
fork, and patches will have to be created. This isn't Fedora's problem,
but something for RHT to note when it is deciding what software to take
and how much work will be necessary to make it RHEL worthy.
RHEL has to do that even with this policy. The policy doesn't ban
flags. It doesn't even banish them to subpackages in all cases.
-Toshio
5:10 p.m.
On Tue, 2009-05-19 at 14:48 -0700, Toshio Kuratomi wrote:
RHEL has to do that even with this policy. The policy doesn't
ban
flags. It doesn't even banish them to subpackages in all cases.
Right. In case it wasn't obvious, I don't like the proposed policy.
I'd much rather we went all the way and just disallowed flags, much like
gnome.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:28 p.m.
Jesse Keating wrote:
Right. In case it wasn't obvious, I don't like the proposed
policy.
Neither do I.
I'd much rather we went all the way and just disallowed flags,
much like
gnome.
I'd much rather we went all the way and just allowed flags, much like KDE.
That said, I think the approved compromise sucks less than banning flags
outright. But not much, it's still a problem for several packages.
Kevin Kofler
2:07 a.m.
On 05/20/2009 12:10 AM, Jesse Keating wrote:
On Tue, 2009-05-19 at 14:48 -0700, Toshio Kuratomi wrote:
> RHEL has to do that even with this policy. The policy doesn't ban
> flags. It doesn't even banish them to subpackages in all cases.
Right. In case it wasn't obvious, I don't like the proposed policy.
I'd much rather we went all the way and just disallowed flags, much like
gnome.
Gnome is an upstream project, while Fedora is not. So this "simple"
solution of yours is a mandated deviation from upstream, something that
is not very Fedora-like to start with, simply based on an irrational
fear of flags and on a single bugzilla complaint. If this is not an
absurd overreaction, I don't know what is.
10:57 a.m.
On Wed, 2009-05-20 at 09:07 +0200, Denis Leroy wrote:
Gnome is an upstream project, while Fedora is not. So this
"simple"
solution of yours is a mandated deviation from upstream, something that
is not very Fedora-like to start with, simply based on an irrational
fear of flags and on a single bugzilla complaint. If this is not an
absurd overreaction, I don't know what is.
There is history here from before Fedora existed. And we make mandated
deviation from upstream in other situations too, where the distribution
of the content goes against the project goals.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:52 a.m.
On Tue, May 19, 2009 at 02:17:49PM -0700, Jesse Keating wrote:
On Tue, 2009-05-19 at 13:59 -0700, Toshio Kuratomi wrote:
> That's easier for releng but just as hard for the packager.
Yes, it is unfortunate that our package set got to the point where flags
existed in some of the packages, and that the unwritten rule from RHL
and Fedora Core didn't make it forward into Fedora, the no flags rule.
I've just been having a look back at the FreeCiv versions from RHL and
Fedora core. It's not an exhaustive survey, but at least RHL 5.2, 6.2,
7.3, 8 and 9, and Fedora Cores 1, 2 and 3 contained FreeCiv packages,
complete with various flags.
As of FC4 the package seems to disappear from Core, probably in favour
of the one in Extras, and the earlier versions of RHL seem to have bits
missing from the copies on archive.download.redhat.com, so it's hard to
tell whether they included FreeCiv or not.
I think it's safe to say that if this unwritten rule ever existed, it
certainly wasn't enforced.
Ewan
11:09 a.m.
On Thu, 2009-05-21 at 16:52 +0100, Ewan Mac Mahon wrote:
I think it's safe to say that if this unwritten rule ever
existed, it
certainly wasn't enforced.
Oh my yes, we were terrible about rule enforcement within RHT. If it
wasn't a QA check item, it didn't get seen. Note the terrible package
quality. The customers who complained about the flags likely never ran
FreeCiv and thus never noticed the flags within. Had they noticed,
FreeCiv likely would have been altered, or removed.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:09 p.m.
Jesse Keating wrote:
Oh my yes, we were terrible about rule enforcement within RHT. If
it
wasn't a QA check item, it didn't get seen. Note the terrible package
quality. The customers who complained about the flags likely never ran
FreeCiv and thus never noticed the flags within. Had they noticed,
FreeCiv likely would have been altered, or removed.
The Bluecurve icon theme, which was even DEVELOPED at RH, also contains
country flags (see the preferences-desktop-locale.png icon).
Kevin Kofler
6:24 p.m.
On Fri, 2009-05-22 at 01:09 +0200, Kevin Kofler wrote:
The Bluecurve icon theme, which was even DEVELOPED at RH, also contains
country flags (see the preferences-desktop-locale.png icon).
Yep, RHT isn't perfect (who said they were?). This doesn't invalidate
what I wrote though.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:06 p.m.
On Wednesday 20 May 2009 00:46:37 Kevin Kofler wrote:
Toshio Kuratomi wrote:
> If you want something that's truly easier, then I propose, "flags are
> just another piece of data provided by upstream unless US law makes us
> care."
+1 to that proposal.
Kevin Kofler
+1 from me also
https://fedoraproject.org/wiki/Staying_close_to_upstream_projects
Alexander Kurtakov
11:44 a.m.
On Tue, 19 May 2009, Denis Leroy wrote:
On 05/19/2009 06:28 PM, Seth Vidal wrote:
> If we end up needing yum plugin of some kind to handle this can I call
> it the free-randomstan plugin?
I am sure people from countries with a "stan" suffix find your example classy
and in good taste. Congratulations.
I'm happy with randomstan, randomville, randomburg, randomton, etc, etc
The suffix -stān (spelled ـستان in the Perso-Arabic script) is Persian
for "place of", derived from the Indo-Aryan equivalent, -sthāna ...
en.wikipedia.org/wiki/-stan
I didn't mean it to point out any region of the world, only to denote
'place of'.
-sv
3:35 p.m.
On Di Mai 19 2009, Toshio Kuratomi wrote:
New Proposal:
[current definition of flags remains]
* Packages that include flags must show that they do this by having a
virtual Provides: Politics(flags).
With Conflicts:, this seems to be a lot easier to implement. Just add a pseudo
package named "no-flags" to the distribution and add a "Conflicts:
no-flags"
to any package that contains flags. Then install no-flags by default and every
flag-hater is happy and others can just remove the package.
Regards
Till
5:36 p.m.
Toshio Kuratomi wrote:
* If a package is on the main spin (or required by something on the
main
spin in the case of updates that pull in different packages)
Which one? There are 3 primary spins.
* This ties the policy to the existence of a "main spin".
I don't
believe there's serious plans to get rid of that but if we do, this
policy will need to be revised.
There is already no one main spin, there's the "Desktop" (GNOME) Live CD
and
there's the installer DVD, both of which are "the main" to some people, and
there's the KDE Live CD.
Now I wouldn't object to only banning flags from the GNOME Live image
because that means we could ship them in KDE packages. ;-) But I'd disagree
in at least 2 ways with the rationale for that decision (censoring flags in
the first place and considering only GNOME a first-class citizen).
Kevin Kofler
11:23 a.m.
On Tue, 2009-05-19 at 15:47 +0100, Ewan Mac Mahon wrote:
On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote:
>
> A list of current countries doesn't solve the problem. Let's take for
> example Freeciv, which was cited earlier as having flags as a core
> part of the experience (I'd disagree, but anyways).
>
The problem with FreeCiv is that the only distinction between a city or
unit of one nation and one of another is the flag[1], so there doesn't
seem to be any simple way to remove them. They could be replaced with
different flags graphics, but they'd all have to be distinct; you
couldn't just use (e.g.) the Fedora logo for every nation.
There's also the fact that FreeCiv in particular contains Tibet as a
playable nation; even if the flag were removed, I don't think refering
to the Tibetan nation would pass muster in China. That being the case
we're either going to need to go a lot further than removing just flags,
or accept that generic Fedora won't be 'China safe', in which case we
might as well leave the flags alone.
Ewan
[1] e.g: <http://freeciv.wikia.com/wiki/File:Big_window.png
That's a pretty big reason why games such as FreeCiv should stick to
fictional countries and fictional flags. It avoids all of these issues.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:25 a.m.
On Tue, 19 May 2009, Jesse Keating wrote:
On Tue, 2009-05-19 at 15:47 +0100, Ewan Mac Mahon wrote:
> On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote:
>>
>> A list of current countries doesn't solve the problem. Let's take for
>> example Freeciv, which was cited earlier as having flags as a core
>> part of the experience (I'd disagree, but anyways).
>>
> The problem with FreeCiv is that the only distinction between a city or
> unit of one nation and one of another is the flag[1], so there doesn't
> seem to be any simple way to remove them. They could be replaced with
> different flags graphics, but they'd all have to be distinct; you
> couldn't just use (e.g.) the Fedora logo for every nation.
>
> There's also the fact that FreeCiv in particular contains Tibet as a
> playable nation; even if the flag were removed, I don't think refering
> to the Tibetan nation would pass muster in China. That being the case
> we're either going to need to go a lot further than removing just flags,
> or accept that generic Fedora won't be 'China safe', in which case we
> might as well leave the flags alone.
>
> Ewan
>
> [1] e.g: <http://freeciv.wikia.com/wiki/File:Big_window.png
That's a pretty big reason why games such as FreeCiv should stick to
fictional countries and fictional flags. It avoids all of these issues.
Then the fictional residents of Ihaterandomstan and randomstan will be
outraged!
-sv
11:46 a.m.
On 05/19/2009 09:23 AM, Jesse Keating wrote:
On Tue, 2009-05-19 at 15:47 +0100, Ewan Mac Mahon wrote:
> On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote:
>> A list of current countries doesn't solve the problem. Let's take for
>> example Freeciv, which was cited earlier as having flags as a core
>> part of the experience (I'd disagree, but anyways).
>>
> The problem with FreeCiv is that the only distinction between a city or
> unit of one nation and one of another is the flag[1], so there doesn't
> seem to be any simple way to remove them. They could be replaced with
> different flags graphics, but they'd all have to be distinct; you
> couldn't just use (e.g.) the Fedora logo for every nation.
>
> There's also the fact that FreeCiv in particular contains Tibet as a
> playable nation; even if the flag were removed, I don't think refering
> to the Tibetan nation would pass muster in China. That being the case
> we're either going to need to go a lot further than removing just flags,
> or accept that generic Fedora won't be 'China safe', in which case we
> might as well leave the flags alone.
>
> Ewan
>
> [1] e.g:<http://freeciv.wikia.com/wiki/File:Big_window.png
That's a pretty big reason why games such as FreeCiv should stick to
fictional countries and fictional flags. It avoids all of these issues.
Using real countries does add value to freeciv (I'm not the only one
that clicks a country and reads about all the great leaders from there,
right? Right? Anyone? Bueller? ;-)
It's also unavoidable in other games that are meant to be simulations as
opposed to equally weighted wargames.
-Toshio
12:16 p.m.
On Tue, 19 May 2009, Toshio Kuratomi wrote:
Using real countries does add value to freeciv (I'm not the only
one that
clicks a country and reads about all the great leaders from there, right?
Right? Anyone? Bueller? ;-)
And this is why we aren't making a blanket black/white policy but letting
fesco adjudicate the items where it is blurrier.
It's also unavoidable in other games that are meant to be
simulations as
opposed to equally weighted wargames.
and in some cases those games may have to be dropped.
Sometimes things suck.
I'd like to see a show of hands of people who are surprised.
oh, look, no one has their hands up.
-sv
12:27 p.m.
I'd like to see a show of hands of people who are surprised.
Actually, I am totally amazed that such a thing as a flag in a
software can cause so many troubles.
Call me naive, maybe I live in a parallel world populated only with
Care Bears, but I really would never have imagined that people could
boycott a product because it includes a reference to a place in the
world that they do not recognized.
So, here is me raising my hand.
Anyway, I don't want to add anything more to the flames, I really do
not care about this issue and I'll be happy to apply the policy
(actually, I'm not sure I already saw a flag in Fedora :)
Regards,
----------
Mathieu Bridon (bochecha)
12:44 p.m.
On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote:
> I'd like to see a show of hands of people who are surprised.
Actually, I am totally amazed that such a thing as a flag in a
software can cause so many troubles.
Call me naive, maybe I live in a parallel world populated only with
Care Bears, but I really would never have imagined that people could
boycott a product because it includes a reference to a place in the
world that they do not recognized.
So, here is me raising my hand.
Anyway, I don't want to add anything more to the flames, I really do
not care about this issue and I'll be happy to apply the policy
(actually, I'm not sure I already saw a flag in Fedora :)
From what I can gather from google you live in France.
Here is a list of the current French territorial disputes:
Madagascar claims the French territories of Bassas da India, Europa
Island, Glorioso Islands, and Juan de Nova Island; Comoros claims Mayotte;
Mauritius claims Tromelin Island; territorial dispute between Suriname and
the French overseas department of French Guiana; France asserts a
territorial claim in Antarctica (Adelie Land); France and Vanuatu claim
Matthew and Hunter Islands, east of New Caledonia
hope that helps.
-sv
1:49 p.m.
On 05/19/2009 07:44 PM, Seth Vidal wrote:
Here is a list of the current French territorial disputes:
Madagascar claims the French territories of Bassas da India, Europa
Island, Glorioso Islands, and Juan de Nova Island; Comoros claims
Mayotte; Mauritius claims Tromelin Island; territorial dispute between
Suriname and the French overseas department of French Guiana; France
asserts a territorial claim in Antarctica (Adelie Land); France and
Vanuatu claim Matthew and Hunter Islands, east of New Caledonia
This is getting completely off topic. This has nothing to do about the
legality of the Fedora distribution containing country flags pictures.
2:01 p.m.
On Tue, 19 May 2009, Denis Leroy wrote:
On 05/19/2009 07:44 PM, Seth Vidal wrote:
> Here is a list of the current French territorial disputes:
>
> Madagascar claims the French territories of Bassas da India, Europa
> Island, Glorioso Islands, and Juan de Nova Island; Comoros claims
> Mayotte; Mauritius claims Tromelin Island; territorial dispute between
> Suriname and the French overseas department of French Guiana; France
> asserts a territorial claim in Antarctica (Adelie Land); France and
> Vanuatu claim Matthew and Hunter Islands, east of New Caledonia
This is getting completely off topic. This has nothing to do about the
legality of the Fedora distribution containing country flags pictures.
you're right - I intended to send that message off-list and I forgot to
clip the list entry.
mea culpa
-sv
1:56 p.m.
On Tue, May 19, 2009 at 01:44:37PM -0400, Seth Vidal wrote:
Here is a list of the current French territorial disputes:
Madagascar claims the French territories of Bassas da India, Europa
Island, Glorioso Islands, and Juan de Nova Island; Comoros claims
Mayotte; Mauritius claims Tromelin Island; territorial dispute between
Suriname and the French overseas department of French Guiana; France
asserts a territorial claim in Antarctica (Adelie Land);
This has been suspended, I believe.
France and
Vanuatu claim Matthew and Hunter Islands, east of New Caledonia
That doesn't make the flags of those countries illegal in France (though
there are other things that are censored in France, for example it
could be possible for a medical software to be illegal in France).
Maybe some crypto software in fedora is still illegal in France, at
least it was clearly the case for openssh in redhat 5-6 years ago.
Coping with every country laws, including countries where there is
no free speech looks wrong to me (and most restrictions in the US
looks already wrong to me, including patents and other stuff, like
crypto regulations and certainly other I don't know about). I think
that Fedora should only abide to US laws and the burden to make derivative
works that are consistent with other country law should be on the
shoulder of those who want to have a distro acceptable for their law.
As an added benefit, that would also leave the possibility for those who
want to resist those laws to do it easily.
--
Pat
2:24 p.m.
Le mardi 19 mai 2009 à 20:56 +0200, Patrice Dumas a écrit :
I think
that Fedora should only abide to US laws and the burden to make derivative
works that are consistent with other country law should be on the
shoulder of those who want to have a distro acceptable for their law.
Why do you think the US is any more neutral in this matter than other
countries ?
--
Nicolas Mailhot
2:28 p.m.
On Tue, May 19, 2009 at 09:24:37PM +0200, Nicolas Mailhot wrote:
Le mardi 19 mai 2009 à 20:56 +0200, Patrice Dumas a écrit :
> I think
> that Fedora should only abide to US laws and the burden to make derivative
> works that are consistent with other country law should be on the
> shoulder of those who want to have a distro acceptable for their law.
Why do you think the US is any more neutral in this matter than other
countries ?
I don't think so, and I said above that there are things I dislike in
US laws, but Redhat and fedora are US entities, so it somehow
determines the minimal set of laws fedora shouldn't break.
--
Pat
2:44 p.m.
Patrice Dumas pisze:
On Tue, May 19, 2009 at 09:24:37PM +0200, Nicolas Mailhot wrote:
> Le mardi 19 mai 2009 à 20:56 +0200, Patrice Dumas a écrit :
>> I think
>> that Fedora should only abide to US laws and the burden to make derivative
>> works that are consistent with other country law should be on the
>> shoulder of those who want to have a distro acceptable for their law.
> Why do you think the US is any more neutral in this matter than other
> countries ?
I don't think so, and I said above that there are things I dislike in
US laws, but Redhat and fedora are US entities, so it somehow
determines the minimal set of laws fedora shouldn't break.
--
Pat
That's the most sane argument I've seen in this discussion. Fedora is a
US-based distribution, so let's stick to what's legal to distribute in
the States. If we try to remove every bit which is illegal in one place
or another, sooner or later we will end up with a product to crippled to
be useful (as if lack of mp3/dvd playback ability wasn't enough).
Julian
P.S.
I tried to stay out of this flamewar, but the overwhelming political
correctness needs to be stopped. There's a saying “don't be more saint
than the pope” where I come from.
2:34 p.m.
On 05/19/2009 12:24 PM, Nicolas Mailhot wrote:
Le mardi 19 mai 2009 à 20:56 +0200, Patrice Dumas a écrit :
> I think
> that Fedora should only abide to US laws and the burden to make derivative
> works that are consistent with other country law should be on the
> shoulder of those who want to have a distro acceptable for their law.
Why do you think the US is any more neutral in this matter than other
countries ?
Because of spot's response on https://fedorahosted.org/fesco/ticket/110 ::
jstanley:
1) What is the legal issue (if there is one)?
[...]
spot:
So, to your questions:
1. There is no specific legal issue at this time.
-Toshio
5:21 p.m.
Mathieu Bridon (bochecha) wrote:
Anyway, sticking to the official internation standard list of
countries maintained by UN (if such a list exists) seems much more
neutral to me.
Not really. You'd remove at least one of the flags KDE ships and take a
political stand by doing that.
Kevin Kofler
8:55 a.m.
On Tue, 19 May 2009, Mathieu Bridon (bochecha) wrote:
Are there countries not agreeing with each others regarding the
official status of other countries (not like country A says country B
is inside country A, but rather country A and country B disagree on
the status of country C) ? Are there countries that disagree with the
UN regarding the official status of a "geographic area" ?
Yes.
http://en.wikipedia.org/wiki/Disputed_territories#Disputes_involving_part...
the list goes on and on and on.
-sv
9:10 a.m.
Once upon a time, Mathieu Bridon (bochecha) <bochecha(a)fedoraproject.org> said:
But what is the official internationally recognized status of Taiwan
?
There is no such thing. Who makes it "official" (hint: lots of people
disagree with the answer "the UN")? Some countries recognize Taiwan as
an independent country, some don't, and some kind-of do (but not
"officially").
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:21 a.m.
Mathieu Bridon (bochecha) wrote:
> And then your next question is "does the Chinese gov't
really care about a
> linux distro having a Taiwanese or Tibetan flag in some programs it ships?"
> and the answer to that question is yes, very much.
>
> So, of course does this mean we are siding with china? No, we're not siding
> with anyone, that's the whole point.
>
> Flags mean a lot to a lot of people. They carry a lot of patriotic crap
> w/them.
But what is the official internationally recognized status of Taiwan ?
There is no World Governement that decides whether independent countries
exist. However, Taiwan does not claim to be a country independent of
China: the Taiwanese KMT, expelled from Beijing in by Mao, still claims
to be the legitimate ruler of *all* China.
If that's a part of china, then it's not an actual country,
then we
can remove its flag.
If that's an independent country, then it has a flag, and we can use it.
I really wonder why we are trying to solve those geopolitical
international issues. Those are for the governments and the UN to
solve. They agree on a list of officially recognized countries, and we
use it.
The UN does not decide what is an "officially recognized country". All
it can do is decide whether to admit a country as a member. This is
not the same as being a sovereign state, which in practice depends on
being recognized by other nations.
Andrew.
4:10 p.m.
2009/5/19 Andrew Haley <aph(a)redhat.com>:
The UN does not decide what is an "officially recognized country". All
it can do is decide whether to admit a country as a member. This is
not the same as being a sovereign state, which in practice depends on
being recognized by other nations.
Isn't that what "United Nations" is? A bunch of countries that try to
work diplomatically problems.
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
8:52 a.m.
On 05/19/2009 03:30 PM, Seth Vidal wrote:
Flags mean a lot to a lot of people. They carry a lot of patriotic
crap
w/them.
Seth, I think we all agree to that. There is a list of <flag,context>
pairs that causes problems :-). To be more accurate, there is a
well-known very short list of <flag,context> pairs that Fedora cannot
ship with legally. The point is: the policy is way overreaching. This
would be better dealt with on a case-by-case basis, only when we know
for a *fact* we cannot ship Fedora with a specific flag. A flag that has
no legal issues but may offend someone is not a good enough reason, it
becomes an upstream project issue rather than a Fedora issue.
-denis
11:21 a.m.
On Tue, 2009-05-19 at 15:52 +0200, Denis Leroy wrote:
Seth, I think we all agree to that. There is a list of
<flag,context>
pairs that causes problems :-). To be more accurate, there is a
well-known very short list of <flag,context> pairs that Fedora cannot
ship with legally. The point is: the policy is way overreaching. This
would be better dealt with on a case-by-case basis, only when we know
for a *fact* we cannot ship Fedora with a specific flag. A flag that has
no legal issues but may offend someone is not a good enough reason, it
becomes an upstream project issue rather than a Fedora issue.
When you single out the flags to remove, you are in fact siding with the
people that take offense to those flags, eg China. I certainly don't
want the Fedora project to appear to be taking sides with China in their
Tibet issues. The only way to be fair, is if we're going to remove one
flag, we remove them all.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:18 p.m.
On Mon, 2009-05-18 at 09:09 -0600, Kevin Fenzi wrote:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Please see:
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
and direct any comments to FESCo in a ticket or via the devel list.
Thanks, and sorry for the oversight. ;(
This should explain the reason why country flags shouldn't show up in
interfaces:
http://community.livejournal.com/xkbconfig/982.html
(I didn't even read the policy, but I guess it's the same one we had
arguments over in GNOME 6 years ago, and a bit before that in RH
itself).
It could cause problems in Europe, in Asia, and in North America (and
that's just on top of my head).
Cheers
12:32 p.m.
Bastien Nocera wrote:
(I didn't even read the policy, but I guess it's the same one
we had
arguments over in GNOME 6 years ago, and a bit before that in RH
itself).
On the other hand, KDE upstream explicitly decided NOT to ban flags, as they
consider banning flags to be a political move and to go against KDE's
principle of political neutrality. Some involved also considered it a free
speech issue. (Sorry, this is from memory, I can't find the old ML link
right now.)
And FYI, the current policy doesn't ban flags entirely, but they have to be
in a -flags package which is not installed by default (this is now
implemented for kdebase-runtime, it has a kdebase-runtime-flags subpackage;
before that, flags used to be removed from kdebase-runtime entirely, as per
the old unwritten policy, the current one is a compromise).
It shall be noted that many users complained about flags being removed (they
expect the keyboard layout chooser to use them), and the current solution
where -flags is optional and not installed by default isn't very helpful
either (but better than not having them at all).
Kevin Kofler
12:45 p.m.
On Mon, 2009-05-18 at 19:32 +0200, Kevin Kofler wrote:
Bastien Nocera wrote:
> (I didn't even read the policy, but I guess it's the same one we had
> arguments over in GNOME 6 years ago, and a bit before that in RH
> itself).
On the other hand, KDE upstream explicitly decided NOT to ban flags, as they
consider banning flags to be a political move and to go against KDE's
principle of political neutrality.
And as soon as you make a choice, one way or the other, you end up not
being neutral any more. Maybe the project is neutral, but the person
that makes the decision and is part of the project isn't.
12:52 p.m.
On 05/18/2009 07:32 PM, Kevin Kofler wrote:
Bastien Nocera wrote:
> And FYI, the current policy doesn't ban flags entirely, but they have to be
in a -flags package which is not installed by default
That's about the same as banning them. What percentage of users do you
think will install them, let alone be aware they exist ? I understand
the reasoning behind this policy, but overall this seems like a gross
overreaction. We have a vast international community here, why not let
this community write up a black-list of sensitive flags to avoid, rather
than ban'em all ?
-denis
12:54 p.m.
On Mon, 18 May 2009, Denis Leroy wrote:
On 05/18/2009 07:32 PM, Kevin Kofler wrote:
> Bastien Nocera wrote:
>> And FYI, the current policy doesn't ban flags entirely, but they have to
>> be
> in a -flags package which is not installed by default
That's about the same as banning them. What percentage of users do you think
will install them, let alone be aware they exist ? I understand the reasoning
behind this policy, but overall this seems like a gross overreaction. We have
a vast international community here, why not let this community write up a
black-list of sensitive flags to avoid, rather than ban'em all ?
B/c the members from Ihaterandomstan and the folks from randomstan will
never come to consensus short of involving the UN or possibly Jimmy
Carter.
-sv
12:56 p.m.
Once upon a time, Denis Leroy <denis(a)poolshark.org> said:
We have a vast international community here, why not let
this community write up a black-list of sensitive flags to avoid, rather
than ban'em all ?
So what do you do when country A wants country B's flag removed and
country B wants country A's flag removed? Who gets to say which flag is
in and which flag is out?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:39 p.m.
Denis Leroy wrote:
On 05/18/2009 07:32 PM, Kevin Kofler wrote:
> And FYI, the current policy doesn't ban flags entirely, but they have to
> be in a -flags package which is not installed by default
That's about the same as banning them. What percentage of users do you
think will install them, let alone be aware they exist ?
It wouldn't be so bad if a package could suggest another package without
requiring it, so that Yum or PackageKit could tell the user "There is also a
kdebase-runtime-flags package that you can install if you like".
Björn Persson
1:33 p.m.
On Mon, May 18, 2009 at 07:32:56PM +0200, Kevin Kofler wrote:
It shall be noted that many users complained about flags being
removed (they
expect the keyboard layout chooser to use them), and the current solution
where -flags is optional and not installed by default isn't very helpful
either (but better than not having them at all).
They may expect the keyboard layout chooser to use them, but you end up
with awkward situations where geopolitical flags don't usefully
represent keyboard layouts that are used in multiple countries or
countries which have multiple keyboard layouts. Even from a purely
technical perspective, flags rarely accurately depict what you're trying
to present to the user.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:41 p.m.
Matthew Garrett wrote:
They may expect the keyboard layout chooser to use them, but you end
up
with awkward situations where geopolitical flags don't usefully
represent keyboard layouts that are used in multiple countries or
countries which have multiple keyboard layouts. Even from a purely
technical perspective, flags rarely accurately depict what you're trying
to present to the user.
Yet KDE upstream and basically all the distros shipping KDE use them. We are
the odd ones out.
Kevin Kofler
1:58 p.m.
On Mon, May 18, 2009 at 08:41:05PM +0200, Kevin Kofler wrote:
Matthew Garrett wrote:
> They may expect the keyboard layout chooser to use them, but you end up
> with awkward situations where geopolitical flags don't usefully
> represent keyboard layouts that are used in multiple countries or
> countries which have multiple keyboard layouts. Even from a purely
> technical perspective, flags rarely accurately depict what you're trying
> to present to the user.
Yet KDE upstream and basically all the distros shipping KDE use them. We are
the odd ones out.
There's several cases where we fix bugs that upstream thinks of as
features.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:11 p.m.
2009/5/18 Kevin Kofler
And FYI, the current policy doesn't ban flags entirely, but they
have to be
in a -flags package which is not installed by default (this is now
implemented for kdebase-runtime, it has a kdebase-runtime-flags subpackage;
before that, flags used to be removed from kdebase-runtime entirely, as per
the old unwritten policy, the current one is a compromise).
Out of curiosity, any reason this is done for kdebase-runtime but not
ktorrent?
--
Paul
5:46 a.m.
2009/5/18 Paul Black <paul-fedora(a)saturnine.org.uk>:
2009/5/18 Kevin Kofler
>
> And FYI, the current policy doesn't ban flags entirely, but they have to
> be
> in a -flags package which is not installed by default (this is now
> implemented for kdebase-runtime, it has a kdebase-runtime-flags
> subpackage;
> before that, flags used to be removed from kdebase-runtime entirely, as
> per
> the old unwritten policy, the current one is a compromise).
Out of curiosity, any reason this is done for kdebase-runtime but not
ktorrent?
Ugh?
Ktorrent has geo-political flags in the connection peers window.
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
4:43 p.m.
Paul Black wrote:
Out of curiosity, any reason this is done for kdebase-runtime but
not
ktorrent?
Because there's no enforcement of the policy and the ktorrent maintainer(s)
just didn't do the change yet.
It also needs to be verified that KTorrent will work properly if you remove
the flags (i.e. don't install the subpackage).
Kevin Kofler
3:38 p.m.
Kevin Kofler wrote:
It shall be noted that many users complained about flags being
removed
(they expect the keyboard layout chooser to use them), and the current
solution where -flags is optional and not installed by default isn't very
helpful either (but better than not having them at all).
To me it would seem more reasonable to install the flags by default. Then the
anti-whatever extremists could just remove them, and the more relaxed among
us would see the user interface the way the authors intended without jumping
through additional hoops.
To make it easy to remove all flags there could be a ban-flags package that
would conflict with all the -flags subpackages.
Björn Persson
1:20 a.m.
On Monday 18 May 2009 22:38:45 Björn Persson wrote:
Kevin Kofler wrote:
> It shall be noted that many users complained about flags being removed
> (they expect the keyboard layout chooser to use them), and the current
> solution where -flags is optional and not installed by default isn't very
> helpful either (but better than not having them at all).
To me it would seem more reasonable to install the flags by default. Then
the anti-whatever extremists could just remove them, and the more relaxed
among us would see the user interface the way the authors intended without
jumping through additional hoops.
To make it easy to remove all flags there could be a ban-flags package that
would conflict with all the -flags subpackages.
Björn Persson
+1, IMO flags should be installed by default.
removing flags by default is definitely overreaction
Fedora should be FREE
If someone "really" needs to remove flags, we should provide easy way to
remove/don't install flags, which are installed by default for people living in
free world.
They who can give up essential liberty to obtain a little temporary safety,
deserve neither liberty nor safety.
---- Benjamin Franklin
(I was looking for log of fesco meeting, who is a freedom fighter here and
who'll get my vote next time.... no one, that's sad...)
8 a.m.
2009/5/18 Björn Persson <bjorn(a)xn--rombobjrn-67a.se>:
To me it would seem more reasonable to install the flags by default.
Then the
anti-whatever extremists could just remove them, and the more relaxed among
us would see the user interface the way the authors intended without jumping
through additional hoops.
+1
But I will try to say it in another way.
Unfortunate peoples that live in countries where a _simple_ flag can
give troubles for whatever cause/reason, can remove them all to be
able to use Fedora. But please, don't cut our freedom just to be more
friendly with authoritarian regimes.
Alphonse
8:59 a.m.
On Tue, 19 May 2009, alcapcom wrote:
2009/5/18 Björn Persson <bjorn(a)xn--rombobjrn-67a.se>:
> To me it would seem more reasonable to install the flags by default. Then the
> anti-whatever extremists could just remove them, and the more relaxed among
> us would see the user interface the way the authors intended without jumping
> through additional hoops.
+1
But I will try to say it in another way.
Unfortunate peoples that live in countries where a _simple_ flag can
give troubles for whatever cause/reason, can remove them all to be
able to use Fedora. But please, don't cut our freedom just to be more
friendly with authoritarian regimes.
What if a non-authoritarian regime didn't want us to distribute a flag
that was offensive to their democratically-empowered populace? Would that
be okay then?
the whole reason for nuking the set of flags entirely is so we are NOT
choosing sides.
-sv
10:30 a.m.
On Tue, 2009-05-19 at 09:59 -0400, Seth Vidal wrote:
On Tue, 19 May 2009, alcapcom wrote:
> 2009/5/18 Björn Persson <bjorn(a)xn--rombobjrn-67a.se>:
>> To me it would seem more reasonable to install the flags by default. Then the
>> anti-whatever extremists could just remove them, and the more relaxed among
>> us would see the user interface the way the authors intended without jumping
>> through additional hoops.
>
> +1
>
> But I will try to say it in another way.
>
> Unfortunate peoples that live in countries where a _simple_ flag can
> give troubles for whatever cause/reason, can remove them all to be
> able to use Fedora. But please, don't cut our freedom just to be more
> friendly with authoritarian regimes.
What if a non-authoritarian regime didn't want us to distribute a flag
that was offensive to their democratically-empowered populace? Would that
be okay then?
Say, using pretzels and sausages on flags instead of Swastikas...
http://www.spiegel.de/international/zeitgeist/0,1518,617987,00.html
the whole reason for nuking the set of flags entirely is so we are
NOT
choosing sides.
Which was my early answer to Kevin on the subject, and comforts me in my
thinking :)
12:12 p.m.
2009/5/19 Seth Vidal <skvidal(a)fedoraproject.org>:
What if a non-authoritarian regime didn't want us to distribute a
flag that
was offensive to their democratically-empowered populace? Would that be okay
then?
IMHO it's an upstream problem not a Fedora one.
Maybe sometimes upstream are to close to a given conflict to take a
appropriate decision. In such cases, FESCO can use the current policy
but only in this kind of cases. Make that sens?
the whole reason for nuking the set of flags entirely is so we are
NOT
choosing sides.
It's a way of doing, maybe not the only one.
Alphonse
8:58 p.m.
On Tue, May 19, 2009 at 6:59 AM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
What if a non-authoritarian regime didn't want us to distribute a
flag that
was offensive to their democratically-empowered populace? Would that be okay
then?
Please Seth, a non-authoritarian regime wouldn't be making demands on
what you can distribute, if they did, they would be authoritarian.
Your logic needs to be improved, and I am in disagreement with you on
this topic.
-Chris
9:05 p.m.
Once upon a time, Christopher Stone <chris.stone(a)gmail.com> said:
Please Seth, a non-authoritarian regime wouldn't be making
demands on
what you can distribute, if they did, they would be authoritarian.
Can you name a non-authoritarian regime then? Hint: China isn't the
only country that restricts flags.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:05 p.m.
On Tue, 2009-05-19 at 18:58 -0700, Christopher Stone wrote:
On Tue, May 19, 2009 at 6:59 AM, Seth Vidal
<skvidal(a)fedoraproject.org> wrote:
> What if a non-authoritarian regime didn't want us to distribute a flag that
> was offensive to their democratically-empowered populace? Would that be okay
> then?
Please Seth, a non-authoritarian regime wouldn't be making demands on
what you can distribute, if they did, they would be authoritarian.
Germany has fairly strong (democratically imposed) restrictions on
freedom of speech as it relates to the Nazi regime and the Holocaust. If
Fedora were to include some software which impinged on those
restrictions in some way, it wouldn't be legal to distribute it in
Germany. It's perfectly possible to envisage a situation in which a
piece of software would be non-distributable in Germany, a country few
would describe as an 'authoritarian regime'.
(In fact, it's happened. The game Wolfenstein 3-D had to be
substantially modified for distribution in Germany.
http://en.wikipedia.org/wiki/Wolfenstein_3D#Controversy )
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9:13 p.m.
On Tue, May 19, 2009 at 7:05 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Tue, 2009-05-19 at 18:58 -0700, Christopher Stone wrote:
> On Tue, May 19, 2009 at 6:59 AM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
> > What if a non-authoritarian regime didn't want us to distribute a flag that
> > was offensive to their democratically-empowered populace? Would that be okay
> > then?
>
> Please Seth, a non-authoritarian regime wouldn't be making demands on
> what you can distribute, if they did, they would be authoritarian.
Germany has fairly strong (democratically imposed) restrictions on
freedom of speech as it relates to the Nazi regime and the Holocaust. If
Fedora were to include some software which impinged on those
restrictions in some way, it wouldn't be legal to distribute it in
Germany. It's perfectly possible to envisage a situation in which a
piece of software would be non-distributable in Germany, a country few
would describe as an 'authoritarian regime'.
Did you know that the Nevada state convention last year had to be
indefinitely postponed because Ron Paul was going to win the majority
of delegates?
No, I cannot name a non-authoritarian regime.
9:19 p.m.
On Tue, 19 May 2009, Christopher Stone wrote:
On Tue, May 19, 2009 at 6:59 AM, Seth Vidal
<skvidal(a)fedoraproject.org> wrote:
> What if a non-authoritarian regime didn't want us to distribute a flag that
> was offensive to their democratically-empowered populace? Would that be okay
> then?
Please Seth, a non-authoritarian regime wouldn't be making demands on
what you can distribute, if they did, they would be authoritarian.
Your logic needs to be improved, and I am in disagreement with you on
this topic.
Making laws does not make a gov't authoritarian.
or rather if you believe that making laws makes a gov't authoritarian then
there is no point in continuing the conversation.
Germany bans nazi flags - that's a classic example of a non-authoritarian
gov't keeping us from distributing specific flags.
-sv
9:30 p.m.
On Tue, May 19, 2009 at 7:19 PM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
On Tue, 19 May 2009, Christopher Stone wrote:
> On Tue, May 19, 2009 at 6:59 AM, Seth Vidal <skvidal(a)fedoraproject.org>
> wrote:
>>
>> What if a non-authoritarian regime didn't want us to distribute a flag
>> that
>> was offensive to their democratically-empowered populace? Would that be
>> okay
>> then?
>
> Please Seth, a non-authoritarian regime wouldn't be making demands on
> what you can distribute, if they did, they would be authoritarian.
> Your logic needs to be improved, and I am in disagreement with you on
> this topic.
Making laws does not make a gov't authoritarian.
or rather if you believe that making laws makes a gov't authoritarian then
there is no point in continuing the conversation.
Germany bans nazi flags - that's a classic example of a non-authoritarian
gov't keeping us from distributing specific flags.
I would argue that it depends on the law. I would also argue that
banning something like a flag means that you fear what that flag
represents. The Chinese have to censor a lot of information because
they fear it. The Communist party fears losing its power, that is why
they censor and ban certain information.
9:48 p.m.
On Tue, 19 May 2009, Christopher Stone wrote:
On Tue, May 19, 2009 at 7:19 PM, Seth Vidal
<skvidal(a)fedoraproject.org> wrote:
>
>
> On Tue, 19 May 2009, Christopher Stone wrote:
>
>> On Tue, May 19, 2009 at 6:59 AM, Seth Vidal <skvidal(a)fedoraproject.org>
>> wrote:
>>>
>>> What if a non-authoritarian regime didn't want us to distribute a flag
>>> that
>>> was offensive to their democratically-empowered populace? Would that be
>>> okay
>>> then?
>>
>> Please Seth, a non-authoritarian regime wouldn't be making demands on
>> what you can distribute, if they did, they would be authoritarian.
>> Your logic needs to be improved, and I am in disagreement with you on
>> this topic.
>
> Making laws does not make a gov't authoritarian.
>
> or rather if you believe that making laws makes a gov't authoritarian then
> there is no point in continuing the conversation.
>
> Germany bans nazi flags - that's a classic example of a non-authoritarian
> gov't keeping us from distributing specific flags.
I would argue that it depends on the law. I would also argue that
banning something like a flag means that you fear what that flag
represents. The Chinese have to censor a lot of information because
they fear it. The Communist party fears losing its power, that is why
they censor and ban certain information.
we don't care why they do it.
only that it hurts fedora there.
-sv
9:56 p.m.
On Tue, May 19, 2009 at 7:48 PM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
we don't care why they do it.
only that it hurts fedora there.
So let the paid employees at the RedHat offices in China figure it out
on a case by case basis. Seems like the most rational solution to me.
9:59 a.m.
On Tue, May 19, 2009 at 19:30:07 -0700,
Christopher Stone <chris.stone(a)gmail.com> wrote:
I would argue that it depends on the law. I would also argue that
banning something like a flag means that you fear what that flag
represents. The Chinese have to censor a lot of information because
they fear it. The Communist party fears losing its power, that is why
they censor and ban certain information.
It's not like noncommunist countries don't have the same issue. In the US
the Democrat and Republican parties conspire to make it difficult for any third
parties to take hold (which would displace one of the two of them if they
did). The currently in power party in an area will often try to affect changes
to how voting is done in order to help that party. I suspect that the ruling
groups trying to enact policies that keeps them as ruling groups is something
that happens almost everywhere.
10:23 a.m.
alcapcom (alcapcom(a)gmail.com) said:
Unfortunate peoples that live in countries where a _simple_ flag can
give troubles for whatever cause/reason, can remove them all to be
able to use Fedora. But please, don't cut our freedom just to be more
friendly with authoritarian regimes.
The simplest way to make it so that anyone can easily and persistently
remove them is to not ship them by default. Makes it a lot harder to
break that way.
Bill
11:51 a.m.
2009/5/19 Bill Nottingham <notting(a)redhat.com>:
alcapcom (alcapcom(a)gmail.com) said:
> Unfortunate peoples that live in countries where a _simple_ flag can
> give troubles for whatever cause/reason, can remove them all to be
> able to use Fedora. But please, don't cut our freedom just to be more
> friendly with authoritarian regimes.
The simplest way to make it so that anyone can easily and persistently
remove them is to not ship them by default. Makes it a lot harder to
break that way.
It's the simple way, but do we always choice the simple way? ...No we
like freedom and challenges :-)
We just need to continue what we always have do and like I had
expected someone would come with something better that just remove all
flags. Thanks Toshio.
Alphonse
10:45 a.m.
On Mon, 2009-05-18 at 19:32 +0200, Kevin Kofler wrote:
On the other hand, KDE upstream explicitly decided NOT to ban flags,
as they consider banning flags to be a political move and to go
against KDE's principle of political neutrality.
Consider the following statement:
On the other hand, $PROJECT upstream explicitly decided NOT to
ban profanity, as they consider banning profanity to be a
political move and to go against $PROJECT's principle of
political neutrality.
Would people be arguing to ship that project, unmodified, in Fedora?
Try the same statement with s/profanity/sexually explicit images/.
Or anything that offends some people irrationally.
Besides, the KDE position doesn't make any sense -- you either ship (for
example) a Taiwanese flag, or you don't. Either way, you've thrown your
opinion into the ring. Only by _avoiding_ flags altogether do you get to
avoid participating in the political debate, and remain neutral.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
4:53 p.m.
David Woodhouse wrote:
Consider the following statement:
On the other hand, $PROJECT upstream explicitly decided NOT to
ban profanity, as they consider banning profanity to be a
political move and to go against $PROJECT's principle of
political neutrality.
Would people be arguing to ship that project, unmodified, in Fedora?
Hell fucking yeah!
Try the same statement with s/profanity/sexually explicit images/.
Same here, if e.g. KDE started shipping sexual wallpapers, I don't see why
we wouldn't ship them in kdebase-workspace-wallpapers or
kdeartwork-wallpapers. (Now those are not installed by default, but that's
a size issue and unrelated to the content. There are no sexual wallpapers
in them at this time, at least none that I know of.)
I also consider the censorship of screensavers which is now done in
xscreensaver (renaming of tangrams with vulgar or sexual titles, webcollage
not actually being a *web* collage by default to avoid fetching sexual
content) stupid, if it was just me I'd have closed all those complaints as
NOTABUG.
Besides, the KDE position doesn't make any sense -- you either
ship (for
example) a Taiwanese flag, or you don't.
FWIW, KDE ships it.
Kevin Kofler
2:43 p.m.
On Mon, 2009-05-18 at 18:18 +0100, Bastien Nocera wrote:
This should explain the reason why country flags shouldn't show
up in
interfaces:
http://community.livejournal.com/xkbconfig/982.html
(I didn't even read the policy, but I guess it's the same one we had
arguments over in GNOME 6 years ago, and a bit before that in RH
itself).
It could cause problems in Europe, in Asia, and in North America (and
that's just on top of my head).
And the Middle East. The display of certain flags here is can be a
bit...interesting. I understand the desire for pretty icons, but having
the wrong icon show up in front of the wrong person in the school I
teach at could have some very unpleasant effects. (And, yes, we are
running Fedora on our workstations, so this isn't a completely
theoretical problem)
So, please, leave the flag icons out of the main packages.
Thanks,
Jonathan
3:31 a.m.
On Tue, May 19, 2009 at 02:28, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Jonathan Dieter wrote:
> On Mon, 2009-05-18 at 18:18 +0100, Bastien Nocera wrote:
>> It could cause problems in Europe, in Asia, and in North America (and
>> that's just on top of my head).
>
> And the Middle East.
I really can't see how this can be a problem at all... :-/
Doesn't the UN maintain a list of officially recognized countries ? If
so, we can just use those, and if someone complains, it's not a Fedora
issue but a UN issue. Any trouble with countries recognized in Fedora
will have to be raised to the UN.
This way, we rely on an official organization, we can use pretty
flags, and everyone is happy (or has to be, I mean, are there some
countries who don't recognize the authority of UN ?)
----------
Mathieu Bridon (bochecha)
11:13 a.m.
On Tue, 2009-05-19 at 10:31 +0200, Mathieu Bridon (bochecha) wrote:
(or has to be, I mean, are there some
countries who don't recognize the authority of UN ?)
Plenty.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:50 p.m.
On Mo Mai 18 2009, Kevin Fenzi wrote:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Why is this a policy and not some packaging guideline. It clearly contains
packaging instructions:
| flag images must be placed in an -flags subpackage. The -flags subpackage
| cannot be Required by the main package.
Also this is something that should probably be checked at review time, which
also makes it better suited in the review guidelines.
Additionally the visibility of this page is pretty low, it is not linked from
any other page. There is only a redirection from probably Tom Callaways
proposal page:
https://fedoraproject.org/wiki/Special:WhatLinksHere/Package_Maintainers_...
And I agree that the title of the page is badly chosen, because it is not
about flags regarding package maintainers. I also assumed some boolean flag,
e.g. like the CVS request flag in bugzilla.
Regards
Till
11:39 a.m.
On 18.5.2009 23:50, Till Maas wrote:
On Mo Mai 18 2009, Kevin Fenzi wrote:
> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in
> Fedora was approved.
>
> Due to an oversight, this policy was not announced here. ;(
Why is this a policy and not some packaging guideline. It clearly contains
packaging instructions:
| flag images must be placed in an -flags subpackage. The -flags subpackage
| cannot be Required by the main package.
Also this is something that should probably be checked at review time, which
also makes it better suited in the review guidelines.
Additionally the visibility of this page is pretty low, it is not linked from
any other page. There is only a redirection from probably Tom Callaways
proposal page:
https://fedoraproject.org/wiki/Special:WhatLinksHere/Package_Maintainers_...
Yes, this was the reason why I brought this up on #fedora-devel (and I'm
sorry that it led to such a flame) to spot as I was not even sure
whether it is still a proposal or already approved policy.
Please turn this discussion back to two questions:
1) What should be the page name?
2) Where should it be moved to and from what pages linked so that people
do not miss it?
Thanks,
Milos
12:34 p.m.
Milos Jakubicek wrote:
Please turn this discussion back to two questions:
1) What should be the page name?
So just in case this can of worms isn't big enough already, it might be
worth changing it to be a more generic "political arguments we don't
want to get involved in" policy.
Specifically, geolocation seems to be the free software buzzword for
2009, and there are a bunch of Summer of Code projects in GNOME and
elsewhere involving location and mapping. Maps pose a similar set of
problems to flags; eg, if you ship a map claiming that Northern Cyprus
is a separate territory from Cyprus then Greece gets pissed off, and if
you ship a map saying that it isn't, then Turkey gets pissed off. (As I
understand it, the Cypriots themselves mostly just wish that Greece and
Turkey would piss off.) And even if you only use maps that don't
indicate political boundaries, there are still disputes over the names
of certain international geographical features (such as whether the body
of water separating Iran from Saudi Arabia is "the Persian Gulf" or "the
Arabian Gulf").
All the free-software map stuff I've seen uses openstreetmap.org,
meaning (a) we probably wouldn't actually be *shipping* maps, just
providing the ability to cause them to be downloaded (which may or may
not matter to us), and (b) we might be able to say "OpenStreetMap is
aware of these issues and is trying to work through them in a reasonable
manner (http://wiki.openstreetmap.org/wiki/Disputes) so we defer to
them" (though we still might feel the need to warn users that the
software might, under some circumstances, download maps that offend them).
-- Dan
3:42 p.m.
On Di Mai 19 2009, Milos Jakubicek wrote:
1) What should be the page name?
Political Flags Guideline maybe.
2) Where should it be moved to and from what pages linked so that
people
do not miss it?
It should be included in the Review Guidelines (a SHOULD check item) and
linked in the Packaging Guidelines.
Btw. also some flag removal SIG would be nice, consisting of people who will
create and maintain necessary patches, if there are any needed.
Regards
Till
5:18 p.m.
Milos Jakubicek wrote:
Please turn this discussion back to two questions:
1) What should be the page name?
Fedora Political Correctness Policies.
Let's be honest about what this is. Everyone already knows to loathe
"PC", right? ;-)
I'm inclined to agree with Julian Sikorski. Let's stick to requiring
adherence to U.S. law (because we have to, not because it's in any sense
"better"), and for the rest, Patches Thoughtfully Considered.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Here endeth the rant... which I realize is not likely to Win Friends or
Influence People, especially the person to whom it was directed.
-- Charles Wilson (generalized)
3:29 p.m.
On Mon, 2009-05-18 at 09:09 -0600, Kevin Fenzi wrote:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Please see:
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
and direct any comments to FESCo in a ticket or via the devel list.
I can see both sides of the argument that has proceeded from this
policy, but as a data point:
if my personal inclinations are any indication, I would say this policy
will likely have a freezing effect on contributions to Fedora if fully
adopted. I do intend to get involved in packaging a few things for
Fedora in future, but I certainly don't intend to go to the trouble of
carrying patches to remove flags for eternity, so I would just not
consider packaging any software which included proscribed images (and
would immediately orphan any package I maintained if any proscribed
images were added to it, or if someone pointed out that it had some that
I'd missed).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:59 p.m.
On Mon, May 18, 2009 at 11:09 AM, Kevin Fenzi wrote:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Please see:
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
and direct any comments to FESCo in a ticket or via the devel list.
Thanks, and sorry for the oversight. ;(
I have a question:
Suppose there is an application that I want to package that contains
the Brazilian flag only and no other flags. Afaik, the Brazilian flag
is not illegal in any country in the world. Do I still have to make a
subpackage for this one flag?
Orcan
4:08 p.m.
On Tue, 2009-05-19 at 16:59 -0400, Orcan Ogetbil wrote:
I have a question:
Suppose there is an application that I want to package that contains
the Brazilian flag only and no other flags. Afaik, the Brazilian flag
is not illegal in any country in the world. Do I still have to make a
subpackage for this one flag?
Yes you would. The only way to be "neutral" is to treat all flags the
same. Any different treatment would amount to preferential treatment
which is exactly what we're trying to avoid.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:21 p.m.
On Tue, May 19, 2009 at 5:08 PM, Jesse Keating wrote:
On Tue, 2009-05-19 at 16:59 -0400, Orcan Ogetbil wrote:
>
> I have a question:
>
> Suppose there is an application that I want to package that contains
> the Brazilian flag only and no other flags. Afaik, the Brazilian flag
> is not illegal in any country in the world. Do I still have to make a
> subpackage for this one flag?
Yes you would. The only way to be "neutral" is to treat all flags the
same. Any different treatment would amount to preferential treatment
which is exactly what we're trying to avoid.
Wouldn't it be better if we apply this policy only to those packages
that contain "unsafe" flags? I mean, if the tarball contains an
"unsafe" flag, make a flags subpackage with all the flags. On the
other hand, if all the flags in the tarball are "safe" as in my above
example, I don't see the rationale for spending the time and the
effort of creating a subpackage.
Orcan
5:31 p.m.
On Tue, 2009-05-19 at 18:21 -0400, Orcan Ogetbil wrote:
Wouldn't it be better if we apply this policy only to those
packages
that contain "unsafe" flags? I mean, if the tarball contains an
"unsafe" flag, make a flags subpackage with all the flags. On the
other hand, if all the flags in the tarball are "safe" as in my above
example, I don't see the rationale for spending the time and the
effort of creating a subpackage.
That's not a terrible stance to take, until you have a package that
contains all the flags except for say Tibet. Plus you then have to try
and keep a running list of "unsafe" flags, and make sure the package set
is kept up to date with those unsafe removals. In my experience, such
efforts fail.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:10 p.m.
On 05/19/2009 01:59 PM, Orcan Ogetbil wrote:
I have a question:
Suppose there is an application that I want to package that contains
the Brazilian flag only and no other flags. Afaik, the Brazilian flag
is not illegal in any country in the world. Do I still have to make a
subpackage for this one flag?
According to policy, yes. If this wasn't the case then the argument
that this policy is neutral goes out the window as it is only applying
to flags that are in dispute by some countries.
-Toshio
2:20 a.m.
On 05/18/2009 05:09 PM, Kevin Fenzi wrote:
In FESCo's 2009-03-28 meeting a policy on Flag usage for packages
in
Fedora was approved.
Due to an oversight, this policy was not announced here. ;(
Please see:
https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
and direct any comments to FESCo in a ticket or via the devel list.
Could we have the FESCO meeting IRC log please.
thanks
3:32 a.m.
On Wed, May 20, 2009 at 09:20:36AM +0200, Denis Leroy wrote:
On 05/18/2009 05:09 PM, Kevin Fenzi wrote:
> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in
> Fedora was approved.
>
> Due to an oversight, this policy was not announced here. ;(
>
> Please see:
>
> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
>
> and direct any comments to FESCo in a ticket or via the devel list.
Could we have the FESCO meeting IRC log please.
It would appear to be originally discussed here:
http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-20.html
where some concerns (including FreeCiv, in fact) were raised, then it
was approved here:
http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-27.html
Ewan
4:08 a.m.
On 05/20/2009 10:32 AM, Ewan Mac Mahon wrote:
On Wed, May 20, 2009 at 09:20:36AM +0200, Denis Leroy wrote:
> On 05/18/2009 05:09 PM, Kevin Fenzi wrote:
>> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in
>> Fedora was approved.
>>
>> Due to an oversight, this policy was not announced here. ;(
>>
>> Please see:
>>
>> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
>>
>> and direct any comments to FESCo in a ticket or via the devel list.
> Could we have the FESCO meeting IRC log please.
>
It would appear to be originally discussed here:
http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-20.html
where some concerns (including FreeCiv, in fact) were raised, then it
was approved here:
http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-27.html
Thanks Ewan,
To summarize the votes:
Dennis Gilmore: +1
David Woodhouse: +1
Bill Nottingham: +1
Jon Stanley: +1
Dan Horak: +1
Kevin Fenzi: +1
The logs include some pearls, like this one:
nirik:ok. I'm unclear what problem this is solving off hand...
jds2001: So reading this, it appears that this came from legal. I'm fine
with this policy.
nirik: ok, if it's legal I'm fine with it...
Nobody is even questioning whether the policy is worth the effort, since
people think this is mandated by Legal. No debate about the proposal
consequences and impact over Fedora packagers. No clear definition about
"there are some flags we can't ship to certain places" and what that
actually means technically. What, you're going to block download
requests coming from the PRC ? What about mirrors ? No debate about how
the RPM split has zero impact over this anyways, and how the
"substantively essential" clause bypasses this also. Not even an attempt
to identify the list of affected packages.
Of those 6, only 2 commented on this thread, and only 1 admitted this
could have been communicated/handled better (and he gets my respect). I
can only fear the other 4 do not read this mailing list.
Frankly, this is the worst FeSCo we have had in years, and I'd like
those people to resign immediately from FeSCo and early elections to
take place.
6:27 a.m.
On Wed, May 20, 2009 at 11:08:09AM +0200, Denis Leroy wrote:
To summarize the votes:
Dennis Gilmore: +1
David Woodhouse: +1
Bill Nottingham: +1
Jon Stanley: +1
Dan Horak: +1
Kevin Fenzi: +1
The logs include some pearls, like this one:
nirik:ok. I'm unclear what problem this is solving off hand...
jds2001: So reading this, it appears that this came from legal. I'm fine
with this policy.
nirik: ok, if it's legal I'm fine with it...
Nobody is even questioning whether the policy is worth the effort, since
people think this is mandated by Legal. No debate about the proposal
consequences and impact over Fedora packagers. No clear definition about
"there are some flags we can't ship to certain places" and what that
actually means technically. What, you're going to block download
requests coming from the PRC ? What about mirrors ? No debate about how
the RPM split has zero impact over this anyways, and how the
"substantively essential" clause bypasses this also. Not even an attempt
to identify the list of affected packages.
Of those 6, only 2 commented on this thread, and only 1 admitted this
could have been communicated/handled better (and he gets my respect). I
can only fear the other 4 do not read this mailing list.
Frankly, this is the worst FeSCo we have had in years, and I'd like
those people to resign immediately from FeSCo and early elections to
take place.
I suggest you run for FESCo instead. While you may like for those 6 people to
resign, I doubt they will. The election happens rather soon, so you have every
opportunity to become elected yourself.
josh
8:57 a.m.
Denis Leroy (denis(a)poolshark.org) said:
To summarize the votes:
Dennis Gilmore: +1
David Woodhouse: +1
Bill Nottingham: +1
Jon Stanley: +1
Dan Horak: +1
Kevin Fenzi: +1
...
Nobody is even questioning whether the policy is worth the effort,
since
people think this is mandated by Legal.
Well, if you want a longer version of my opinion...
There are places where the use of certain flags is verboten; in this case,
the use & distribution of Fedora would be verboten if it prominently
used them.
One of our Fedora goals (stated very clearly, see Overview on the wiki) is
to be usable and redistributable *by ALL*. Now, we don't always succeed here;
take, for example, countries where we're unable to distribute to because
of US restrictions (such as Iran, Cuba, etc.) However, we should certainly
strive towards this goal.
By making this change, we allow people in China, or similarly restricted
locales, to be able to use & contribute to Fedora in a way that's safer
and more legal for them. (As to the question whether it's enough for there;
given the preexisting example of something like Red Hat Linux in that
locale that had a 'no flags' policy, by first glance it is enough.)
Is it catering to paranoia of a particular government? Yes. (So are
the T-6 restriction, FWIW.) Is it annoying? Yes. However, changing the
scope of various governments is fairly out of scope of Fedora; let's stick
to what we can change.
It comes down to a tradeoff; it's essentially a pragmatic decision. Are the
gains by making it acceptable in China (or similar locales) worth the effort in
changing/removing some small number of packages? Given the benefits in
opening up the community to 1/6 of the planet's population, and the fact
that in most all cases, the flags aren't a crucial portion of the
functionality *of the project* that is exposed to users, I think so.
Other restrictions in other locales can be handled as need be. For example,
the costs in removing encryption to satisfy some theoretical edict from
a non-US government *wouldn't* be worth the trade-off, as that's a core
functionality that affects pretty much all of our users.
If you want me to resign over making that choice, I'm afraid you'll be
disappointed. But you're certainly welcome to run for a seat and vote
in the next election.
Bill
9:49 a.m.
On 05/20/2009 06:57 AM, Bill Nottingham wrote:
(As to the question whether it's enough for there;
given the preexisting example of something like Red Hat Linux in that
locale that had a 'no flags' policy, by first glance it is enough.)
Part of the problem here is that the current policy is not a "no flags"
policy. Flags are allowed into the distribution and they're allowed
into the distribution in packages unmarked as containing flags. From
the comments given in the first FESCo ticket, it appears that the
ability to make exceptions like that was a part of the reason that some
FESCo members voted for the policy.
In the original ticket comments, I asked that more information about
what problems were trying to be solved be put into the policy but that
wasn't done. There's no mention in the policy about the goal of not
shipping flags. Without an understanding of the goal, there's no way to
see that the current policy makes more work for packagers without
actually letting us ship to flag banning countries.
-Toshio
1:57 p.m.
On Wed, May 20, 2009 at 09:57:17AM -0400, Bill Nottingham wrote:
Well, if you want a longer version of my opinion...
I think that such explanation is clearly missing, and i also think that
it should be expanded and explicited by the board such that Fedora
contributors know what are the practical goals. So far, the only
rule I knew was about US laws, your opinion (which is very reasonable,
in my opinion) goes much further, which is certainly good, but should
be 'officially' said.
One of our Fedora goals (stated very clearly, see Overview on the
wiki) is
to be usable and redistributable *by ALL*. Now, we don't always succeed here;
take, for example, countries where we're unable to distribute to because
of US restrictions (such as Iran, Cuba, etc.)
What does that exactly mean? Are the Fedora mirrors unreachable from
those countries?
However, we should certainly strive towards this goal.
By making this change, we allow people in China, or similarly restricted
locales, to be able to use & contribute to Fedora in a way that's safer
and more legal for them. (As to the question whether it's enough for there;
given the preexisting example of something like Red Hat Linux in that
locale that had a 'no flags' policy, by first glance it is enough.)
Right, but it also should be more openly assessed. If some countries
are a feasible goal for Fedora compliance, and it is known, people can
come with their knowledge of the country law and help doing more
guidelines to comply to te country law.
It comes down to a tradeoff; it's essentially a pragmatic
decision. Are the
gains by making it acceptable in China (or similar locales) worth the effort in
changing/removing some small number of packages? Given the benefits in
opening up the community to 1/6 of the planet's population, and the fact
that in most all cases, the flags aren't a crucial portion of the
functionality *of the project* that is exposed to users, I think so.
Once again, no problem with that, but it should be openly said somewhere
explicitely, that Fedora should abide to chinese laws in addition to
US laws. And it is certainly worth noting which countries are known to
be ok or not ok with fedora.
Other restrictions in other locales can be handled as need be. For
example,
the costs in removing encryption to satisfy some theoretical edict from
a non-US government *wouldn't* be worth the trade-off, as that's a core
functionality that affects pretty much all of our users.
Maybe it could also be said somewhere.
--
Pat
2:46 p.m.
Patrice Dumas wrote:
On Wed, May 20, 2009 at 09:57:17AM -0400, Bill Nottingham wrote:
> One of our Fedora goals (stated very clearly, see Overview on the wiki)
> is to be usable and redistributable *by ALL*. Now, we don't always
> succeed here; take, for example, countries where we're unable to
> distribute to because of US restrictions (such as Iran, Cuba, etc.)
What does that exactly mean? Are the Fedora mirrors unreachable from
those countries?
No. At least people from Iran have no trouble getting Fedora at all AFAICT,
and there's hardly any enforcement of export control. They were banned from
using the official FreeMedia project, but online downloads are pretty much
impossible to police, most if not all mirrors are wide open to Iran.
Kevin Kofler
3:52 p.m.
On Wed, 2009-05-20 at 20:57 +0200, Patrice Dumas wrote:
What does that exactly mean? Are the Fedora mirrors unreachable from
those countries?
No, but it would be illegal for the Fedora project to actively try to
distribute into those countries. The mirrors are supposed to put up a
blurb about not downloading if you're in one of those countries, and/or
blocking IPs from those areas. It's not easily policable, but it is
easy to notice the project entering into any kind of business
arrangement or actively helping to distribute into those countries.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:02 p.m.
On Wed, 2009-05-20 at 13:52 -0700, Jesse Keating wrote:
On Wed, 2009-05-20 at 20:57 +0200, Patrice Dumas wrote:
> What does that exactly mean? Are the Fedora mirrors unreachable from
> those countries?
No, but it would be illegal for the Fedora project to actively try to
distribute into those countries. The mirrors are supposed to put up a
blurb about not downloading if you're in one of those countries, and/or
blocking IPs from those areas. It's not easily policable, but it is
easy to notice the project entering into any kind of business
arrangement or actively helping to distribute into those countries.
FWIW, the concept of introducing a policy that "we will adjust the
Fedora project and product to enable it to be distributed in China" is a
troubling one. There are other, well-known cases of prominent tech
companies - Yahoo! China is the obvious example - doing very problematic
things to make the Chinese government happy and hence be 'kosher' for
distribution / promotion etc in China. I'm not sure that's a road we
want to start down.
I'm fairly sure that, if it actually happened, Fedora wouldn't do
anything really ethically dubious just to continue being distributable
in China. However, if it came to that, we'd then have wasted all this
effort footling around with flags...
I think we need a broader assessment of the overall implications of such
a policy before jumping in to it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:51 p.m.
On 05/20/2009 03:57 PM, Bill Nottingham wrote:
There are places where the use of certain flags is verboten; in this
case,
the use& distribution of Fedora would be verboten if it prominently
used them.
Right, we all know that, although it is not a problem *today* (as in,
it's blocking F-11). But I don't see how this is related to Spot's
proposal.
Promoting Fedora in China is a worthy goal of course. Now if we decide
to tackle that challenge today, for whatever reason, and we lock up our
brightest minds in a room and ask them to come out with a plan for that
specific purpose, do you think they'll come out with a policy about
isolating flags in subpackages ? No, they'll most likely come up with
some grand master plan about creating a community of Chinese Fedora
enthusiasts, creating their own SIG and PRC Fedora spin (I don't
necessarily mean official SIG or spins), which most likely will
black-list some packages, alter the default install, i18n params and
comps files, and possibly, on a case-by-case basis, ask some packagers
to split some packages in part to make their work possible. That's the
way to go, and Fedora keeps a completely neutral stance in this. Any
international community can do the same, for whatever political agenda
they may have. That's the beauty of FOSS.
Or maybe their plan will be to create an "International" Fedora spin (or
call it "Export", or "Flagless", or ...), which is a flavour of Fedora
minus lots of content considered offending or illegal in a bunch of
countries. Now of course, you need volunteers to work that spin. Such
that, if someone complains about some offending flag, you can answer
"Why, thank you for raising this issue! We are precisely looking for
volunteers to help us create your own special flavour of Fedora!".
Now, back to Spot's proposal. It does not address any sort of focused
and pragmatic problem we have today. Want Fedora to be <country
X>-friendly ? Great, but first start by designing grand master plan
above. Moving US, French and German flags into a bunch of secret
subpackages doesn't buy you anything.
2:45 p.m.
On Wed, May 20, 2009 at 6:57 AM, Bill Nottingham <notting(a)redhat.com> wrote:
Is it catering to paranoia of a particular government? Yes. (So are
the T-6 restriction, FWIW.) Is it annoying? Yes. However, changing the
scope of various governments is fairly out of scope of Fedora; let's stick
to what we can change.
What are the T-6 restrictions? A google search only came up with this thread.
I'm trying to understand your logic, are you saying that if the
Chinese government no longer recognized other languages as being
valid, then we would have to remove all languages from Fedora? Is
that not the exact same logic you are applying to flags?
It comes down to a tradeoff; it's essentially a pragmatic decision. Are the
gains by making it acceptable in China (or similar locales) worth the effort in
changing/removing some small number of packages? Given the benefits in
opening up the community to 1/6 of the planet's population, and the fact
that in most all cases, the flags aren't a crucial portion of the
functionality *of the project* that is exposed to users, I think so.
Why not make a China spin? There is a Russia spin in the works is
there not? Why not a China spin? In the China spin we can make all
flags the Chinese flag.
8:31 a.m.
On 05/23/2009 03:45 PM, Christopher Stone wrote:
What are the T-6 restrictions? A google search only came up with this
thread.
There are 6 countries that Fedora cannot be legally exported to (as a
result of US export restrictions):
Cuba, Iran, Iraq, North Korea, Sudan and Syria
These are known as the "T-6" countries. No individual associated with
the Fedora project (or mirror site) should provide Fedora software to
anyone in those countries, even if they are not in the US.
Here's the full legal paragraph:
"Because Fedora software contains encryption technology, Fedora software
and technical information is subject to the U.S. Export Administration
Regulations and other U.S. and foreign law, and may not be exported or
re-exported to certain countries (currently Cuba, Iran, Iraq, North
Korea, Sudan and Syria) or to persons or entities prohibited from
receiving U.S. exports (including those (a) on the Bureau of Industry
and Security Denied Parties List or Entity List, (b) on the Office of
Foreign Assets Control list of Specially Designated Nationals and
Blocked Persons, and (c) involved with missile technology or nuclear,
chemical or biological weapons). You may not download Fedora software or
technical information if you are located in one of these countries, or
otherwise affected by these restrictions. You may not provide Fedora
software or technical information to individuals or entities located in
one of these countries or otherwise affected by these restrictions. You
are also responsible for compliance with foreign law requirements
applicable to the import and use of Fedora software and technical
information."
Tom "spot" Callaway, Fedora Legal
9:09 a.m.
New subject: export policy, was Re: Package Maintainers Flags policy
On Tue, 26 May 2009, Tom "spot" Callaway wrote:
Though I am also not a lawyer, I did look into things, being upstream
for openswan and an author of a book containing crypto, a rather crypto
heavy application and book...
There are 6 countries that Fedora cannot be legally exported to (as
a
result of US export restrictions):
Cuba, Iran, Iraq, North Korea, Sudan and Syria
I think technically, this restriction only applies on the export of the
software out of the US. For those outside the US, US law/doctrine does
not apply (even though the US claims it does). Rather, for most Western
countries, implementation of the Wassenaar Agreement in local law applies,
where some countries have extended the export restrictios as set forth in
the Wassenaar Agreement. In Europe, there is also the European Union
Dual-Use Export laws.
These are known as the "T-6" countries. No individual
associated with
the Fedora project (or mirror site) should provide Fedora software to
anyone in those countries, even if they are not in the US.
This is again US doctrine. It becomes even stranger as in my case, Fedora
imports openswan from The Netherlands, and then tells me I could not obtain
my own GPL licensed code to do what is legal within my country? Though in
this case, there is a large overlap of implementation of the Wassenaar
Agreement.
"Because Fedora software contains encryption technology, Fedora
software
and technical information is subject to the U.S. Export Administration
Regulations and other U.S. and foreign law, and may not be exported or
re-exported to certain countries (currently Cuba, Iran, Iraq, North
Korea, Sudan and Syria)
See above. Note that the Wassenaar Agreement excludes software that is
in the "public domain", eg free/open source software.
or to persons or entities prohibited from
receiving U.S. exports (including those (a) on the Bureau of Industry
and Security Denied Parties List or Entity List, (b) on the Office of
Foreign Assets Control list of Specially Designated Nationals and
Blocked Persons, and (c) involved with missile technology or nuclear,
chemical or biological weapons).
This is technically a violation of GPL, and could mean that
anyone distributing Fedora with those restrictions has lost their rights
to use and/or distribute the GPL software contained within Fedora.
You may not download Fedora software or
technical information if you are located in one of these countries, or
otherwise affected by these restrictions. You may not provide Fedora
software or technical information to individuals or entities located in
one of these countries or otherwise affected by these restrictions. You
are also responsible for compliance with foreign law requirements
applicable to the import and use of Fedora software and technical
information."
This is just boilerplate for more "US law applies to non-US citizens
because we say so" doctrine. Though it does not apply to non-US citizens,
there is a risk. I formulated it like this in the Openswan book:
Unrecognised international claims
Certain countries claim jurisdiction even outside their national
borders. Most notably, France claims the right to “regulate information
on foreign servers”, Italy assumes jurisdiction over sites "directed to
an Italian audience" and the US reserve the right to prosecute "offenses
against American interests" according to US law, irrespective of where
they take place.
You may want to consider the possibility that you can be sued or
prosecuted in another country. Additionally, if you are physically in
a country other than the Netherlands when you download our software,
you are probably subject to that country's jurisdiction anyway. And if
your download happens to pass a router under US control (say in Guam),
the US might make additional claims to rights for restriction of your
packets or even your person.
Note that this text was written a few years ago. For an updated situation,
one should probably consult their local lawyer, please the updates from
http://www.wassenaar.org/
Paul
9:54 a.m.
New subject: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 07:39 PM, Paul Wouters wrote:
This is technically a violation of GPL, and could mean that
anyone distributing Fedora with those restrictions has lost their rights
to use and/or distribute the GPL software contained within Fedora.here
they take place.
FSF doesn't seem to think so
http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF
Rahul
10:30 a.m.
New subject: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 10:09 AM, Paul Wouters wrote:
See above. Note that the Wassenaar Agreement excludes software that
is
in the "public domain", eg free/open source software.
This is not correct. "Public Domain" has a very specific legal meaning,
and 99% of FOSS does _not_ meet it. Public Domain is when the copyright
holder has explicitly abandoned his/her/its copyright on the work and
placed it into the Public Domain. (Note: In some countries, such as
Germany, this is impossible)
> You may not download Fedora software or
> technical information if you are located in one of these countries, or
> otherwise affected by these restrictions. You may not provide Fedora
> software or technical information to individuals or entities located in
> one of these countries or otherwise affected by these restrictions. You
> are also responsible for compliance with foreign law requirements
> applicable to the import and use of Fedora software and technical
> information."
This is just boilerplate for more "US law applies to non-US citizens
because we say so" doctrine.
Keeping in mind the complexities of US export law are many, people who
are directly affiliated with a US company are still required to follow
US export law, or the US company can face serious legal risks (even if
the non-US citizen who violates US export laws does not directly face
any risk, or a minimized risk). In such a scenario, the individual could
be perceived to have been acting as an agent of Fedora (Red Hat), making
Red Hat liable. The penalties for export violation are steep and
serious, which is why all Fedora contributors are required to abide by
the export policies.
~spot
11:13 a.m.
New subject: export policy, was Re: Package Maintainers Flags policy
The penalties for export violation are steep and
serious, which is why all Fedora contributors are required to abide by
the export policies.
Maybe this should be mentioned in the CLA ? We (Fedora contributors)
have to sign it. Specifying it there would make it more widely known,
and could provide a way to make contributors respect it (as they
agreed and signed the CLA).
Unless I miss it, it is not mentioned:
https://fedoraproject.org/wiki/Legal/Licenses/CLA
Regards,
----------
Mathieu Bridon (bochecha)
11:35 a.m.
New subject: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 12:13 PM, Mathieu Bridon (bochecha) wrote:
> The penalties for export violation are steep and
> serious, which is why all Fedora contributors are required to abide by
> the export policies.
Maybe this should be mentioned in the CLA ? We (Fedora contributors)
have to sign it. Specifying it there would make it more widely known,
and could provide a way to make contributors respect it (as they
agreed and signed the CLA).
Unless I miss it, it is not mentioned:
https://fedoraproject.org/wiki/Legal/Licenses/CLA
Nope. We'll definitely take that into consideration as we rework the CLA.
Historically, we've only highlighted the export details onto people who
are likely to redistribute Fedora as part of their normal activities
(FreeMedia, Mirrors), but there is no reason we can't make it clear to
everyone who signs the CLA.
~spot
1:39 p.m.
New subject: export policy, was Re: Package Maintainers Flags policy
Once upon a time, Tom spot Callaway <tcallawa(a)redhat.com> said:
Historically, we've only highlighted the export details onto
people who
are likely to redistribute Fedora as part of their normal activities
(FreeMedia, Mirrors), but there is no reason we can't make it clear to
everyone who signs the CLA.
IIRC mirrors are not required to sign the CLA (I did, but that was
because I was working towards being a packager as well).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:49 p.m.
New subject: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 02:39 PM, Chris Adams wrote:
Once upon a time, Tom spot Callaway <tcallawa(a)redhat.com>
said:
> Historically, we've only highlighted the export details onto people who
> are likely to redistribute Fedora as part of their normal activities
> (FreeMedia, Mirrors), but there is no reason we can't make it clear to
> everyone who signs the CLA.
IIRC mirrors are not required to sign the CLA (I did, but that was
because I was working towards being a packager as well).
Yes, but they are presented with the export restrictions.
~spot
8:19 p.m.
New subject: export policy, was Re: Package Maintainers Flags policy
| From: Tom "spot" Callaway <tcallawa(a)redhat.com>
| On 05/26/2009 10:09 AM, Paul Wouters wrote:
| > See above. Note that the Wassenaar Agreement excludes software that is
| > in the "public domain", eg free/open source software.
|
| This is not correct. "Public Domain" has a very specific legal meaning,
| and 99% of FOSS does _not_ meet it. Public Domain is when the copyright
| holder has explicitly abandoned his/her/its copyright on the work and
| placed it into the Public Domain. (Note: In some countries, such as
| Germany, this is impossible)
Tom is right about the meaning of "public domain" in US law. This is
not the meaning in the Wassenaar Agreement.
9:19 a.m.
New subject: export policy, was Re: Package Maintainers Flags policy
On 05/26/2009 09:19 PM, D. Hugh Redelmeier wrote:
| From: Tom "spot" Callaway <tcallawa(a)redhat.com>
| On 05/26/2009 10:09 AM, Paul Wouters wrote:
| > See above. Note that the Wassenaar Agreement excludes software that is
| > in the "public domain", eg free/open source software.
|
| This is not correct. "Public Domain" has a very specific legal meaning,
| and 99% of FOSS does _not_ meet it. Public Domain is when the copyright
| holder has explicitly abandoned his/her/its copyright on the work and
| placed it into the Public Domain. (Note: In some countries, such as
| Germany, this is impossible)
Tom is right about the meaning of "public domain" in US law. This is
not the meaning in the Wassenaar Agreement.
Hmm, I dug this out of the WA, and Hugh is right:
"In the public domain"
This means "technology" or "software" which has been made available
without
restrictions upon its further dissemination.
Note Copyright restrictions do not remove "technology" or "software"
from being "in the
public domain".
A poor choice of words, especially since the terminology "public domain"
has had a well defined and accepted international legal meaning long
before the WA.
This definition also seems contradictory, as redistribution is not a
right automatically granted, it is only granted as an extension of
copyright.
However, it is noteworthy that Encryption software does not qualify for
this exception in the WA, which is the main reason that Fedora has this
export policy in the first place.
~spot
10:16 a.m.
New subject: export policy, was Re: Package Maintainers Flags policy
On Tue, 26 May 2009, D. Hugh Redelmeier wrote:
| On 05/26/2009 10:09 AM, Paul Wouters wrote:
| > See above. Note that the Wassenaar Agreement excludes software that is
| > in the "public domain", eg free/open source software.
|
| This is not correct. "Public Domain" has a very specific legal meaning,
| and 99% of FOSS does _not_ meet it. Public Domain is when the copyright
| holder has explicitly abandoned his/her/its copyright on the work and
| placed it into the Public Domain. (Note: In some countries, such as
| Germany, this is impossible)
Tom is right about the meaning of "public domain" in US law. This is
not the meaning in the Wassenaar Agreement.
That's right, in the Wassenaar context it is (http://jya.com/wass-au.htm):
"in the public domain" (GTN NTN GSN), as it applies herein, means
"technology" or "software" which has been made available without
restrictions upon its further dissemination (copyright restrictions do
not remove "technology" or "software" from being "in the public
domain")
Note that the US has various restrictions on top of the Wassenaar
Agreement, but those do not apply to me (as upstream)
Paul
11:27 a.m.
On Wed, 20 May 2009 11:08:09 +0200
Denis Leroy <denis(a)poolshark.org> wrote:
Thanks Ewan,
To summarize the votes:
Dennis Gilmore: +1
David Woodhouse: +1
Bill Nottingham: +1
Jon Stanley: +1
Dan Horak: +1
Kevin Fenzi: +1
The logs include some pearls, like this one:
nirik:ok. I'm unclear what problem this is solving off hand...
jds2001: So reading this, it appears that this came from legal. I'm
fine with this policy.
nirik: ok, if it's legal I'm fine with it...
Nobody is even questioning whether the policy is worth the effort,
since people think this is mandated by Legal. No debate about the
proposal consequences and impact over Fedora packagers. No clear
definition about "there are some flags we can't ship to certain
places" and what that actually means technically. What, you're going
to block download requests coming from the PRC ? What about mirrors ?
No debate about how the RPM split has zero impact over this anyways,
and how the "substantively essential" clause bypasses this also. Not
even an attempt to identify the list of affected packages.
I agree that we could come up with a better policy.
I think the number of packages is pretty limited here. I know of about
5 so far. Unfortunately I don't know an easy way to identify any beyond
that. Do you?
The policy "came from" legal concerns. Thus I think it's a a good idea
to address it before we have to scramble to do so. I thought it was a
better policy than 'no flags', but perhaps it's not.
My understanding is that we split out things to make it easier for
places that dislike flags to filter or otherwise block them. I agree
that base packages that have essential flags wouldn't be identified
then.
Of those 6, only 2 commented on this thread, and only 1 admitted this
could have been communicated/handled better (and he gets my respect).
I can only fear the other 4 do not read this mailing list.
I do. I however have a day job and figure I can spend my time more
productively for Fedora than responding to each of the 278 posts in
this thread. Many of which are not constructive or useful.
Out of those 278 posts, there have been I think about 4 counter
proposals. For those that were constructive and offered them up I thank
you. Personally I think this thread could have been about 10 posts:
- Point out the problems with the passed policy (Which I admit freely it
has). (one or two posts. Or even the paragraph above does that).
- Offer some specific counter proposal or changes to the existing
policy to make it more clear or better suit fedora's goals.
- Someone could have figured out a list of affected packages.
(How many of these affected packages do you maintain?)
The "fesco is lazy and should resign" or "I just hate this" or
"Here's specific examples of flags" I don't find productive or useful.
The policy is not good, we should address it and get one thats better.
We will.
Frankly, this is the worst FeSCo we have had in years, and I'd
like
those people to resign immediately from FeSCo and early elections to
take place.
Elections are taking place soon. Feel free to run.
I note that the majority of the current fesco has served many times
before, so I don't think this is any radical change of elected members.
kevin
12:24 p.m.
Kevin Fenzi wrote:
On Wed, 20 May 2009 11:08:09 +0200
Denis Leroy <denis(a)poolshark.org> wrote:
> Thanks Ewan,
>
> To summarize the votes:
>
> Dennis Gilmore: +1
> David Woodhouse: +1
> Bill Nottingham: +1
> Jon Stanley: +1
> Dan Horak: +1
> Kevin Fenzi: +1
I agree that we could come up with a better policy.
Yes, tabling this issue and working out a sustainable solution would
have been the appropriate approach. So far, to me, FESCO's decision is a
short-sighted hip-shot, without any foundation nor long term-perspective.
Harmful to FESCO, harmful to Fedora, without providing a solution.
The policy "came from" legal concerns. Thus I think
it's a a good idea
to address it before we have to scramble to do so. I thought it was a
better policy than 'no flags', but perhaps it's not.
Well, I am sure, FESCO will now will initiate the necessary measures to
initiate the "youth protection" certification processes, whose absence
so far legally threads Fedora vendors/distributors from different
countries around the globe?
The "fesco is lazy and should resign" or "I just hate
this" or
"Here's specific examples of flags" I don't find productive or useful.
The policy is not good, we should address it and get one thats better.
We will.
> Frankly, this is the worst FeSCo we have had in years,
ACK.
Elections are taking place soon. Feel free to run.
Pardom? In
a democracy, the natural consequence of people feeling
dissatisfied with the ruling party, is to vote against them or to
abstain from voting, when feeling "there is no voteable candidate" or
when feeling "voting is useless".
Ralf
12:35 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On 05/20/2009 01:24 PM, Ralf Corsepius wrote:
Well, I am sure, FESCO will now will initiate the necessary measures
to
initiate the "youth protection" certification processes, whose absence
so far legally threads Fedora vendors/distributors from different
countries around the globe?
We actually have this pretty well covered wrt to US laws. :)
~spot
10:08 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
Tom "spot" Callaway wrote:
On 05/20/2009 01:24 PM, Ralf Corsepius wrote:
> Well, I am sure, FESCO will now will initiate the necessary measures to
> initiate the "youth protection" certification processes, whose absence
> so far legally threads Fedora vendors/distributors from different
> countries around the globe?
We actually have this pretty well covered wrt to US laws. :)
We are talking about the "national laws" threating
users/vendors/re-distributors in a particular country.
Wrt. "youth protection", US laws are widely irrelevant. It's similar to
US "alcohol/tobacco/drug laws", "weapon laws", "medication
laws", "car
part regulations". At least in my country (Germany), they are widely
irrelevant.
Relevant wrt. "youth protection" on SW in Germany are computer games.
Very oversimplified, in general, it's illegal in Germany to make
"non-USK-certified/rated" computer games available to people below
certain age, rsp. in some cases, to distribute them at all.
Ralf
11:58 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On Wed, May 20, 2009 at 8:08 PM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
Tom "spot" Callaway wrote:
> On 05/20/2009 01:24 PM, Ralf Corsepius wrote:
>
>> Well, I am sure, FESCO will now will initiate the necessary measures to
>> initiate the "youth protection" certification processes, whose absence
>> so far legally threads Fedora vendors/distributors from different
>> countries around the globe?
>>
>
> We actually have this pretty well covered wrt to US laws. :)
>
We are talking about the "national laws" threating
users/vendors/re-distributors in a particular country.
Wrt. "youth protection", US laws are widely irrelevant. It's similar to US
"alcohol/tobacco/drug laws", "weapon laws", "medication
laws", "car part
regulations". At least in my country (Germany), they are widely irrelevant.
Relevant wrt. "youth protection" on SW in Germany are computer games. Very
oversimplified, in general, it's illegal in Germany to make
"non-USK-certified/rated" computer games available to people below certain
age, rsp. in some cases, to distribute them at all.
Fedora, as a project of a US corporation, is liable for violation of the
laws of the State of North Carolina and of the United States. We're not
liable for violation of the laws of any other jurisdiction... Whether it's
over "protect teh [sic] children!", maps that have Israel on them, or flags.
Do we really want to start excluding content just because it's illegal in
some other jurisdiction? This seems.... slippery.
-Chris
--
Chris Weyl
Ex astris, scientia
12:24 a.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
Chris Weyl wrote:
On Wed, May 20, 2009 at 8:08 PM, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
> Tom "spot" Callaway wrote:
>
>> On 05/20/2009 01:24 PM, Ralf Corsepius wrote:
>>
>>> Well, I am sure, FESCO will now will initiate the necessary measures to
>>> initiate the "youth protection" certification processes, whose
absence
>>> so far legally threads Fedora vendors/distributors from different
>>> countries around the globe?
>>>
>> We actually have this pretty well covered wrt to US laws. :)
>>
> We are talking about the "national laws" threating
> users/vendors/re-distributors in a particular country.
>
> Wrt. "youth protection", US laws are widely irrelevant. It's similar to
US
> "alcohol/tobacco/drug laws", "weapon laws", "medication
laws", "car part
> regulations". At least in my country (Germany), they are widely irrelevant.
>
> Relevant wrt. "youth protection" on SW in Germany are computer games. Very
> oversimplified, in general, it's illegal in Germany to make
> "non-USK-certified/rated" computer games available to people below certain
> age, rsp. in some cases, to distribute them at all.
>
Fedora, as a project of a US corporation, is liable for violation of the
laws of the State of North Carolina and of the United States. We're not
liable for violation of the laws of any other jurisdiction...
ACK.
Whether it's
over "protect teh [sic] children!", maps that have Israel on them, or flags.
ACK, nor Tibet, or Nagorno-Karabakh, Kosovo, FYR of Macedonia, Cuba,
Palestina, just to mention a few other controversial countries ....
Do we really want to start excluding content just because it's
illegal in
some other jurisdiction? This seems.... slippery.
ACK.
I am simply trying to demonstrate the impact of the can of worms Spot,
FESCO and RH-Legal have opened. If they were consequent, they now _will
have to take care_ with this kind of issues, world-wide!
Ralf
1:55 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On 05/21/2009 12:58 AM, Chris Weyl wrote:
Do we really want to start excluding content just because it's
illegal
in some other jurisdiction? This seems.... slippery.
In fact, this was not the intention behind the flags proposal, rather that:
* Use of Flags in Fedora has a history of causing controversy between
groups (political, rather than legal)
* Use of Flags in Fedora may prevent Fedora from being available in some
areas (again, political rather than legal)
If FESCo decides that they are okay with Fedora including all sorts of
flags, there is no legal reason for that decision to be overturned.
~spot, with his Fedora Legal hat on
2:04 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On Thu, 21 May 2009, Tom "spot" Callaway wrote:
* Use of Flags in Fedora has a history of causing controversy
between
groups (political, rather than legal)
* Use of Flags in Fedora may prevent Fedora from being available in some
areas (again, political rather than legal)
Only include flags in the Everything repo? Never on the install media?
Though it seems rather silly to me. Would we also not allow little flags
to show language preferences (eg french canadian vs american english)?
If one people's republic does not like the other people's republic flags,
they can re-spin their own?
Paul
ps. The really interesting question is: If a Fedora DVD image contains a
US flag, can you still burn it? :)
2:28 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
Paul Wouters wrote:
ps. The really interesting question is: If a Fedora DVD image contains a
US flag, can you still burn it? :)
You owe me a new keyboard.
--
in your fear, speak only peace
in your fear, seek only love
-d. bowie
2:30 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On Thu, 21 May 2009, Paul Wouters wrote:
Only include flags in the Everything repo? Never on the install
media?
Though it seems rather silly to me. Would we also not allow little flags
to show language preferences (eg french canadian vs american english)?
If one people's republic does not like the other people's republic flags,
they can re-spin their own?
Paul
ps. The really interesting question is: If a Fedora DVD image contains a
US flag, can you still burn it? :)
I don't know where people have gotten the idea that burning a US flag is
illegal. It's not. It's been found to be protected speech repeatedly.
Defacing a flag is an act of protected speech under the First
Amendment to the United States Constitution, as established in Texas v.
Johnson, 491 U.S. 397 (1989), and reaffirmed in U.S. v. Eichman, 496 U.S.
310 (1990).
It's also off-topic from this thread, I think.
-sv
3:12 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On Thu, May 21, 2009 at 12:30 PM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
On Thu, 21 May 2009, Paul Wouters wrote:
> ps. The really interesting question is: If a Fedora DVD image contains a
> US flag, can you still burn it? :)
>
I don't know where people have gotten the idea that burning a US flag is
illegal. It's not. It's been found to be protected speech repeatedly.
The fact that they have to "re-find" this fact repeatedly is what is
amusing about his statement. I did not get the impression that he was
suggesting that burning a US flag is illegal.
2:36 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On Thu, 2009-05-21 at 15:04 -0400, Paul Wouters wrote:
Only include flags in the Everything repo? Never on the install media?
That gets hard, as there are also the spins we do to consider, and the
fact that you can enable the Everything repo at install time. Also the
contents of the install media change over time as deps change, so it's
something that would have to be constantly monitored.
Though it seems rather silly to me. Would we also not allow little flags
to show language preferences (eg french canadian vs american english)?
That's precisely where we don't want to show flags. A) it's bad UI, and
B) it's rather noticeable.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:04 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On Thu, May 21, 2009 at 12:36 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Thu, 2009-05-21 at 15:04 -0400, Paul Wouters wrote:
> Though it seems rather silly to me. Would we also not allow little flags
> to show language preferences (eg french canadian vs american english)?
That's precisely where we don't want to show flags. A) it's bad UI, and
B) it's rather noticeable.
Ah, excellent! So when are we going to start auditing all packages in
Fedora for "bad UI"?
:)
-Chris
--
Chris Weyl
Ex astris, scientia
1:56 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On 05/21/2009 12:58 AM, Chris Weyl wrote:
Fedora, as a project of a US corporation, is liable for violation of
the
laws of the State of North Carolina and of the United States.
Well, its actually the laws of the State of Delaware, but I digress. ;)
~spot
3:02 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
On Thu, May 21, 2009 at 11:56 AM, Tom "spot" Callaway
<tcallawa(a)redhat.com>wrote:
On 05/21/2009 12:58 AM, Chris Weyl wrote:
> Fedora, as a project of a US corporation, is liable for violation of the
> laws of the State of North Carolina and of the United States.
Well, its actually the laws of the State of Delaware, but I digress. ;)
Man. Is my $work the only corporation left in the US _not_ incorporated in
Delaware?! :)
-Chris
--
Chris Weyl
Ex astris, scientia
2:31 p.m.
New subject: Youth Protection: Was Re: Package Maintainers Flags policy
Chris Weyl wrote:
> Fedora, as a project of a US
corporation, is liable for violation of the
> laws of the State of North Carolina and of the United States. We're not
> liable for violation of the laws of any other jurisdiction...
Maybe not so:
ALL *US* made films, have to be incompliance with EU laws.
If necessary to comply, ratings will be up or down.
To suit EU\ evenindividual member state laws.
IANAL
Frank
--
msn: frankly3d skype: frankly3d
Mailing-List Reply to: Mailing-List
Still Learning, Unicode where possible
1:17 p.m.
On Wed, May 20, 2009 at 07:24:44PM +0200, Ralf Corsepius wrote:
> Elections are taking place soon. Feel free to run.
Pardom? In a democracy, the natural consequence of people feeling
dissatisfied with the ruling party, is to vote against them or to
abstain from voting, when feeling "there is no voteable candidate" or
when feeling "voting is useless".
You are free to vote against candidates. Or not vote for them. Or even not
vote.
But a more effective manner of being able to influence things is to actually
run for office. This is significantly more of an option in Fedora than it is
in true government elections, because the campaign doesn't cost millions of
dollars. All it costs is the candidate's time. They may win, they may not.
But at least they cared enough to try.
Expecting things to change without having actual candidates pushing for that
change is a bit absurd. I'm not sure what anyone would expect to actually
accomplish by not voting and then just criticizing the elected body they didn't
vote for. To truly be part of a community, one needs to participate it the
actual workings of that community.
josh
10:12 p.m.
Josh Boyer wrote:
On Wed, May 20, 2009 at 07:24:44PM +0200, Ralf Corsepius wrote:
>> Elections are taking place soon. Feel free to run.
Expecting things to change without having actual candidates pushing
for that
change is a bit absurd.
Well, telling "your representative" that you are
dissatisfied with him
and that he should do better next time is of no use?
Ralf
5:43 a.m.
On Thu, May 21, 2009 at 05:12:17AM +0200, Ralf Corsepius wrote:
Josh Boyer wrote:
> On Wed, May 20, 2009 at 07:24:44PM +0200, Ralf Corsepius wrote:
>>> Elections are taking place soon. Feel free to run.
> Expecting things to change without having actual candidates pushing for that
> change is a bit absurd.
Well, telling "your representative" that you are dissatisfied with him
and that he should do better next time is of no use?
No, that certainly is of use. And representatives should listen to feedback
on individual issues.
However, if one is dissatisfied with the elected body overall, then changing
the composition of that body through newly elected candidates seems to be the
only way to possibly change that.
Forgive me for picking your particular email to reply to, but a number of
people have expressed that they feel this is 'the worst FESCo in a long time'
and I'm just trying to point out that FESCo is simply composed of people that
cared enough to run for election.
BTW, personaly I disagree with the 'worst FESCo' statement and not because
I'm
on FESCo. There have just been a number of issues this term that actually
require FESCo to do something other than approve Features and Sponsors. It's
been interesting, but overall there has really only been the flags item that
really needs revisiting.
josh
12:26 p.m.
On Wed, May 20, 2009 at 10:27 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
The policy "came from" legal concerns. Thus I think
it's a a good idea
to address it before we have to scramble to do so. I thought it was a
better policy than 'no flags', but perhaps it's not.
s/legal concerns/political concerns/
Right?
--
Jerry James
http://www.jamezone.org/
2:42 p.m.
Kevin Fenzi wrote:
I think the number of packages is pretty limited here. I know of
about
5 so far.
I know of 4 more (which I don't think are the sames you're thinking of –
well, 2 of the 4 are subpackages of the same SRPM, but separate versions of
the flags), plus the icons for preferences-desktop-locale in pretty much
all icon themes (I'm going to write a separate mail on that issue where it
fits better in the thread).
The policy "came from" legal concerns. Thus I think
it's a a good idea
to address it before we have to scramble to do so.
I think we shouldn't unless there's an actual legal issue where Fedora is
based (which happens to be the USA).
I note that the majority of the current fesco has served many times
before, so I don't think this is any radical change of elected members.
That's an issue of lack of alternatives more than anything else. It also was
not really clear in past elections what stand the candidates are taking on
individual issues (hopefully the interview process being tried this time
will help), and it's especially hard to predict what decisions they'll make
on new issues which come up. I'm sorry to say this to you (and it's not
against you personally), but most of us really don't know whom we can
trust.
Kevin Kofler
2:57 p.m.
I wrote:
That's an issue of lack of alternatives more than anything else.
It also
was not really clear in past elections what stand the candidates are
taking on individual issues (hopefully the interview process being tried
this time will help), and it's especially hard to predict what decisions
they'll make on new issues which come up. I'm sorry to say this to you
(and it's not against you personally), but most of us really don't know
whom we can trust.
PS: Oh, and "If you don't know whom to trust, run for office yourself!"
isn't really a satisfying answer. While there should indeed be some people
unhappy with the current FESCo running for office to provide a real
alternative, if everybody runs and only trusts themselves, we end up with
everyone having exactly 1 vote (or rather n "votes" where n is the maximum
rating in the range voting system being used), that won't work at all.
Another issue is that there are many people whom I totally agreed with on
some issues but totally disagreed with on some others in the past.
I really don't know what the best solution for those issues would be. Better
communication of platforms, goals etc.? Forming factions/parties so we
could vote e.g. for KDE SIG? Direct democracy as practiced in Debian? (But
I'm not sure any of those really works, Debian's votes have often been
total chaos, parties probably don't work for such small committees where
there would be just 1 or 2 members of each party, most likely voting for
their own position rather than the official party line more often than not,
better communication probably doesn't solve the whole problem.)
Kevin Kofler
3:19 p.m.
On 05/20/2009 12:57 PM, Kevin Kofler wrote:
Another issue is that there are many people whom I totally agreed
with on
some issues but totally disagreed with on some others in the past.
This one is actually a feature of republican forms of government.
Debating why that is is likely off-topic for Fedora devel. However,
dealing with it is:
No one who is elected by multiple people can represent all of the people
who voted for them all of the time. So the voter has to make a decision:
1) Do you want someone who does what the majority of people think is right?
2) Do you want someone whose judgement you think is sound?
3) Do you want someone who holds the same fundamental values as you do?
4) Do you want someone that you, personally, have influence with?
So, to prepare for the next election, it would be good to get some
questions posted that speak to the core values that the people hold and
to see whether, when they disagree with you, they are doing so with
rational arguments that you can understand even if you don't agree with
them.
-Toshio
3:33 p.m.
On Wed, May 20, 2009 at 01:19:55PM -0700, Toshio Kuratomi wrote:
On 05/20/2009 12:57 PM, Kevin Kofler wrote:
> Another issue is that there are many people whom I totally agreed with on
> some issues but totally disagreed with on some others in the past.
>
This one is actually a feature of republican forms of government.
Debating why that is is likely off-topic for Fedora devel. However,
dealing with it is:
No one who is elected by multiple people can represent all of the people
who voted for them all of the time. So the voter has to make a decision:
1) Do you want someone who does what the majority of people think is right?
2) Do you want someone whose judgement you think is sound?
3) Do you want someone who holds the same fundamental values as you do?
4) Do you want someone that you, personally, have influence with?
So, to prepare for the next election, it would be good to get some
questions posted that speak to the core values that the people hold and
to see whether, when they disagree with you, they are doing so with
rational arguments that you can understand even if you don't agree with
them.
To wit:
http://thorstenl.blogspot.com/2009/05/what-questions-would-you-like-to-as...
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
1:30 a.m.
On 20.05.2009, Kevin Kofler wrote:
I really don't know what the best solution for those issues would
be. Better
communication of platforms, goals etc.? Forming factions/parties so we
could vote e.g. for KDE SIG? Direct democracy as practiced in Debian? (But
I'm not sure any of those really works, Debian's votes have often been
total chaos, parties probably don't work for such small committees where
there would be just 1 or 2 members of each party, most likely voting for
their own position rather than the official party line more often than not,
better communication probably doesn't solve the whole problem.)
I usually try to stay away from threads like this. With that excuse: I
really hope this does not increase bureaucracy. There are hardly any
examples where a bureaucratic/democractic governance model would have had
any real positive impact on open source projects, quite the contrary. When
policies start to matter more than technical questions, you are already
lost.
Personally, I would rather give FESCo more power. Perhaps this could at
least end the shouting contest that Fedora developer mailing list has
become.
Two cents from a Fedora user,
Jukka.
1:44 a.m.
Jukka Ruohonen wrote:
Personally, I would rather give FESCo more power.
Why? They
already have almost "unlimited", almost "almighty" powers.
Perhaps this could at
least end the shouting contest that Fedora developer mailing list has
become.
They are being shouted at, because people do not agree with their
"almighty wisdom".
Ralf
5:45 a.m.
On Thu, May 21, 2009 at 08:44:42AM +0200, Ralf Corsepius wrote:
Jukka Ruohonen wrote:
> Personally, I would rather give FESCo more power.
Why? They already have almost "unlimited", almost "almighty" powers.
This is untrue.
> Perhaps this could at
> least end the shouting contest that Fedora developer mailing list has
> become.
They are being shouted at, because people do not agree with their
"almighty wisdom".
And that's fine. I don't think anyone on FESCo would claim they are almighty
though. Please refrain from being inflammatory.
josh
6:33 a.m.
Josh Boyer wrote:
On Thu, May 21, 2009 at 08:44:42AM +0200, Ralf Corsepius wrote:
> Jukka Ruohonen wrote:
>> Personally, I would rather give FESCo more power.
> Why? They already have almost "unlimited", almost "almighty"
powers.
This is untrue.
Elaborate. What is untrue about this?
The only restrictions imposed to FESCO are
* FPB interfering
* By law
* Them being ignored.
>> Perhaps this could at
>> least end the shouting contest that Fedora developer mailing list has
>> become.
> They are being shouted at, because people do not agree with their
> "almighty wisdom".
And that's fine. I don't think anyone on FESCo would claim they are almighty
though. Please refrain from being inflammatory.
C.f. the rest of this thread.
It clearly demonstrates FESCO's almightiness.
7:34 a.m.
On Thu, May 21, 2009 at 01:33:59PM +0200, Ralf Corsepius wrote:
Josh Boyer wrote:
> On Thu, May 21, 2009 at 08:44:42AM +0200, Ralf Corsepius wrote:
>> Jukka Ruohonen wrote:
>>> Personally, I would rather give FESCo more power.
>> Why? They already have almost "unlimited", almost "almighty"
powers.
>
> This is untrue.
Elaborate. What is untrue about this?
The only restrictions imposed to FESCO are
* FPB interfering
* By law
* Them being ignored.
Funny. All of those are the only restrictions applied to any existing packager
too.
Seems we're on even playing ground then, and FESCo really is an elected body
that is _representative_ of the technical Fedora community.
josh
6:25 a.m.
On Wed, May 20, 2009 at 09:20:36AM +0200, Denis Leroy wrote:
On 05/18/2009 05:09 PM, Kevin Fenzi wrote:
> In FESCo's 2009-03-28 meeting a policy on Flag usage for packages in
> Fedora was approved.
>
> Due to an oversight, this policy was not announced here. ;(
>
> Please see:
>
> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy
>
> and direct any comments to FESCo in a ticket or via the devel list.
Could we have the FESCO meeting IRC log please.
http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-27.html
josh
5455
days inactive
5464
days old
264 comments
62 participants
participants (62)
-
Adam Williamson -
alcapcom -
Aleksandar Kurtakov -
Andrea Musuruane -
Andreas Thienemann -
Andrew Haley -
Arnaud Gomes-do-Vale -
Bastien Nocera -
Bill Crawford -
Bill Nottingham -
Björn Persson -
Bruno Wolff III -
Chris Adams -
Chris Weyl -
Christoph Wickert -
Christopher Stone -
Colin Walters -
D. Hugh Redelmeier -
Dan Winship -
David Woodhouse -
Denis Leroy -
Ding Yi Chen -
Ewan Mac Mahon -
Frank Murphy -
James M. Leddy -
Jerry James -
Jesse Keating -
Jesse Keating -
Jochen Schmitt -
John Poelstra -
Jon Ciesla -
Jonathan Dieter -
Josh Boyer -
Jukka Ruohonen -
Julian Sikorski -
Kevin Fenzi -
Kevin Kofler -
Krzysztof Halasa -
Martín Marqués -
Mathieu Bridon -
Matthew Garrett -
Matthew Woehlke -
Michael Cronenworth -
Michal Hlavinka -
Milos Jakubicek -
Nicolas Mailhot -
Orcan Ogetbil -
Patrice Dumas -
Paul Black -
Paul W. Frields -
Paul Wouters -
Peter Lemenkov -
Peter Robinson -
Pierre-Yves Chibon -
Rahul Sundaram -
Ralf Corsepius -
Seth Vidal -
Suren Karapetyan -
Till Maas -
Tom Callaway -
Tom Lane -
Toshio Kuratomi