[License-discuss] GPL and proprietary WebAPIs

[Chris Travers]

On Tue, Dec 20, 2011 at 6:35 PM, Clark C. Evans <cce at clarkevans.com> wrote:
> 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.

Also bad feelings can come back to hurt you later, legal actions or not.
>
>> 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.

Ok.  So far so good.....
>
> 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.

Well, technically you'd probably release under the LGPL or BSD
license, sort of like nVidia does with their stubs for their Linux
video drivers.  Again this isn't a new thing.  You see a surprising
amount of it in Linux (ndiswrapper, the nVidia drivers that RMS hates,
etc).
>
>> 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".

That's not my reading.  My reading is that the license tries to get
away from the derivative works definition (maybe it's not strict
enough for Stallman?) through refining definitions.  Of course the GPL
is not a EULA and it only requires acceptance when you distribute the
work or derivative works, but that only covers some cases.

Let's try a thought experiment.  Let's say LedgerSMB depended on
Windows and was essentially using Windows-only API's (and thus linking
with Windows base libraries).  Now, I recognize that the GPL
specifically exempts linking to system libraries, but I see no reason
why system libraries are different from a copyright perspective (i.e.
this distinction exists solely because RMS wrote it into the license).
 Now, if linking implies derivation, then isn't the software (and by
extension *all* Windows software) derivative of Windows?  If that's
the case then doesn't every developer of Windows software need
Microsoft's permission to distribute such software?  I don't think so.

So if it isn't a derivative work and you aren't distributing
LedgerSMB, I am hard pressed to see how legal action could be
successful in court, but IANAL.  OTOH, it could be very successful
both in terms of expenses involved and bad press to get you to do what
I want.  Really, this is what the FSF did to Apple over the Objective
C add-ons to the GCC.  Sooner or later though someone will fight
through and win and this will lose its effectiveness.
>
>> 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?

Would I personally have a problem with that?  Not as such, though I
might think you were doing something unwise.  You are obviously
building a market for us and helping define how payroll should work
and how we should enhance our asset depreciation features.  However,
as we develop these, you are faced with a problem in that refusal to
contribute back would increase your own maintenance efforts for
diminishing returns.  You can't just take our code and close it all
off because of the GPL, and then fork and go on your way as a
proprietary product, so you are kinda trapped.  So in other words this
technique doesn't work around copyleft so much as it limits the
applicability of copyleft to code as code.

If I were talking to you I would be urging you to change your business
model, but even if this were LedgerSMB, I would feel it's your right
to go that direction.

Now, let's say this is not something like payroll that is under active
development.  Suppose this is something that many businesses may need
but we aren't planning to develop for a while.  Let's pick management
accounting.

Here you are somewhat safer in the short run because we are unlikely
to be immediately working on competing features.  You might be able to
collect license fees for a reasonable amount of time, and in doing so
you are building a market for my services.  Great!

However, even here you are better off at least planning on pushing
your software towards open source about as fast as you can.  If you
don't want to, I am happy to let the expenses of maintaining the code
come back and bite you.

Keep in mind though, I don't think any of the developers on the
LedgerSMB project are hostile to more permissive licenses.

Best Wishes,
Chris Travers