[License-discuss] GPL and proprietary WebAPIs
Clark C. Evans
cce at clarkevans.com
Tue Dec 27 16:37:27 UTC 2011
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.
More information about the License-discuss