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

Engel Nyst engel.nyst at gmail.com
Wed Nov 6 12:03:58 UTC 2013


If I may comment on your goals, in relation to their implementation in 
the license or generally.

On 11/05/2013 10:37 PM, Elmar Stellnberger wrote:
> 1. The license should not only protect itself but any reference given to
> the authors such as concerning their web presence. The primary
> motivation to publish some software which should now be released under
> S-FSL was to attract people to the authors web page so that the ability
> to remove any such reference would have been a pitfall to the developers
> and publishers. It should also protect to some extent against
> re-publishing the software at another site with higher page rank
> possibly at cost just with the intention to draw off traffic from the
> original site (like f.i. already done with OpenOffice). It is the right
> of the user at least to know about the primary upstream page in the web.

I suggest to address this goal through social means, not copyright 
licensing means.

> 2. Concerning the incorporation into paid, proprietary or commercial
> software the license should offer a comparable level of protection to
> intellectual property rights as GPL does even for scripts and software
> not being compiled (You actually have to use L-GPL when incorporating
> your compiled sources into any such product. However GPL does not seem
> to give any such protection for code distributed and executed as source
> or by just in time compilation).

Well, I do think GPL may not have the widest imaginable extent for 
scripting languages, but that seems to be a limitation of the extent 
accessible to copyright for software, not of GPL.

> 3. Note that S-FSL requires some minimal provisions by the distributor
> regarded by the author as de-facto standard and fair use conditions: a
> free core distribution or proactive distribution of patches, updates
> including security updates and fixes to broken functionality to anyone
> who got the core distribution, no undue obstacle in obtaining them,
> secure checksums to verify the downloads. Things quite common in the
> open source sector but not with some proprietary systems: Downloaders of
> Windows can not verify their downloads with publicly trusted tools; in
> order to update OS/2 Warp 4 some 'mean tricks' i.e. insider knowledge
> was necessary before I have published that on my personal blog at
> elstel.org.

I'd suggest to address this concern simply by proving secure checksums 
and updated patches to users. Projects do that by doing it. I don't see 
how a license can help here, unless I misunderstand the problem.

> 4. The license has especially been designed for people who want to
> release their shareware under an OSS-compliant version for the first
> time experimenting to get input from a broader public community. As the
> original authors retain full property rights of their software even
> after incorporating patches (compare it in this point with the SRC M3
> license) they may re-publish it under a different license like BSD or
> GPL at any time. It has been designed for the original authors to retain
> a maximum of intellectual property rights especially and also for those
> who are reluctant to make their software public domain in the first place.

I don't think a copyright *license* can possibly make original authors 
"retain full property rights for patches".

Re-licensing patches under *any different* license also implies almost 
full copyright control from the initial authors. I don't think even that 
is within the scope of a license (unless it's a CLA).

Regarding the last phrase, I believe it implies that open source 
software means "public domain". It doesn't.

I'd suggest to rethink this goal. In my reading, it's confusingly full 
of proprietary assumptions, incorrect at best. They contradict a free 
software license.

> 5. By granting a group of developers to work on a new 'branch' other
> people can acquire similar responsibility and rights to work on an
> affiliated project. Free branching may be specified in addition to the
> license terms: "This program is licensed under S-FSL v1.3.x and may be
> branched for free.".

If a new branch has to be "affiliated", in the sense that special 
permission has to be given for someone to fork the software, it's not 
open source.

Regarding 4) and 5), I think that copyright control to the extent you 
want, even if it were possible, contradicts free redistribution (OSD 
#1), derived works (OSD #3) and distribution of license (OSD #7), at 
least. (likely more)

Please note, free as in free distribution or free software means free of 
the need to come back to someone and ask for more permissions. Free from 
the need to ask for (another) permission at all, in order to exercise a 
set of rights. The license should give those permissions already. Your 
goals and license seem to confuse it with an "I may allow you free of 
charge, but I keep control over whether I allow you to in the first 
place". That's not an open source license.



More information about the License-review mailing list