[License-discuss] GPL and proprietary WebAPIs

[Chris Travers]

On Tue, Dec 27, 2011 at 8:37 AM, Clark C. Evans <cce at clarkevans.com> wrote:
> First, thank everyone for their responses.  I especially
> enjoy the reading material that Rick Moen has referenced.
>
> On Tue, Dec 27, 2011, at 10:07 AM, Tzeng, Nigel H. wrote:
>> If it's not a derivative work then it's not a derivative
>> work and you should have no heartache.  If it is a
>> derivative work then you have legal recourse to correct it.
>
> I'm concerned about the case where a shim/adapter could be
> ruled as derivative work and as such its distribution of
> such could be prohibited under copyright law --- but where
> the court does not consider the derivative work to include
> an independent proprietary component needed to actually use
> the derivative in a meaningful way.

Two quick points:

1)  Derivation is not contageous.  SCO argued this in their lawsuit
against AIX to absolutely no avail.  Just because A is derivative of B
and B is derivative of C, it doesn't follow that A is derivative of C.
 At least in the US, you have to show that the derived *expressions*
from C made it from B into A.

2)  Copyright has, IMHO, virtually nothing to do with dependencies at
least in the US (IANAL).  Copyright only protects expressive elements,
and only to the extent they are separable from functional elements.
This is why I don't think that #include readline.h is sufficient to
create a derivative work, and even if it was, I could certainly create
equivalent macros in my own code, and create a minimal .h file with
only the exports I wanted ordered in a different order, and then there
would be no derivative work at least in US law (don't know about
Europe).  Basically a .h file is ideally a set of facts (namely
function prototypes).  If there are additional expressive elements I
don't see why those can't be stripped out.  In the US, facts cannot be
copyrighted, so I can copy all the whitepages directory listings in
the country without violating anyone's copyrights (in Europe I know
this is different however).
>
> In this case, does the GPLv3 create an additional contractual
> condition for the distribution of the "covered work" in 5(c)
> that would forbid the distribution of the shim if the required
> proprietary component is not also licensed compatibly?

If copyright law doesn't require permission, then you don't need
permission.  And even the FSF draws a line between where things are in
one process and where they communicate over pipes or sockets.

>
> Or, is 5(c) of the GPL essentially the same as the OSL and
> limited to only the scope of a derivative work.  In this
> interpretation, you rely upon convincing the court that the
> entire derived work necessarily includes a component which
> is required for it's operation.  That seems much harder case.

Interesting thought experiment.

Suppose I write a license functionally identical to the GPL (we'll
call it the MGPL) but with the provision that all software written
must be licensed under the same license if:

1)  It is written by a person who is bound to the license by
distributing MGPL'd software, and
2)  Interacts with the MGPL'd software in any way.

So if I write an MGPL'd web server than anyone who distributes this
web server and also makes a web browser must license the web browser
under the MGPL.

I wonder if that would even meet the OSD, particularly the bit about
not restricting other software?  Might it be an edge case?
>
>> IMO, "appropriate licensing strategy" is far more a
>> business decision than a legal one.  If you wish to develop
>> an open source community around your product then
>> GPL v3 + a proprietary license option like MySQL AB
>> offered is safe enough for most practical purposes.
>
> I think MySQL AB's licensing strategy is offered in this
> forum as an overreach.  In  particular, Larry Rosen argues
> that there is no derived work when an application simply
> uses MySQL as intended via its public interface, even if
> the application relys upon specific MySQL functionality.
> It seems that Rick Moran and many others agree.
>
> Please note that my scenario is different, I'm talking
> about a competitor who would alter/transform/modify our
> work in order to add proprietary functionality -- not
> simply use it via its public interface.

MySQL AB has argued many different things in the past in this area.
They generally drew the line though between using a standardized
interface like ODBC and directly linking to their libraries.  ISTR a
controversy on Slashdot regarding a statement that MySQL AB would
treat exporting the API's of the client libs via a web service as an
attempt to circumvent their licensing.
>
>> Then your scenario of shims and "creative
>> circumventions" isn't a negative but a positive as it
>> enhances both your revenue stream and ecosystem.
>
> I can't disagree more.  This technique, if the GPLv3
> offers no defense against it, would permit our competitors
> to keep their exclusive proprietary licensing stream
> while actively integrating the benefit that our software
> would provide without contributing back.  The shim being
> an actual "anti-contribution" since it may confuse users
> what is free software and what isn't.

Every open source license I know of allows some sort of bridging to
proprietary technologies.

Best Wishes,
Chris Travers