Re: [License-review] For Approval: Scripting Free Software License, Version 1.3.5 (S-FSL v1.3.5)
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
Reply to: