Free RewardRights License

[Norbert Bollow]

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

License text:  http://FRRL.info/license
Rationale:     http://FRRL.info/rationale

It is in many ways very similar to (the Last Call draft of) Version 3
of the GNU GPL.

Besides having a much less ideological preamble, the main differences
to GPLv3 are

1. That the FRRL is designed to support several categories of business
   models besides those supported by the GPL, in particular:
   (a) Requiring royalty payments for specified categories of
       commercial use.
   (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.

2. Compatiblity with GPLv2 and Creative Commons licenses.

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.  (However, since
   version 1 of the FRRL will allow relicensing under version 2 of the
   GPL, the protections in the FRRL against tivoisation and/or
   MS-Novell-like deals are relatively weak until most GPLv3 projects
   have upgraded to a later version of the GPL so that the GPLv2
   compatibility can be dropped from the FRRL without losing license
   compatibility with the majority of active GPL-based projects.)

Greetings,
Norbert.


--
Norbert Bollow <nb@...>                    http://Norbert.ch
President of the Swiss Internet User Group SIUG  http://SIUG.ch

[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

[Norbert Bollow]

/* This dicussion is about the Free RewardRights License
 * License text:  http://FRRL.info/license
 * Rationale:     http://FRRL.info/rationale
 */

Matthew Flaschen <matthew.flaschen@...> wrote:

> you've created a weak copyleft license

Actually I'd call it "semi-strong copyleft", rather than "weak
copyleft", since it guarantees that all derivative works are at
least semi-free.  (For the definition of semi-free software see
http://www.gnu.org/philosophy/categories.html )  In fact the
category of RewardRights licenses provides significant freedom
rights beyond those provided by any existing semi-free software
license that I'm aware of.

> that allows relicensing under a particular proprietary license.

At least according to the FSF's definitions of the terms, the
Non-Free RewardRights Licenses are not proprietary licenses.
They're semi-free.

> appears to allow things that would be illegal if attempted.

I've have fixed the two compatibility clauses which were a
bit carelessly worded so that they could be misinterpreted
in this way.

> urge you to use the unmodified GPLv3 when it comes out.

That is not an acceptable option from my perspective, because
the GPL does not support enough business models to allow GPL'd
software to completely replace all closed-source software.

> >    (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.

I'm thinking of situations where there's at least reason to doubt
whether adding the proprietary "look and feel" elements is "mere
aggregation".  Anyone interested in basing a business model on the
idea that people would be willing to pay for a nice "look and feel"
will be very interested in legal certainty about this point.

> If the combination is a derivative work, the presentation
> elements' license would also need to allow the combination.

The typical use of this clause will be that the company which owns the
rights to the presentation elements is the one doing the conveying,
hence there are no worries about license compatibility on that side.

> > 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.

Of course there are cases where the clause isn't needed - no
disagreement about that.

> 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.

You're right, there's no reasonable way to make FRRL compatible with CC
ShareAlike or No-Derivatives licenses; it was a bug of draft 3 that it
claimed to be compatible.  I've fixed that.

> 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.

That clause is not needed in FRRL due to the FRRL having an explicit
linking permission for the Apache License.  (Linking with the Apache
License adds the additional requirement of requiring indemnification
in certain situations which would be a violation of the "no additional
requirements" rule if it weren't for the explicit linking permission.)

> > 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.

The GPL says "you may convey if you do X", with X being designed so
that in the current legal environment, it is believed that doing X
results in the users being fully empowered to use, modify and convey
the Work".  This cause-and-effect conclusion is vulnerable to changes
in the legal environment; IMO it is bad engineering to rely on that.
By contrast, the FRRL defines "fully empowered to use, modify and
convey the Work" and then makes achieving that for the recipients a
condition of conveyance.

For an example of how this could turn out to be more robust, imagine
that a new category of "intellectual property rights" gets invented
which is similar in effect to patents so that it would allow the
equivalent of the Novell-Microsoft deal, but distinct from patents
so that the patents provisions of the Dicussion Draft 3 and Final
Call Draft of GPLv3 don't apply.

> Besides, what's the point in strong copyleft it can still be
> converted to a (single) proprietary license?

The point is that even the Non-Free RewardRights Licenses provide
important freedoms.

Greetings,
Norbert.


--
Norbert Bollow <nb@...>                    http://Norbert.ch
President of the Swiss Internet User Group SIUG  http://SIUG.ch

[Matthew Flaschen]

Norbert Bollow wrote:
>> that allows relicensing under a particular proprietary license.
>
> At least according to the FSF's definitions of the terms, the
> Non-Free RewardRights Licenses are not proprietary licenses.
> They're semi-free.

This is just semantics.  The FSF defines such a license as non-free, and
it's not OSD-compliant either.  Thus, OSI shouldn't be endorsing it even
implicitly.

> I've have fixed the two compatibility clauses which were a
> bit carelessly worded so that they could be misinterpreted
> in this way.

Your change appears to address the problems I identified, though a
combination with CC-NonCommercial couldn't be distributed commercially.

> That clause is not needed in FRRL due to the FRRL having an explicit
> linking permission for the Apache License.  (Linking with the Apache
> License adds the additional requirement of requiring indemnification
> in certain situations which would be a violation of the "no additional
> requirements" rule if it weren't for the explicit linking permission.)

I think you're right, because of the "provided that in doing so you
fulfil the conditions imposed by the Apache License" clause.

> For an example of how this could turn out to be more robust, imagine
> that a new category of "intellectual property rights" gets invented
> which is similar in effect to patents so that it would allow the
> equivalent of the Novell-Microsoft deal, but distinct from patents
> so that the patents provisions of the Dicussion Draft 3 and Final
> Call Draft of GPLv3 don't apply.

I'm kind of skeptical that a license could deal with this implicitly.  I
doubt it would hold up in court.

>> Besides, what's the point in strong copyleft it can still be
>> converted to a (single) proprietary license?
>
> The point is that even the Non-Free RewardRights Licenses provide
> important freedoms.

I know the FRRL is OSD-compliant and I understand your perspective, but
I just think it's bad policy.

Matt Flaschen