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

Elmar Stellnberger estellnb at gmail.com
Thu Nov 7 11:17:29 UTC 2013


In Reply To: Thorsten Glaser
>|/  The program may be distributed by a third party given that the program
/>|/  is distributed in its original state completely without any kind of
/>|/  modifications or patches. If you need to re-distribute a patched
/>|/  version of this program you need to distribute the patches separately
/>|/  from the original so that the pristine version can be restored at any
/>
> What about binaries?

Well, the license has been preliminarily prepared for publishing work in 
a scripting language or for JIT (just in time compilation). Most 
licenses like QPL and GPL do always talk about binaries, about linking 
them and so on. However this is often inappropriate for programs written 
with script languages such as python, bash or perl. As the license says 
nothing about binaries I would presume that it is not forbidden to 
derive such binaries as long as the sources are still shipped and 
handled in the way it is described by the license.

>|/  time. Any derived work must carry the name of the distributor, vendor
/>|/  or the product in its name (or a unique shorthand for it) preceded by
/>|/  the original unchanged name of the software and its version at the
/>
> This will explode, cf. the 4-clause BSD licences. (We currently carry
> 118 advertising clauses in MirBSD.) This is not non-free but doesn't
> scale well and is deprecated even by its inventors.

Maybe it will if there is some heavy mutual contribution (However as 
soon as the original authors agree they can at the current matter of 
state always re-publish under a different license.). For the general use 
case that distributors want to ship their own modifications adding a 
suffix like deb-3 or os-7.2 this will not explode. Suffixing makes it 
just a whole lot easier for the developers of the software to quickly 
spot whose sub-version to work on when it will f.i. come to serve a bug 
report; even if there should at some time be a suffix like deb-3-ub-8. 
Perhaps we should say "preceded by the original unchanged upstream name 
of the software" so that Ubuntu just needs to use ub-8. However at some 
point we do strongly recommend to get all changes incorporated into the 
main line. I believe it would really become a problem if the software is 
unmaintained or incompatible upstreams. However for this case we can 
either fork a new branch or denominate new copyright holders. Clearly 
considering this I think there is some point in your argument; we should 
likely change this to only praefix with the upstream name but not with 
subsequent contributors.

>|/  You as a distributor need to let your contributors add their names,
/>|/  their email and modifications with date to the changelog.
/>
> The requirement to carry a changelog is undue burden to downstream.
> Not everyone does that (usually, we just keep stuff in CVS).
>
> Not sure whether this is a stopping point, though.

  If the original authors did not create a changelog then there would be 
nothing to add. However most distributors have their own packaging 
changelog like the changelog.Debian and as long as this changelog is 
shipped and used there should be no additional constraint by the 
license. It just says that there needs to be one; not which one. The way 
I conceive things it is a right of the user to know who has changed 
what. Everyone who does a change to the software will be responsible for 
it. At the present state of OSS where the approach is just come and drop 
everything to the community we have a huge quality problem as no one 
feels responsible for the outcome.

> The term "public distributor" is not defined. Also, this makes the
> licence special to some groups in a way.

... well you have to read a bit further.

> |/  you are obliged to send a copy of your patches to the original authors
/>
> This so totally fails the "desert island test" and possibly the
> dissident one as well. This is, IMHO, also ground for rejection
> (not necessarily by OSI).

My base of OSS compliance criteria is http://opensource.org/osd and as I 
believe the license passes all these points. To refer to the Debian 
desert island test as explained at 
https://wiki.debian.org/DesertIslandTest I believe it would even pass 
the test itself:
"A good test case for whether a license is free (for issues like this) 
is whether a disconnected group of people on a desert island could 
distribute the software among themselves. In the vim case, they cannot. 
(For example, if the vim maintainer flies over the island and drops down 
a message saying "you must hereby send me your changes", how are the 
people down below to comply?) The fact that the vim maintainer can send 
the request does not say anything about whether the people receiving it 
could reply."
As far as I have studied law if there is a force majeure that prevents 
you from notifying the original authors or if there is some unreasonable 
burden to do so then you do not need to do that. - and on a desert 
island force majeure is preventing you from notification. Distributing 
without the knowledge of the upstream party will thus be o.k.. Note also 
that public distributors do not need to notify at all; only 'closed' 
distributions which obfuscate their sources need to. Consequently I 
would regard this as minor infringement.

>|/  referred to herein as the authors of the first version of the program
/>
> Why's got the first one a special position (instead of, say,
> chaining upstreams)?

Well that is the concept of the license. The original authors are those 
who did not only have the idea for the program but also have invented 
and designed the program and finally coded it in the first place. 
Invention includes primary requirements engineering. S-FSL assumes a 
proper software engineering and quality management process done either 
by the original authors or any later group denominated as new copyright 
holders. The bottom up development approach that is 'hack and drop to 
the community' is the way I believe rarely a good starting point for 
high quality assurance. Also the design of the initial inventors should 
be followed by later contributors.

>|/  publish or exchange your patches with other people. If you have some
/>
> If my patches are not distributed as part of your program but separately
> (as you require above) you cannot claim anything on them.

My argument against this is that patches for my software can not be 
produced without my software and are thus to be regarded as derived 
works. Note also that patch+orignial (is isomorph to) final results + 
patch (for a sufficiently accurate patch denominating line numbers). 
Isomorph in mathematics means something like 'the same regarding all of 
its properties' but presented in a different way. If you write f.i. '#' 
instead of '+' the resulting structure is still isomorph. Otherwise 
(i.e. for a non reverse applicable patch) it would be homomorph which 
would result in something that can be derived from an accurate patch. 
The argument of a patch as derived work still applies. It can never be 
seen independent from the program it was designed to patch because 
otherwise it would be meaningless.

>|/  By distributing patches you do also consent that the original authors
/>|/  may incorporate your patches into future versions of this program. The
/>|/  patched parts of the program and the patches themselves will also
/>|/  become subject to this licensing and may even be used for free in
/>|/  other programs or in the same program under different licensing as
/>|/  soon as you choose to publish any kind of patch; i.e. you need to be
/>
> This is very ouch-y, and I'm unsure whether this works in a simple
> software licence, as opposed to, say, a Contributor Licence Agreement.

... 'ouch-y' but actually necessary to re-license at a given later point 
in time. It was the intention of the license designers to make this 
possible. Consider my previous argument that it should be possible to 
license as S-FSL in a first place when publishing the first time and 
re-license later on under any OSS license you want. That will make it 
possible to present your work to others quickly and painlessly, allow 
first place contributions, meet others and potentially also to find 
another license of desire.

>|/  If you want to develop a separate branch of this program the original
/>|/  authors need to consent as long as the software may be subject to
/>|/  further development by them
/>
> Erm, *what*?

You may need it as soon as you develop something that is sufficiently 
different from the main branch and want to give it its own name. The 
idea behind it is that the original authors will have to decide whether 
they want an own branch for it or include the given features into main. 
... However this section should likely be subject to further discussion.

Yours,
Elmar








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20131107/83a41b06/attachment.html>


More information about the License-review mailing list