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

[Elmar Stellnberger <estellnb@gmail.com>]

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
> software."
>
> 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
> asked.
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
>   medium"
>
> 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
> > licenses).
> > 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
> software.
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