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

[Elmar Stellnberger]

Am 0
> "License".
> License means permission. Let us say, a copyright license is a text
> that grants certain copyright permissions under specified conditions.
> (give or take some amount of legalese)
>
> conditions != restrictions [that prevent those permissions in the
> first place]

requirements or 'restrictions' are so called exceptions from 
permissions. You must not touch the program if you do not consent with 
the license.

>
> Now, let me read OSD #7.
> "The rights attached to the program must apply to all to whom the
> program is redistributed without the need for execution of an
> additional license by those parties."
The license allows you all you need without need for execution of a 
different license given that you are ready to publish dependent works 
under the same license or as OSS free of charge. At least you can do 
everything with it that is implied
by the OSD criteria.


> - the rights to distribute the software, to read it, to prepare
> derivative works and distribute them [OSD #1, #3], attached to the
> program
> - must apply to all to whom the program is redistributed ([#5, #6]
> public or private, first downstream or the seventh)
> - without the need for them to come back to you to ask for permission.
You may any time create a derived work as long as you use the proposed 
naming scheme. The possibility of such a naming scheme to exist is 
enforced by the OSD criteria. Branching is just an additional facility 
you do not need to make use of and thus does not need to apply to the 
OSD criteria. Additional permissions off scale regarding the OSD 
criteria are always allowed.

The same argument applies for the facilitation about public 
distributors. They are beyond the OSD cirteria and thus do not hamper 
OSS compliance. The license would be OSS compliant without these 
additional permissions. Sending out patches or at least allowing them to 
be read by the original authors as the outcome of these requirements is 
is not an infringement towards free redistribution neither can it be 
deemed a discrimination against persons, groups or fields of endeavor.

>
> > 6. You may choose to develop a different branch of this program any
> > time you want given that your new branch serves a new purpose or is
> > sufficiently different _so that the original authors do choose not to
> > re-integrate your branch_. [...] _Branched versions can not_
> > re-publish under a different license or _use patches_, patents or
> > other intellectual property _of the maintainers of the parent branch
> > in a new context unless explicit consent from the maintainers of the
> > parent branch is given_.
>
> It's not clear to me what "a new context" means, what means "so that
> original authors do choose", nor what means they're forbidden to "use
> patches" without explicit consent. (if "patches" would be under S-FSL,
> it contradicts that branches are forbidden to "use" under S-FSL)
  It should just assert that they can make changes on sections where 
patents are already in use. However they can not use it another time in 
a 'new context'.


>
> Do original authors have to "give explicit consent" for people to make
> a branch, integrate S-FSL code, or can they block/disprove the
> creation of a branch because they state it's not sufficiently different?
With version 1.3.6 of the license no consent by the original authors or 
branch maintainers is required given that the stated criteria for new 
branches are fulfilled. Note that you may always need to "ask for 
permission" even for code that is licensed under GPL. f.i. if you want 
to re-publish under a different license then you need to ask all 
previous contributors for permission when using GPL. For S-FSL you just 
need to ask the original authors and eventually the branch maintainers. 
In spite of this GPL is an OSS license. This is because re-licensing is 
not required by the OSD criteria. - and so is branching or any other 
facilitation.