[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 19:56:43 UTC 2013


Hi mirabilos,

Am 07.11.2013 17:34, schrieb Thorsten Glaser:
> FWIW, the GMane thread view for the Debian bug on this is:
> http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/1099104
> The bugreport is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728716
> although I’d have put it into the ITP bug #721447 instead.
>
> Elmar Stellnberger dixit:
>
>>> What about binaries?
>> 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
> No, binaries are derived works.

Yes, they are and the license does currently not give any restriction 
about them except for the naming convention (Perhaps we should mention 
there that derived works should contain a shorthand for the derivation 
process if it was automatic like mysw-version-gccbin.). Or what would 
you expect to be in there concerning binaries? If automatic derivations 
need special treatment ahead of this then what would it be?
>
>> 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
> This has led to catastrophes, but also to improvements (full forks).
> I think you’re too restrictive here, especially for the all of the
> OSS ecosystem.
Hmm, with this license it is the responsibility of the original authors 
to decide about this: either branch or integration into mainline. If an 
S-FSL developer does not have the resources for such work he can any 
time specify 'free branching'.

>
>> 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
> There’s CVS for it ;)
I did not give any restrictions to where the changelog should be 
located; or did I? It could as well be an automatic git, cvs or svn 
history. At least it should be available in some sort to the upstream 
maintainers which should be possible to organize even for incompatible 
technologies. Do you think we need to specify these possibilities 
explicitly? Perhaps, yes. You are not the first to ask me.
>
>> and drop everything to the community we have a huge quality problem as no one
>> feels responsible for the outcome.
> I don’t think forcing people like this would help.
>
> [ desert island ]
>> 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
> Yes, but this is a metaphor for less “majeure” things. Please do not
> assume special provisions for the “desert island”, otherwise the test’s
> metaphor will obviously fail – it’s used to help comprehend the issue
> *behind* the test, not for its own good.
The relevance of the desert island test needs to be examined, yet. It 
can only be infringed for non-public distributors. However it is not an 
OSD criterium (#1-#10). It would also pass for an individual. However if 
there is some broader effort to establish new features I would simply 
consider it good style to notify the upstream maintainers. The software 
below could change.
>
>> 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.
> You don’t define “public distributors”, and this will make some parts
> of the licence specific to certain people _and not their downstreams_
> which is an issue.
Well, yes I do. It is in paragraphs 6. and 7. (ui; that should be numbered).
"specific to someone": Well this is an unavoidable necessity in order to 
enforce bringing patches to the attention of upstream maintainers. 
Someone who obfuscates his modifications can hardly claim possession on 
my work. Well, we have allowed this for individuals who do not share 
their modifications/patches at all which is again "specific to certain 
use cases". My arguments against these issues are: It may be specific to 
use cases and organizational issues but it is not specific to people or 
groups of people. Furthermore you could simply leave these facilities 
out and the license would still work under OSD#1-#10.

>
> […]
>> program and finally coded it in the first place. Invention includes primary
>> requirements engineering. S-FSL assumes a proper software engineering and
> […]
>
> I think your ideas are really right, but trying to put them into
> this form will not work out.
>
> People do get along with the already-approved licences plus *asking*
> (but not legally requiring) to e.g. keep the “powered by FusionForge”
> comment on the output HTML, plus *reminding* people that things used
> in academic papers *must* be cited/acknowledged properly and that
> this-and-that is the correct citation for this piece of OSS software.
>
> For this, these things do not need to be in the licence.
>
> And, I think removing copyright/authorship remarks is not legal either
> so it doesn’t need to be explicitly required (maybe mentioned, sure).
Well I am not absolutely sure about it. They could for instance just 
move it to another place; i.e. from the help->about menu to some 
obfuscated place which should not happen either; and I am not so sure if 
the web presence would be part of it automatically though known to be 
the most secure hook for getting in contact or retrieving downloads from 
the primary maintainers.
>
>> 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
> Sure, the hack’n’drop is bad, but:
>
> Please do not put all bottom-up development into that category though.
> I find bottom-up SWE (after designing, of course) very nice for smaller
> things, basically where you can have an idea in your head.
>
> (But this is going off-topic.)
Well I must confess I often do it bottom up as well or in actual fact 
both at the same time: verify that a given way is viable with a given 
technology needs bottom up development. However for bigger or more 
complicated projects considering a good design will also be important.

>
>> starting point for high quality assurance.
> IMHO this doesn’t belong into the licence. Maybe in an academic or
> commercial environment, yes, but definitely not in OSS.

Well I see the license as some provision for a given development model. 
While GPL & co are strongly cooperative, S-FSL should also allow a 
top-down or a combined top-down model in contrast to mere agile, light 
weight or bottom up development which doubtlessly has an (increasingly) 
important place in software development. Top down in its primary sense 
simply requires some sort of privileges and control.

>
>> Also the design of the initial
>> inventors should be followed by later contributors.
> This is a point I am prepared to vehemently disagree, by pointing
> out that some peoples’ designs just suck. You may not fall under
> it (I’ve looked at your website to see what the programs mentioned
> are, but not at the code itself), but I know others who most certainly
> do. (Incidentally, they seem to end up at RedHat.)
Well if the design does really suck it would perhaps be best to 
re-implement. Open sources make it easy any way (no matter which license 
was used). Nonetheless I honor your noble intention to support such 
programs. I don`t wanna go too far but perhaps the light weight, agile 
or bottom up development model is a reason why things tend to be 
rewritten more often in the Linux community. If something has not been 
planned by the design you may simply have to rewrite all of it from some 
point in time on.

>
>> My argument against this is that patches for my software can not be produced
>> without my software
> Forward ed(1) diffs with no context can. (Mostly §24 UrhG which is
> especially interesting for Fanfiction, not so much for software.)
That is where I argue with homomorphism. You can strip a full context 
diff into a no context diff. Consequently the no context diff is a 
derived work of the full context diff. Then using transitivity the given 
criteria will apply the same way.
>
> Parts of the new code may need to be written in order to fit with
> the existing code, but that’s just interfacing.
The license says that such parts would not be concerned as far as 
independent. If it does not need the S-FSL code to run (or does 
incorporate S-FSL as a plugin) then it can even be put under a 
proprietary closed source license. Compatibility with S-FSL code is not 
excluded though (perhaps a loophole :( ).


>
>> and are thus to be regarded as derived works.
> And here we also disagree: if forward ed(1) diffs can be works
> of their own, so can be unified/context diffs iff the country
> in question permits “fair use” (Germany doesn’t but the USA do).
see the homomorphism and transitivity issue: A derived work of a derived 
work is a derived work.

>
>> It can never be seen independent from the program it was designed to
>> patch because otherwise it would be meaningless.
> Leaving mathematic terms aside (I tried hard to forget them and
> am in no particular mood to figure out which ones to use), yes,
> a “patch” can contain (and thus be) an independent work; for
> example something written for another program and then just
> fitted to match the interfaces of yours. (This is, incidentally,
> the reason nobody can legally go after the multi-platform Nievida
> graphics driver in Linux, no matter how much they want to.)
If it is independent work I believe it should be distributed as such.
i.e. as standalone file rather than as a patch.
To me a patch is something that refers to the part which is to be patched.

>
>> ... '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.
> Indeed, but – as others also pointed out – you need a much stronger
> contract for this, and you cannot simply require this of all patches,
> only for those steered your way with intent to accept them upstream.
>
> I know (from further above) that you always want that, but in practice
> this doesn’t work out (the “desert island” thing, and because upstream
> and downstream can and will disagree over whether to use a given patch
> or not).
Can you explain it any further why it won`t work in practice?

>> 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.
> Sure, but you need actual contracts for this, properly. You’d just
> only need to accept patches from people who signed them, or trivial
> ones (over which nobody can prevent you from relicencing).
Contracts with the authors of the patches? I think S-FSL as well as the 
DEC SRC M3 license make sure this is not required because it may not be 
possible to ask any contributor with hindsight. They need to agree in 
advance or work on their own branch possibly with other license.

>
>> 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.
> But in Open Source, the right of the user to fork the code (e.g. if
> they disagree with upstream) is basic.
I doubt whether this is enforced by the OSD criteria #1-#10. You could 
deem it an OSS license with certain constraints if 'free branching' was 
not given by the authors. If this is vital I can make it the standard 
option.
>
> bye,
> //mirabilos
>
> PS: My eMails to the OSI mailing list (which, incidentally, is the only
>      OSI list not also on GMane) also are delayed by a day or so, that’s
>      apparently normal.
bye,
Elmar






More information about the License-review mailing list