Bug#765421: jmapviewer: Resolution for missing Bing logo

Sebastiaan Couwenberg sebastic at xs4all.nl
Sat Oct 18 15:02:09 UTC 2014


On 10/18/2014 04:19 PM, Felix Natter wrote:
>>> But if MS decides the logo must not be included in jmapviewer
>>> then I'm afraid I *must* remove BingAerialTileSource.java from
>>> jmapviewer and apply the attached patch [1] to 0.0.svn7480+dfsg1-2,
>>> removing Bing support from JOSM. Otherwise jmapviewer may be moved to
>>> non-free because it contains Bing support but not the logo [2].
>>
>> I'm not sure that the alternative is that you *must* remove the Bing
>> support from jmapviewer.
>>
>> The logo referenced by the BrandLogoUri in the attribution REST-call be
>> fine the use instead of the bing_map.png included in jmapviewer. As
>> mentioned by Martin Krüger:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765421#30
>>
>> The Bing license says:
>>
>> "
>> and if the required logos and copyright notices are not
>> included in the service generated content, you shall add the logos and
>> copyright notices provided by Microsoft to the service generated content
>> as described in the SDKs
>> "
>>
>> Since the attribution REST-call includes the logo in its generated
>> content, downloading and using that instead of adding it in jmapviewer
>> itself seems to comply with the license.
> 
> I thought you mean to patch josm in your last mail! Of course patching
> jmapviewer to download the image during build time is a good solution:
> 
> wget http://dev.virtualearth.net/Branding/logo_powered_by.png -o ...
> --> is that what you and Martin Krüger mean?
> (is it even ok from a Debian point of view to download images during
> build?)

No, builds cannot require network connectivity.

> --> If yes, then I can implement it on the weekend. If it's more
> complex, then I'm probably out (see below). @Bas: could you take over in
> this case?

The proposed solution is to download the logo at runtime, using the
patch by Markus Lundblad which downloads the logo when fetching the
attribution meta data. See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765421#60

I can apply this patch to the jmapviewer package since that's already
under the Debian GIS umbrella.

I've updated the josm, josm-plugins and openstreetmap-map-icons packages
with recent snapshots. Since all pkg-osm packages should move to
pkg-grass, I've created copies of these three repositories under
pkg-grass. So we can update these packages in the context of this bug too.

>>> --> can we agree on this?

If downloading the logo at runtime by patching jmapviewer is an
acceptable solution to both Debian and Microsoft, that's the way to go.

If it's not, then removing the Bing support from jmapviewer and patching
josm to cope with that is what we should do.

>> In the interest of our JOSM users, doing our best to prevent the removal
>> of Bing support in jmapviewer should be our priority.
>>
>> Please discuss the BrandLogoUri solution with Microsoft in your call,
>> that seems to be the preferred solution to keep jmapviewer and its rdeps
>> in main, while also complying with the Bing license terms.
>>
>> While my brief tests with your patch show that JOSM works fine without
>> Bing support, it's a major loss of functionality. MapBox Satellite and
>> other freely usable satellite imagery is not on par with the Bing
>> imagery.
> 
> I'm trying hard, but if the logo is not DFSG compliant *and* the
> BrandLogoUri solution is not acceptable for MS (or Debian), then I don't
> see any other choice but removing bing support from jmapviewer.
> Is *that* ok?

Yes.

> (this issue shortly before the code freeze puts pressure on me and
> is beginning to have an impact on my dayjob so I need to finish this
> on Monday!)

I can help you share the load with on Debian side.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



More information about the Pkg-grass-devel mailing list