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

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



I'm going to copy this (and bounce the last mail here) to debian-legal.

Again, I'd like to stress how much I really dislike the idea of another
license written for fun.

Thanks for your work,
  Paul

On Mon, Nov 04, 2013 at 10:13:33PM +0100, Elmar Stellnberger wrote:
> 
> 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
> 
> 

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `-     http://people.debian.org/~paultag

Attachment: signature.asc
Description: Digital signature


Reply to: