Free RewardRights License

[Matthew Flaschen]

Norbert Bollow wrote:
> Hello,
>   I'd very much appreciate if you could please review and comment on
> the following draft Free RewardRights License (FRRL):

The license is obviously OSD-compliant, because it can be relicensed to
GPLv2.  However, I don't think it's a good idea, and appears to allow
things that would be illegal if attempted.  Essentially, you've created
a weak copyleft license that allows relicensing under a particular
proprietary license.  It has the disadvantages of copyleft licenses
(complexity, limiting the choices of downstream developers) without the
guaranteed freedom for all recipients of the code or derivative works.
And then, it has the fundamental disadvantage of permissive licenses
(derivative works may not longer be open source) without the broad
compatibility (with essentially every license, free or proprietary);
major free licenses, not to mention other proprietary licenses (some of
which may be better than NFRRL on subjective grounds) are incompatible.
 Even if you included a broader relicensing clause, the license would
have to be revised occasionally just to accommodate new licenses.

The only real justification for this license can be to implicitly
endorse the proprietary Non-Free RewardRights License Agreement; such
implicit endorsements tend to be reinterpreted as explicit ones, and it
wouldn't be too long before someone decided to call NFRRL an
OSI-approved license, which it clearly can't be.

Because of these serious problems, I can't support this license and urge
you to use the unmodified GPLv3 when it comes out.

>    (b) Combining programs with proprietary "presentation elements"
>        which don't affect functionality, but which, through providing
>        different "look and feel" could improve customers' willingness
>        to pay.

This is probably already allowed by the GPL under the mere aggregation
clause.  If the combination is a derivative work, the presentation
elements' license would also need to allow the combination.

> 2. Compatiblity with GPLv2

This is easily accomplished because full relicensing is allowed.

> and Creative Commons licenses.

IANAL, but this is misguided, and will probably not be successful.
First, we only have to consider cases where the combination is a
derivative work of the CC work; otherwise it is mere aggregation and no
special permission is required.  CC Attribution ShareAlike 1.0 requires
that, "You may distribute, publicly display, publicly perform, or
publicly digitally perform a Derivative Work only under the terms of
this License" so attempting to distribute part of the derivative work
under FRRL would be illegal.  Later CC licenses have more liberal
share-alike clauses, but FRRL still probably wouldn't qualify.  If the
CC license had a no-derivs restrictions, the combination couldn't be
distributed at all.  If the CC license had an non-commercial
restriction, combinations couldn't be distributed freely.  In all three
cases , distributing the whole for a fee (as allowed by FRRL) is illegal.

Only if the CC license was Attribution only would that probably be
legal.  That case doesn't even require a special FRRL clause, though.

You also attempt to allow linking with Apache.  This may not be legal,
because FRRL doesn't have the GPLv3's "requiring indemnification of
licensors and authors of that material by anyone who conveys the
material" clause.

> 3. That the FRRL defines a notion of what it means for recipients to
>    be "fully empowered to use, modify and convey the Work" and then
>    defines the conditions for conveying the work in terms of the
>    requirement that recipients must be "fully empowered to use, modify
>    and convey the Work".  I hope that this approach will make the FRRL
>    more robust than the FSF's GPLv3 with regard to changes in the
>    legal environment that could possibly make some now variants of
>    tivoisation and/or MS-Novell-like deals possible.

I don't see why that would be the case.  You've basically just rephrased
the GPLv3 requirements, and I don't see why your version would be more
durable.  Writing, checking, and maintaining a strong copyleft like the
GPL is difficult.  It is not desirable to do it twice, and in fact if
both this and GPLv3 became popular confusion could result.  There are
likely problems in your license that GPLv3 has solved; I'm not going to
read it as closely as I am GPLv3.  Besides, what's the point in strong
copyleft it can still be converted to a (single) proprietary license?

Matt Flaschen