[kwlug-disc] This sounds scary? no more GPL?

[B. S.]

On 06/09/2016 09:15 PM, Bob Jonkman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> B.S. wrote
>> There is a 3rd use case, which is what I thought was going on -
>> what I would call thunking. (Think windows.) Think LD_PRELOAD.
>>
>> I write 'api' calls with identical headers to the underlying
>> API/SDK. I munge things in between, possibly returning directly,
>> and possibly calling the underlying API and munging the return.
>> Essentially replacing the pointer to function func, and internally
>> calling the direct _func functions instead.
>
> Interesting! But I don't think that was the case with Oracle and Google.
>   Google only partially implemented the Java API, but I don't think that
> was Oracle's concern either.  I suspect their true motivation was that
> Google's Android phone made a ton of money, but the Oracle Java Phone
> never made it off the drawing board (if it ever even made it TO the
> drawing board!)[1].
>
> There was another use case I read about[2] where a vendor made available
> an API for their service for "API consumers", but the API was then used
> to create a competitive service. The author of [2], Peter Bright
> believes that's a clear case of Fair Use. But he thinks Google's use
> of Oracle's API is a clear case of infringement since Google didn't
> fully implement Oracle's API, so Google should (and could) have
> created their own (incompatible) API.
>
> But I don't think API copyrights or patents should ever stifle
> competition and a better product. Must be because I'm such a Free
> Software fanatic...

In the end, such thunking is the only way to evolve API's. Your 
refactored software duplicates the old, possibly adding new and/or 
actually calling the old - in all cases putting itself between the old 
and new. Thunking, at the time, was the common term for win32 calls to 
the (old) win16 subsystems. (Think MS-DOS.) [Or some variation thereof - 
but don't think it's 64bit to 32.) {In essence, this is exactly what 
every new version of an API or lib is. Else ... chaos. The difference 
here is most of the time it is the original author, thus right's holder, 
doing the updating. Which, of course, mostly doesn't apply in a FOSS / 
GPL environment, as the original author usually gives up all rights. 
Without it, new developers taking over maintenance of old projects 
becomes problematic.}

One of the article / issue's problems is, IIUC, headers / function 
definitions now copyrightable. Which seems ludicrous. [For old software 
to work with new versions, by definition you must have exactly the old 
function defs / parameter types, etc.]

Thus, IIUC, although copyrightable, decision declared such use fair use. 
(Fair dealing is IIUC a Canadian term, none of which applies to this 
discussion.) Thus the consternation over the expansion of 'fair use'. (?)

- IIUC, 'fair dealing' may eventually come into play, thus Canada, as it 
seems despite all protestations, U.S. language gets dropped in to 
Canadian legislation. But I expect for such U.S. decisions to apply to 
Canada such legislation must actually get enacted and/or such used in a 
Canadian case (by which it becomes effective due to Canadian case law / 
precedent.) [Note that U.S. precedents can and have been used in 
Canadian cases, particularly absent Canadian precedents otherwise. And, 
AFAIK, it is the reasoning behind a U.S. precedent that is used - it's 
not just lifted and dropped in. Thank goodness.]

In any case ... the point of the original author that the decision has 
impact is probably true. Just what that impact is is the question. Thus 
Joe's OP excellent observation: This sounds scary!

If people come across links to trusted opinions on actual impact, do 
please post.