Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Elmar Stellnberger <estellnb@elstel.org> writes:
> Am 04.11.13 18:43, schrieb Paul Tagliamonte:
>>
>>
>>
>> On Mon, Nov 4, 2013 at 12:42 PM, Paul Tagliamonte
>> <paultag@debian.org <mailto:paultag@debian.org>> wrote:
>>
>> On Mon, Nov 04, 2013 at 06:22:15PM +0100, Elmar Stellnberger wrote:
>> > Is it really a problem? If yes then I can add an exception for
>> > distributors like Debian.
>>
>> Perhaps you're interesting in reading our guidelines:
>>
>> http://www.debian.org/social_contract#guidelines
>>
>> point 8 is "License Must Not Be Specific to Debian".
>>
> 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.
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.
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.
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.
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.
"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.
That's not going to work, either.
>> > However what I want is being noticed somehow about changed versions
>> > of my programmes.
>>
>> That's OK. It just means you need to upload to non-free.
>>
> I hope that will not pose an unnecessary restriction to the
> re-distribution as
> the program may f.i. also be especially useful under the
> rescue-console.
I'm afraid this WILL pose serious restrictions on the program, as
non-free is NOT part of the official Debian distribution. Software in
non-free are generally not included on DVDs or CDs or any other material
one normally uses for rescuing purposes.
>> 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.
If you mean that any derived work needs to remain under the same
license, that is of course okay. But the whole "free of charge" thing
needs to be rethought (see my comments above).
>> > Well to me it is an issue under which license to publish. I do not
>> > want to burden
>> > my distributor unncessarily but actually want to retain as much
>> > rights as possible
>> > because writing, maintaining the software and supporting also casual
>> > users is a
>> > major effort.
>>
>> It's a lot more effort for the distributors to review this license and
>> attempt to figure out how it applies in different jursidictions, with
>> other licenses and how to properly comply.
This. It's a pain in the backside to review a custom license, especially
one not written by a lawyer who understands the delicate properties of
the law. There are many errors and loopholes in your license, that would
need to be fixed before we can discuss including your software in
non-free, let alone main. And to be honest, it's not worth the effort to
do that. So, please, use a well known software license, it makes
everyone's life far easier, yours included in the long run (as you won't
have to deal with silly little details you would never have thought of).
Based on what I've read so far, you want your software to remain free
software, and you want to know about modifications. There's a very good
license for that, and it's called the GPL. It does not require people to
contact you directly, but it does require them to publish their changes.
And most often than not, the easiest way to do that is send them
upstream. In my experience, this works beautifully.
--
|8]
Reply to: