It is March 6.  How many days should we wait?  Especially given that the
current VP Legal as resigned and no replacement has been announced yet?


On 3/6/18, 1:03 AM, "Harbs" <> wrote:

>The path data appears to be from the CC-BY derivative and not the public
>domain original.
>I do think we need to either get clarification of replace the path data
>(and possibly SVG file). I’m happy doing it myself.
>I have opened a JIRA for an official ruling on the topic. It feels like
>it’s easier to just replace the data than get the ruling, but I think
>this is something which *should* have a ruling. If it’s OK to reuse SVG
>data in Cat B images, folks shouldn’t have to jump through hoops just
>because there’s nothing clear on the topic.
>I do think it’s a relatively minor issue and should be classified as a
>bug. It’s not something that should hold up a release if it can’t be
>resolved before the next release. I just created an issue on the topic.
>> On Mar 6, 2018, at 7:56 AM, Alex Harui <> wrote:
>> Hi Om,
>> Comments inline.
>> On 3/5/18, 3:09 PM, " <> on
>>behalf of OmPrakash Muppirala"
>> < <> on behalf of
>> <>> wrote:
>>> On Mon, Mar 5, 2018 at 2:47 PM, Alex Harui <>
>>> wrote:
>>>> Hi Om,
>>>> I am not able to follow your logic.  I think I've read your full email
>>>> and
>>>> have looked at the links.  It appears you are trying to say that the
>>>> data
>>>> points we are using came from [1], but to me, [1] seems clearly under
>>>> GNU
>>>> Document and CC-BY-SA.  The act of removing the state names from the
>>>> data
>>>> in [2] made it a derivative work, and it appears that the author of
>>>> says that work is not under Public Domain.
>>> The SVG asset itself is licensed as such.  We are not using the svg
>>> anywhere.  We are only using the map data which came from some other
>>> source.
>>> Map data is not copyrightable.
>>> Please read the section under "The map wasn’t eligible for copyright in
>>> the
>>> first place" here:
>>> aaOfQ%3D&reserved=0
>>> " If the components of the map are “entirely obvious” the map will not
>>> copyrightable. For example, an outline map of the state of Texas, or
>>> of
>>> the US showing the state boundaries is *not* copyrightable. (Not
>>> creative.)
>>> Ditto maps that use standard cartographic conventions, like a survey
>>> (Not original.) "
>> Right after the passage you quote, it says this:
>>    "This is could be a tough call in certain cases
>>    (I mean, come on ... “entirely obvious”?) but
>>    that's the what the courts have said. Just keep
>>    in mind ... what you think is entirely obvious,
>>    the mapmaker might contest as creative."
>> Let's see what other PMC members think.  To me, the quote I pasted
>> indicates that this is still a controversial area.  The definition of
>> data", AIUI, has to be tied to facts.  So, GIS coordinates, or any other
>> lat/lng fact that is used to create a map is not copyrightable, and any
>> map image produced by the US Government is in the public domain.  But I
>> believe there is a gray area around the digitizing of maps.  The number
>> points chosen which create the level of detail of a map could be argued
>> be a form of expression as well as the line-weights chosen for the
>> Also, the provenance/history of how the SVG file you chose became public
>> domain is murky.  I was unable to determine where the data points came
>> from.
>> To me, that's one reason why folks on wikimedia are claiming copyright
>> different licensing on their maps that are essentially digitized from
>> public domain US Government maps.  The fact that the data points for the
>> states are different in different SVG files also leads me to believe the
>> data points are not facts.  I think the safest and least controversial
>> option is for us to use a map that is in the public domain already.
>> map [1] seems to have a much simpler public domain provenance.  Then I
>> think there is less surface for nitpickers to attack.
>> If other PMC members want to go with the current data you have in the
>> files then I'll defer to them (and you).
>> Thanks,
>> -Alex
>> [1] 

Reply via email to