<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<pre>In Reply To: Thorsten Glaser
>|<i> The program may be distributed by a third party given that the program
</i>>|<i> is distributed in its original state completely without any kind of
</i>>|<i> modifications or patches. If you need to re-distribute a patched
</i>>|<i> version of this program you need to distribute the patches separately
</i>>|<i> from the original so that the pristine version can be restored at any
</i>>
> What about binaries?
</pre>
<div class="moz-cite-prefix">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.<br>
<br>
<pre>>|<i> time. Any derived work must carry the name of the distributor, vendor
</i>>|<i> or the product in its name (or a unique shorthand for it) preceded by
</i>>|<i> the original unchanged name of the software and its version at the
</i>>
> 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.</pre>
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.<br>
<br>
<pre>>|<i> You as a distributor need to let your contributors add their names,
</i>>|<i> their email and modifications with date to the changelog.
</i>>
> 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.
</pre>
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.<br>
<br>
<pre>> The term “public distributor” is not defined. Also, this makes the
> licence special to some groups in a way.
</pre>
... well you have to read a bit further.<br>
<br>
<pre>> |<i> you are obliged to send a copy of your patches to the original authors
</i>>
> 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).
</pre>
My base of OSS compliance criteria is <a class="moz-txt-link-freetext" href="http://opensource.org/osd">http://opensource.org/osd</a>
and as I believe the license passes all these points. To refer to
the Debian desert island test as explained at
<a class="moz-txt-link-freetext" href="https://wiki.debian.org/DesertIslandTest">https://wiki.debian.org/DesertIslandTest</a> I believe it would even
pass the test itself: <br>
"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." <br>
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.<br>
<br>
<pre>>|<i> referred to herein as the authors of the first version of the program
</i>>
> Why’s got the first one a special position (instead of, say,
> chaining upstreams)?
</pre>
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.<br>
<br>
<pre>>|<i> publish or exchange your patches with other people. If you have some
</i>>
> If my patches are not distributed as part of your program but separately
> (as you require above) you cannot claim anything on them.
</pre>
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.<br>
<br>
<pre>>|<i> By distributing patches you do also consent that the original authors
</i>>|<i> may incorporate your patches into future versions of this program. The
</i>>|<i> patched parts of the program and the patches themselves will also
</i>>|<i> become subject to this licensing and may even be used for free in
</i>>|<i> other programs or in the same program under different licensing as
</i>>|<i> soon as you choose to publish any kind of patch; i.e. you need to be
</i>>
> 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.
</pre>
... '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.<br>
<br>
<pre>>|<i> If you want to develop a separate branch of this program the original
</i>>|<i> authors need to consent as long as the software may be subject to
</i>>|<i> further development by them
</i>>
> Erm, *what*?
</pre>
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.<br>
<br>
Yours,<br>
Elmar<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div>
<br>
</body>
</html>