Elmar Stellnberger <estel...@elstel.org> writes: > Am 04.11.13 18:43, schrieb Paul Tagliamonte: >> >> >> >> On Mon, Nov 4, 2013 at 12:42 PM, Paul Tagliamonte >> <paul...@debian.org <mailto:paul...@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] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org