[tahoe-dev] Is TGPPL compatible with Apache license?

Zooko O'Whielacronx zookog at gmail.com
Tue May 14 22:17:50 UTC 2013


On Tue, May 14, 2013 at 10:41 AM, Daira Hopwood (formerly David-Sarah)
<davidsarah at leastauthority.com> wrote:
>
>> 1. If we combine TGPPL code with Apache code to create one work derived from both TGPPL code and Apache code, can we redistribute such work under Apache license only and permanently?
>
> No.

I agree with Daira that you can't do this, although I'm going to
explain it differently than she did.

The reason you can't do this is that copyright law disallows you from
using Zfec, unless you get permission from the copyright holder.
("Using" in the preceding sentence means a few things, including
copying, adapting, translating, redistributing, selling, and more.)

There are two ways that you can get that permission to use Zfec:
either from the GPL or from the TGPPL.

The GPL is very widely used and hopefully well-understood. It grants
you permission to use [* see above about what "use" means] Zfec,
provided that if you make a derived work from Zfec you release your
derived work under the terms of the GPL. (By the way, there is no
rigorous, mathematical, technical definition for what is and isn't "a
derived work", although the absence of such a definition is very
frustrating to computer geeks like me, who like rigorous and objective
definitions for things. That's because a "derived work" is a concept
defined by copyright law, not by the authors of the GPL nor by authors
of Zfec. For better or for worse, copyright law — at least in any
jurisdiction that I've ever heard of — defines what is "a derived
work" in a very complicated and fuzzy and context-dependent way.)

So, the GPL does not offer you permission to make a derived work of
Zfec and license that resulting derived work to others under the terms
of the Apache license.

The other way you can get permission to use Zfec is from the TGPPL,
but it has the same kind of constraint. It will give you permission to
use Zfec only on the condition that you (eventually — within 12
months) release your derived work licensed under the terms of the
TGPPL. So it also does not offer permission to make a derived work of
Zfec and license it under the Apache license.

I will offer you one tip, though! Zfec was itself based on an older
library named "feclib" by Luigi Rizzo and many contributors. There is
another modernized derivative of feclib, named "fecpp" and written by
Jack Lloyd, which may serve your purposes and which is licensed under
the permissive BSD licence:

http://www.randombit.net/code/fecpp/

>> 2. If we include TGPPL code (unmodified or modified), as a standalone dynamic library,
>> in our Apache project, can we redistribute the TGPPL code under Apache license only and
>> permanently?
>
> No, this is no different from the cases above.

This is that annoyingly imprecise "gray area" that I mentioned above.
Would the resulting thing be considered "not a derived work of" Zfec
by a court of law? My opinion on this matches Daira's — I don't think
the technical details of how a thing gets compiled, linked, or loaded
should have any bearing on whether or not the thing "is a derived work
of". However, again, my opinion on that is not authoritative. That's
up to copyright law and the interpretation thereof by courts.

I hope this helps, yuanz! If you have any further questions or
feedback for us, please write again. I would be happy if you could use
Zfec. Swift is a good cloud storage system, despite not having
Tahoe-LAFS's security and integrity properties built in, and Swift
would be greatly improved by the addition of erasure coding.

(Although, by the way, it turns out not to be a simple improvement
without downsides and complications! We've spent years grappling with
the weird, subtle problems that erasure coding brought to Tahoe-LAFS.)

There is, I think, one option remaining to you for the use of Zfec,
which is that I could add the "Apache license compatibility exception
clause" to Zfec like we have in Tahoe-LAFS. See line 19 of
COPYING.TGPPL.rst:

https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/COPYING.TGPPL.rst?annotate=blame&rev=18b44383dc45c9f8dba9cb0149682bded6941028#L19

If I did that (and the only reason I haven't already is that I forgot
or didn't get around to it), then you would have the option of making
a derived work of Zfec and Swift in which the Zfec *part* of that work
was licensed under the TGPPL or GPL and the rest of it was licensed
under the Apache license. This would mean that if someone further
downstream wished to make a proprietary derived work of your work,
they would be allowed to do so using the non-Zfec part of your work,
but not allowed to do so using the Zfec part of your work, except
inasmuch as the GPL or the TGPPL would allow them to. Make sense? I
suspect that this option, too, will be unacceptable to your legal
department, but I'd like to find out what they say about it and
whether that option is of use to anyone else.

Regards,

Zooko


More information about the tahoe-dev mailing list