[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!

S-FSL v1.3.3 uploaded at http://www.elstel.org/license/

Having clearly considered your critics I have published a reworked edition
of S-FSL which should more strictly adhere to the terms of OSS-software.
As you can understand and as I have already partially described there are
still issues to me which discourage me from using an existing license like
f.i. GPL or BSD.

  The new license is posted here for public review.

We could possibly allow any distribution to distribute patches without
notifying the
"original authors" as far as the term "distribution" can be defined
clearly and
doubtlessly (i.e. to only apply this restriction to individuals and
organizations who
do not distribute their software for free to the public; if that would
help us).
That will not be possible, due to DFSG#3 (derived works): "The license
must allow modifications and derived works, and must allow them to be
distributed under the same terms as the license of the original

Which means that whoever gets the software through Debian MUST be able
to redistribute it under the very same terms Debian did.

Furthermore, there are many distributions derived from Debian, asking
all of them to send you patches whenever they make the tiniest
modification (even to packaging!) is not going to work, neither for you,
nor for Debian, nor for any of the distributions based on it.
Now nothing that can be called a 'public distribution' needs to send out
patches. The patches as well as the patched programs do automatically
become subject to the same license.
I would strongly suggest you reconsider your license, or at least this
requirement, as it will never, ever work as you expect it to: people
will just not use your software, because requiring them to send patches
back no matter what is so huge a pain in the backside that noone in
their right mind will do it. It's a much smaller effort to find an
alternative (like schroot, in this case) or roll your own.

Furthermore, there's this part of the license:

  "If you want to develop a separate branch of this program you need to
  ask the original authors for permission."

That goes against DFSG#4, which permits the author to require
distribution under a different name, but still requires the license to
allow distributing patched versions. The quoted paragraph prevents that,
so much so, that it's far too strict even for non-free: if we ever want
to do a non-maintainer upload for whatever reason, it's not possible,
because that may very well mean "develop a separate branch", and thus
require asking for permission.
now the term separate branch is clearly defined. It means publishing under
a different name(ing convention).

Furthermore, the quoted paragraph also has a loophole: it only requires
one to ask the original authors for permission, it does not say that
the permission needs to be granted too. In a strict reading of the text,
just asking for permission and not waiting for an answer is ok. Even
better, asking, but receiving a negative answer is still ok, because one
that loophole has been eliminated; thx.

Going further:

  "Distribution of the program by third parties must be done free of
  charge apart from fees for the physical reproduction of the data

This goes against DFSG#1: "The license of a Debian component may not
restrict any party from selling or giving away the software as a
component of an aggregate software distribution containing programs from
several different sources. The license may not require a royalty or
other fee for such sale."

While this part may be okay for non-free, it definitely is a no-go for
main. The exceptions given do not matter.
'exception' can now be any software or additional service as long as
xchroot is not distributed outside of a distribution;
that should suffice.

The way distribution is defined is also a bit odd: "The term
distribution describes shipping of a given set of software and its
documentation with adherent materials."

So if I strip away parts of the software (like documentation), and
publish that, does that count as distribution? Strictly reading the
license: no, because adherent materials are not shipped with it.
replaced by and/or; forgetting about docs should no more matter

  "Availablity free of charge or costs includes tools, software and
  manuals needed to download or obtain the distribution in a finally
  usable state as well as the possibility to verify the integrity of the
  download securely but not general connectivity to the internet."

This part is also quite vague. Lets imagine the following scenario:
there's Joe Average user, installing GNU/Linux for the first time. He
has absolutely no idea how to do it, so he buys a book about the topic.
To install additional software, such as those covered by this license,
he uses tools and techniques described in the manual, for which he paid
for. In this case, the distribution is not allowed to let Joe Average
install programs covered by this license, because he needed a paid-for
manual to install the distribution and the software covered by the
license in question.
 Thanks for that hint. My intention was that a technically experienced user
should be able to do it. For OS/2 Warp 4.5 doing the updates without
purchasing docs was even impossible for a technical expert user before
http://www.elstel.org/OS2Warp/InstallUpdate.html. That is the only issue
I want to prevent.
:: replaced by the term 'averagely experienced technical user'

     That's not true; commercial software *can be paid software*. So
     long as

can be free software* (sorry!)

     the software is compatable (and the work on the whole is
     distributed as
     GPL), this isn't a problem.

     Please, if you don't know how the GPL works, I have to strongly insist
     on you not writing your own license.

   Oops there we have an error! (Well I clearly know how it works with GPL.)
Commercial software does not need to be paid software. Well, to me a
similar restriction like for GPL could be very handy: having to put
all of the
software under any OSS-compliant license as soon as an S-FSL program
is incorporated (That would also limit possible interference with other
Would that be acceptible?
I'm not exactly sure I understand what you mean here. If you mean that
any program or distribution that incorporates an S-FSL licensed program
will need to comply with the S-FSL license terms aswell, that will not
work. First of all, the S-FSL is not compatible with the GPL, so you
can't "link" it or integrate it with anything that is GPL'd.
Furthermore, DFSG#9: a license must not contaminate other, unrelated
no just compliance with any OSS-license like f.i. GPL so that S-FSL is
'compatible' to other licenses; see for S-FSL v1.3.3

Reply to: