Nicolas -- Would the speaker contend that using GBS to reference *full image scans* of *entire works* was OK, but somehow just the cover thumbnails in OPAC were prohibited? I'm sure Google's management would be surprised to find they didn't own the scans (for example, of old out-of-copyright works) that they pay libraries millions of dollars to procure. Surely they must be allowed to supply those images in whatever API they choose.
For the speaker's argument to make sense, then I could not create an application to retrieve images from a regular Google Images search or from Google's cache at all, since the ownership of the original images is similarly "not all Google's". The argument as I read it is that Google should not provide these things as part of an API. I.E., the argument is against GBS (and other Google) APIs altogether. I suspect that he is only considering the subset of jacket images that may have come from 3rd parties under some limited terms. But this is not something for *clients* of the API to figure out. If Google wanted to return only Google-owned and public domain images to HTTP_REFERER's outside of their own servers, they could do that. But as clients of the current API, we have no such capability. The speaker needs to explain to his superiors at Google that the examples given on the API site itself don't meet his approval: http://code.google.com/apis/books/docs/dynamic-links.html#style-guide and see if they have a more receptive response than I do. --Joe Atzberger On Mon, Jun 16, 2008 at 4:44 PM, Nicolas Morin <[EMAIL PROTECTED]> wrote: > Hi all, > I went to the French Library Association's Congress last week, and had > an interesting talk with the representative for Google Book Search in > France. I inquired about the new Terms of Services and what they meant > for libraries. He was positive that using the GBS API to fetch cover > images was crossing the red line: Google doesn't own those cover > images, which are "third party material" and shouldn't be used in > opacs through the APIs. That's what I was told in no uncertain terms. > Nicolas >
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
