[License-review] For Approval: Convertible Free Software License, Version 1.4 (C-FSL v1.4)

[Lukas Atkinson]

For the purpose of easier review here are the meaningful changes to the
previous version.

A new section 5.4 was inserted, which softens the mandatory publication of
changes:

> Changes which do not require a single commit or which result in unusable
> code do not need to be published. This includes,
> but without limitation to, code made non-functional due to bugs and code
> with no further prospects of continued work.
>

Section 7.5 (65% threshold for appointing new Original Authors) now applies
to individual components, i.e. not to a program as whole.

In Section 7.7, the word “Libraries” is replaced by “components”, without
explicitly defining the new term. And where the license previously said:

> […] In such event, the Library name shall be included in the file header.
> Clause 7.4 above shall apply to each Library independently. For the
> avoidance of doubt, Libraries licensed under Version 1.1 of the C-FSL do
> not need to be named as main Works in the file header to qualify as an
> independent Work.
>

It now says:

> […] In such event, the component name shall be included in the file header
> and identified as an independent Work under C-FSL.
>

A new section 7.8 was added:

> If a CFSL-licensed Work is incorporated into another program or
> application, and the Work has little association with or has distinct
> functionality from the rest of the program, the Work shall remain an
> independent component.
>

* Comments:*

While version 1.4 does clarify a few edge cases (thank you!) and seems to
close a loophole regarding the 65% threshold (sensible!), it does not
fundamentally address the criticism on the previous version:

   - It still requires publication of nearly all derivative works, which I
   think makes the software non-free. Compare especially Carlo Piana's
   criticism “there is more!” [1].
   - It does not address the problem that Original Authors are implicitly
   given an effectively unlimited license to contributions.
   - It continues to suppress forks of the project, which is usually bad
   for the community. C.f. Rob Landley's list of examples of license changes
   and maintainer–community dynamics [2].

In [1], Carlo Piana has suggested fundamental changes so that the C-FSL
might be “tentatively compliant”: Embed an explicit CLA or CAA in the
license which covers contributions to a *project*, but not the *changes*
itself. This would allow maintainers of a project to relicense their
project arbitrarily, without shackling the community to those maintainers.
Piana ends with:

I expected something in this direction with the new license, conversely I
> only see stubborn rewording that makes it more hard to lay persons to spot
> how the license in practice work. This is not going to succeed, I submit.
>

Again, no meaningful changes towards compliance have been made. In my
opinion, this makes it unnecessary to review this revised version: any
conclusion of the review process would remain unchanged as well.

[1]:
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003911.html
[2]:
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003900.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190123/30c5bf0a/attachment.html>