[License-review] For Approval: Scripting Free Software License, Version 1.3.6 (S-FSL v1.3.6)

Elmar Stellnberger estellnb at gmail.com
Sun Nov 17 11:24:07 UTC 2013


It will be the decision of the OSI commission whether to accept or
reject this license. At least I would have deserved an exact
reasoning on why it was rejected or accepted. I have not received
any cogent argument on this yet (Please give your view on my
contra-arguments.). f.i. I do not see it as a discrimination against
private distributors that they will have to send me patches: It
simply  asserts that I will be able to notice the existence of such
patches be it a private or public distributor (and other licenses
have the same restriction). Josh Berkus, other people have a
different perception on what is going on: Debian maintainers would
not have sent me to OSI if they would have thought like this:
Gergely Nagy:

  I would recommend getting your license
OSI[1] approved,


Paul Tagliamonte, after I have responded to his comments on
OSD #3 & OSD#5:

"Debian doesn't use OSI conformance as it's measure for free software. We
have our own tests (the DFSG), and a team to work out if a license is
free (the ftpteam)."

So he thinks the license is or could be OSI compliant. Otherwise
he would not need to write that.
Protection of copyright sections does IMHO not violate #3 nor
can special rights for the original authors be seen as a
discrimination against other people #5. They are those who
have invented and designed the program. Disallowing extended
rights for the original authors can under certain circumstances
result in quality issues. Current licenses can not clarify the issue
who is responsible for a given change and possible failure of a
program. As far as I have learned it a total exclusion of
responsibility as achievable by not noting who has changed what
would not even be lawful. S-FSL on the contrary does clearly
state who is responsible for adopting new patches in mainline
and to whom other changes can be attributed to.
Again responsibility is not the same as discrimination.
Again the additional possibility of the original authors to re-license
as it results from S-FSL and to decide about branching (as only
given in the original proposal but no more in 1.3.6) does only state
additional rights in complement to what needs to be granted by the
OSD criteria. If the license where OSD compliant without the
possibility to branch then it should also be with that additional
possibility as there is
* no need to branch (you would simply need to use a different name
which is explicitly granted by OSD)
* the authors could grant you to use a different name even without
anything being mentioned in the license which does not violate #7
as there is no need to branch and as even GPL may require additional
permission in cases where something is not covered by the OSD
criteria or the license itself as f.i. re-licensing a GPL program.
Similar arguments do apply to the additional possibility to re-license.
as there is no need by the OSD criteria to allow re-licensing and as
it just is a result of sharing your rights with the original authors
(responsibility discussion).

Elmar Stellnberger



The current proposal may have some flaws and the way od

Am 16.11.2013 21:41, schrieb Josh Berkus:
> All,
>
> I'm concerned that by continuing to discuss this license with Elmar, we
> are misleading him that it actually has some chance of being approved.
>
> --Josh Berkus
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review




More information about the License-review mailing list