[License-review] For Approval: Convertible Free Software License, Version 1.4 (C-FSL v1.4)
opensource at lukasatkinson.de
Wed Jan 23 22:25:17 UTC 2019
For the purpose of easier review here are the meaningful changes to the
A new section 5.4 was inserted, which softens the mandatory publication of
> 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.
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!” .
- 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 .
In , 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-review