[License-discuss] GPL and proprietary WebAPIs

Clark C. Evans cce at clarkevans.com
Wed Dec 21 02:35:47 UTC 2011


On Tue, Dec 20, 2011, at 03:30 PM, Chris Travers wrote:
> In general, good will from the projects at issue is a factor that 
> should not be underestimated and being a good citizen means ideally 
> making sure they are ok with it.

Absolutely.  If people consider you to be behaving fairly, 
they are more likely to support your cause.

> I can tell you how the LedgerSMB core team approaches this.  We draw a
> hard line between "using our code" (requires adhering to the GPL) and
> using our API (does not).  In practice this means if you use our code
> as a basis for your code whether through object inheritance, literal
> copying, or paraphrasing, we expect you to adhere to the GPL v2. 

Let's suppose that I've working on a Ledger++ program 
which is a proprietary version of your Ledger SMB that 
adds awesome multi-state Payroll and Asset Depreciation
features.  Only rather than including these features
in your code-base, I include only stubs that package
up the data each feature needs, calls a proprietary
web service, and returns the data.

So, about 5% of my code is a bunch of hooks, while 95% of 
my Ledger+ code remains proprietary.  I release the stubs 
under the GPL license... but effectively, the features 
I've added are completely useless and non-operational 
unless you've paid for my web service subscription.

> This is intended on our part to keep the "based on" 
> language in the GPL v2 to be close to the derivative 
> works definition in copyright law and recognizing that
> nobody needs copyright licenses from Microsoft to write,
> say, Internet Explorer plugins.

My reading of the GPLv3 is that it uses copyright law
to determine when you've made a modification, but, the
condition to distribute your modification goes far beyond
this limitation, including "the whole of the work, and all 
its parts, regardless of how they are packaged".

> In this view, there is no problem. There wouldn't even be a problem,
> in this view, if the libraries were linked provided that the code
> connections are not so intimate as to create a derivative work (for
> example, I would argue that class inheritance in fact does this).

Would you have a problem with the scenario above, perhaps
assuming I'm implementing a business feature that you consider
to be "core" to the mission of Ledger SMB and you would have
hoped would be contributed back to the project?

Thanks kindly for any additional thoughts,

Clark




More information about the License-discuss mailing list