After consulting with Red Hat Legal, I've drafted a proposed policy on acceptability of inclusion of flags in Fedora Packages. This goes outside the scope of the Fedora Packaging Committee, so I am presenting it for approval by FESCo.
The draft is here:
Will cover this at 2009/03/20 meeting
Why, exactly, is this necessary at all? There was no background on the need for this policy in the wiki page, which would be useful. I assume it's something to do with Red Hat legal being concerned about the way nations are represented in Fedora?
FESCo elected to defer this issue, not being informed of the background and context, making it impossible to form an educated opinion.
1) What is the legal issue (if there is one)?
2) What effect will the exceptions allowed in the proposed policy have on said legal issue?
3) What about packages already existing in Fedora?
4) Was there a particular event that brought about the need for this policy?
If some of these questions cannot be answered publicly, you're more than welcome to use the FESCo list or e-mail us individually. It'd obviously be preferred to answer here, though :)
Currently, there is no formalized policy around whether flag images can be included in Fedora. In the Red Hat Linux era, Red Hat came across several problems caused by flags (China would not certify Red Hat Linux for import with the Taiwainese flag present, for example). They also have been touchstones for various ethnic and cultural groups to get angry about either the inclusion or exclusion of flags. Red Hat adopted a general policy of "no flags", but that policy was not written down when RHL became Fedora. Recently, I was asked to help draft a formalized policy that was a bit more permissive than "no flags" by a Fedora community member. I asked Red Hat Legal for their advice, not due to any specific legal issue, but more to try to avoid any. They gave me some advice, which I then used to help craft the proposed policy.
So, to your questions:
Please consider this policy again. Having this documented will clear up some confusion and prevent unnecessary issues in the future.
I'm a little concerned about this example:
* Flags used for gaming purposes, such as a game that uses flags to represent country/language selection
In this specific case, the flag usage is not acceptable. The flag use here is almost certainly not essential.
It's a bit unclear whether this is pointing out the same thing as the deluge example (the flag shows where the players are connecting from and thus, nonessential) or if it's pointing out that this is being used in a game and thus not essential. If the former, just needs clarification. If the latter, I think the policy's a little broad. For instance, a WWII simulation would have a real justification to use flags from the countries involved. freeciv gives the player the option to play as a historical leader from an actual country. These seem to be technically (user interface requires something that denotes a specific country) and substantively (other information linking to real geopolitical entities is given) necessary.
We get a bit greyer when we get to games that allow a user to choose a nation to play as but have no other traits identifying the nation. For instance, netpanzer allows you to choose a country with flag. This flag is then used to make your units distinct from other player's units. Some identifying marker is needed but the flag and name need not be real areas. We just have to create a palette of fake country names and flags. This seems like a more appropriate level to draw the line (although with no concrete problem to address, it's hard to evaluate what benefits and costs we have from drawing the line here rather than somewhere else or having no line at all.)
One other question which bothers me logically but probably has no answer without a concrete problem to address is why we'd be outlawing the use of flags from geopolitical entities but not the use of the geopolitical entities names.
this policy was approved. There's enough flexibility in here to allow us to address toshio's concerns on a case-by-case basis.
to comment on this ticket.