Elmar Stellnberger dixit: > Yes, they are and the license does currently not give any restriction about > them
Except for forbidding them all, because patches must be distributed separately, and distributing patched versions is forbidden. > However it is not an OSD criterium Independent on whether it is or not (it’s not explicitly listed, as are other things people have commented on, but some of these things can be inferred from the OSD), I said in my first eMail that I’d do a general comment on the S-FSL, no (pure) OSI review. (For that matter, I’m also lead developer of both a BSD and a GNU/Linux distribution, *and* a Debian Developer, too, that’s why I have feet in multiple camps.) > However if there is some > broader effort to establish new features I would simply consider it good style > to notify the upstream maintainers. The software below could change. I agree, but it’s much better to just _request_ it. Sensitive people will upstream their patches anyway (if upstream is reachable), since not doing so massively increases maintenance burden, especially when keeping up with active upstream development. > "specific to someone": Well this is an unavoidable necessity in order to Maybe, but specific clauses like this clearly violate OSD #3 and #5 (#3: if your downstream “A” is a “public distribution” and A’s downstream “B” isn’t, B cannot distribute them under the same terms as it got them from A under). > Someone who obfuscates his modifications can hardly claim possession > on my work. Of course not, only on their changes, but that is generic. > move it to another place; i.e. from the help->about menu to some obfuscated > place which should not happen either That will make it a forbidden invariant section. You cannot, in OSS, prevent people from doing so, period. (In this case you’d probably be better off with the GNU AGPL, because it does what-you-really-want in a more OSS way than what you’re trying to do.) > development. Top down in its primary sense simply requires some sort of > privileges and control. But too much of it and you can’t call it OSS any more. > That is where I argue with homomorphism. You can strip a full context diff > into > a no context diff. Consequently the no context diff is a derived work of the > full context diff. Oh, but copyright law does not work this way. For example, I own all of my (copyrightable) sentences in this eMail that I wrote, but none that you wrote. You own all those you wrote, but none that I wrote. If someone cites a sentence I wrote in this eMail, it doesn’t mean you’ve got any rights in the thing that other person writes citing my sentences. >> in question permits bsee the homomorphism and transitivity issue: A derived I seem to be unable to read your eMail, can you please configure your MUA to send as quoted-printable or base64 instead of 8bit because at least on of the mail servers between your MUA and my inbound MTA is violating the SMTP standard? (And while at it, *please* wrap your lines at, at most, 72 columns.) > If it is independent work I believe it should be distributed as such. > i.e. as standalone file rather than as a patch. In your scenarios, patches are standalone files. > To me a patch is something that refers to the part which is to be patched. Ah. That’s a rather narrow definition. I have a combination of a Debian source package (with all red tape this requires) whose debian/rules unpacks a *.deb then runs forward ed(1) diffs on the contents and regenerates some things like md5sums then repacks it. The debian/rules script is a patch, as are those forward ed diffs. Yet, they are not derived works of the .deb that’s binpatched, only the result is. Hm. Actually, maybe the better term for these is “compiler”, as this sounds awfully like what gcj does when compiling *.jar files into *.so DLLs. But it’s still oftentimes referred as patch… > Can you explain it any further why it won`t work in practice? There are packages whose distributors carry patches rejected by upstream, over a disagreement. > Contracts with the authors of the patches? Yes. > I think S-FSL as well as the DEC SRC > M3 license make sure this is not required because it may not be possible to > ask > any contributor with hindsight. They need to agree in advance or work on their > own branch possibly with other license. That makes these things non-free, too. >> But in Open Source, the right of the user to fork the code (e.g. if >> they disagree with upstream) is basic. > I doubt whether this is enforced by the OSD criteria #1-#10. You could deem it “The license shall not restrict any party from selling or giving away the software” plus “The program must include source code, and must allow distribution in source code” plus “The license must allow modifications and derived works, and must allow them to be distributed” and OSD#4 doesn’t permit the author to restrict downstreams from distributing patches *and* patched versions. In this case, yes, the right to fork is written in the OSD, and this part is an explicit OSD analysis ☺ bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles kaputt? :) 15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders… -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311072000210.27...@herc.mirbsd.org
