[License-discuss] GPL and proprietary WebAPIs

[Clark C. Evans]

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.  

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?

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.

> 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. 

> 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.

Best,

Clark