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

[Elmar Stellnberger]

Josh Berkus:
>> 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.
>
> This is what is known as a "vanity license" and I believe prohibited
> from certification for that reason. If what you really want is
> shareware, then do shareware: it's a venerable and well-proven business
> model.

No, shareware is not my intention. My intention is an open source 
license giving customers the right to read, understand the sources, 
modify and adapt them to their own needs. It should set up certain rules 
for contributions and publishing derived works. Finally it should allow 
'fair use' acceptance to public and non public distributors which 
requires some sort of legal certainty to distributors only obtainable 
via a certification process like the OSI. They need to know how it would 
interact and what it means in detail.
While GPL and BSD may be too permissive for certain business models I 
have tried to find a new license which is less permissive and still 
conforms with the OSI criteria #1 - #10. Open source fetishists may not 
like it since they regard everything that is open source to be usable as 
ever they would like. This is not true and not even enforced by the Open 
Source Definition.
I wanna strongly discourage you from using barely provocative vocabulary 
as 'vanity license' since you should adhere to what the license really 
says when judging about the license, not about the initial motivation 
which lead to the creation of the license. So reading the license ...

Richard Fontana:
>> Modifications applied to this program may not affect the
>> name, original version, copyright, license or any reference given to
>> the authors such as their email addresses or their web presence and/or
>> page in any part of the program or any files attached to the program
>> apart from updates to these references made by the respective authors
>> themselves.
>
> This is a little unclear but I assume you mean 'preserve all copyright,
> license and attribution notices'.


i.e. The email address for an author may be updated even in elder 
versions of the program. However other people may not change it.
The license also says in some place:

should be indicated by them denominating either new copyright holders 
with the same right as the original authors

so updates may be needed but only by people authorized to do so.

Richard Fontana, is it still unclear?

Thorsten Glaser:
>> 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
>
> This is non-free: the GNU FDL is a common example of where to find
> invariant sections and why they’re inherently incompatible with OSS
> (think someone wanting to put an excerpt of the Emacs manual on a
> coffee mug, they can’t do that w/o adding the manifesto etc. too).

It should rather be regarded as a right of the user to know about the 
authors, copyright holders and their email addresses and the primary web 
page where to download new pristine upstream versions and get the latest 
email addresses. Yes; copyright and license notices need to be 
'invariant' sections only changeable by the respective authors because 
they need to be shielded against malicious alterations. I believe it is 
good style to include this into a license!

Thorsten Glaser:
> In short, I wouldn’t touch any piece of work under this licence
> with a ten metric-foot pole.

Well my experience with publishing programs as open source is very 
different. As soon as I have f.i. unleashed xchroot I found patched 
versions in the net even though that time the program did not even have 
a license. So my experience is that as soon as something is open source 
it will be read, altered and possibly even re-written. Later on I 
re-published the program under something I called S-FSL to put these 
alterations on a legal basis. It should also at least assert that I can 
use these patches without having to re-write myself.
I must confess that this model of contribution does in some way give 
preference to the protection of the 'initial authors' or 'copyright 
holders' rather than to encourage contribution. You are not oblidged to 
contribute if you do not want to. However some point about it is also 
that it should encourage to release under a free license at all in the 
first place; note that otherwise any change or modification of the 
program would be accusable even if it was shareware and the changes made 
privately. Given that the initial authors still hold full copyrights 
over their own program - whether they have chosen to include patches or 
not - they may any time re-publish it under another license like GPL or 
BSD as soon as a more permissive model is required. This will be 
especially useful if you have a program, want to present and publish it 
quickly to the public without even having to think on how to license. 
Nonetheless S-FSL will also facilitate new business models on its own 
(as pointed to initially). Concerning the management of patches it could 
be considered a bit similar to the DEC SRC M3 license as it does also 
assert that DEC can use the patches by its own (though this license had 
usage restrictions which is not what we want).