Re: [License-discuss] [Fedora-legal-list] Re: The license of OpenMotif (Open Group Public License)
Tom Callaway dixit: >On 10/26/2018 11:32 AM, Adam Jackson wrote: >> So if it's not as free everywhere as it would be in Debian, >> it's not free enough for Debian. > >It has never happened that I know of, but if there were a copyright >license which was somehow okay only in Fedora (but not for anyone >downstream of us), we would not consider it acceptable either. It’s the same in the BSDs. The “freeness” of the OS/distro is a promise to its users, not just a means for itself. bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: W3C FSA (Final Specification Agreement)
Hi Ben >So it's essential to know what is the specific *grant of license* from >the copyright holder to recipients of the work. I posted you the specific grant in my previous eMail, did you not see it? >>>Where is the text granting specific license in that work? >> >> >> >>So, as I said, pretty much irrelevant here. In general, grants say “this is licenced under X”, unless specified otherwise, and a generic review for this is to be possible. (In this case, this is also the actual specific grant.) The wording is only really relevant if either the licence is embedded in the grant, as in the BSD camp, or in the specific case of things like GPL versions. This affects actually a minority of licences. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Re: W3C FSA (Final Specification Agreement)
Hi Ben, >> Please keep me in Cc as I’m not subscribed to the list. > >Done, but if you want to continue this discussion please do subscribe so >you don't miss messages. meh. I can always check the web archives if someone misses this. >> I don’t think this has been covered yet, and, while I don’t have >> immediate need for this, it awoke my curiosity. > >Is there a specific Debian package (or ITP report) for this work? No, as I said, pure curiosity. >To allow the archives to retain the context for the discussion, and >because the same URL can often lead to a different text at a later date, >we prefer to have the text being discussed reproduced verbatim: OK. >> Is this acceptable for Debian? > >Debian doesn't consist of licenses; it consists of software works under >specific grants of license. Last time I looked, there was no difference in practice except for the GFDL. So, DWIM ;-) >Are you proposing a Debian package of the MusicXML standard? Or some >other work? I was wondering what to do if there was a piece of software containing the MusicXML specification or DTDs as part of itself. >Where is the text granting specific license in that work? So, as I said, pretty much irrelevant here. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
W3C FSA (Final Specification Agreement)
Hi, I don’t think this has been covered yet, and, while I don’t have immediate need for this, it awoke my curiosity. From https://github.com/w3c/musicxml/issues/114 I see that the latest version of the MusicXML standard is published under the W3C FSA: “The FSA Deed is available at: https://www.w3.org/community/about/agreements/fsa-deed/ “The FSA agreement itself is at: https://www.w3.org/community/about/agreements/final/ Is this acceptable for Debian? Please keep me in Cc as I’m not subscribed to the list. Thanks, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Ángel González dixit: On 30/07/14 22:00, Stas Malyshev wrote: You could not distribute other derived products bearing the name of PHP - but distributing PHP itself is fine, since it's not a product derived from PHP but the actual PHP. If Debian OTOH decides to make their own The actual PHP is still normally patched in a distribution. + 4B= On the other hand, minor patches to products already containing Absolutely no! That would make the situation much worse. This is very vague language, which will not help but add insecurities. There is some ambiguity on what is a B+minor patchB;, but I feel it's better to leave that to the courts should a lawsuit really arise (which would be a The very idea of a distribution doing licence review is to avoid things that could possibly, ever, go to court. or later. Use Common Sense for determining if it's a minor patch. That does not work in a legal environment, unfortunately. This is why the OSI (and many others) say to please leave writing licences (code for the scripting language called legalese) to experts (lawyers), just as we’d not want the lawyers to write C code. Would this change have the blessing of Debian and the approval of PHP? I highly doubt it. The current php5 source package in Debian has 49 patches… on top of a 5.6 release candidate. Things like porting to new platforms, etc. are not minor. One is named “hack-phpdbg-to-explicitly-link-with-libedit.patch”. You could say that every distribution makes a fork. Looking at a BSD… there are 34 patches in MirPorts for PHP as well, though the licence information there is set to say that binaries may not be redistributed. Another option would be to simply rename PHP to… Icescriptinglanguage? ;-) bye, //mirabilos (Debian Developer, but also MirBSD founder) who’d personally prefer to just shut up and hack instead of dealing with legal issues… -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour” -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1407310720520.23...@herc.mirbsd.org
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Ángel González dixit:
Please remember that we are just talking about changes that Debian
itself may want to perform (so it doesn't require a renaming which
would be bad both for PHP and Debian users).
Right, but Debian probably (though it’s up to Ondřej Surý, the
maintainer; there is no central instance) would not want to accept
a licence that says “you may keep the name if your patches are
only this small, and if they get bigger or disagree with what
we say, you may not keep the name”.
There is innovation, writing of new code, and patching code when
the packager disagrees with upstream (or – worse – when tech-ctte
says so because some *other* maintainer within Debian is important
enough for them to judge to not force him to fix the bugs in *his*
package instead, and so the packager is in the minority and forced
to deviate from upstream, so that the package still fits into the
distro).
Also, Debian is a bit of promise to downstreams. I am not sure (I
did not specifically look at this part), but I think downstreams
should be able to not need to look at how _much_ patching the
licence allows…
Looking at a BSDb as well,
I count only 20 :S (all minor things, some that should have been done at PHP)
There are some hidden in ../{core,extensions}/patches/
(As an aside, it's sad in general to check package patches, since most of them
should really be at upstreamb
Right. It’s been problematic (and doesn’t scale well when
you’re a small project) to get patches for a non-mainstream
OS into upstream (though the situation did get better over
the years). In fact, most of our patches are carried over
from OpenBSD, who also either did not submit them or did
not have luck with that. (Though their relationship to both
their upstreams and downstreams is a bit special anyway.)
though the licence information there is set to say
that binaries may not be redistributed.
You are creating the patches with a license not allowing binary
redistribution?? You leave me speechless.
No, what I meant is: the port metadata says that we may not
distribute the binary packages.
It’s your licence which forbids that ;-)
PS: The cvs daemon at anoncvs.mirbsd.org doesn't seem to be listening on its
IPv4 interface (81.169.181.30).
There is no cvs dæmon, it’s anonymous CVS over ssh. (Nobody
sane uses pserver – it’s susceptible to MITM and all.)
(And yes, I’m gonna update that thing some day… but for what
I’m currently using it, that old beast serves well enough…)
bye,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/pine.bsm.4.64l.1407312028310.12...@herc.mirbsd.org
Re: Re: [PHP-QA] Debian and the PHP license
Pierre Joye wrote: As Rasmus, and I, said numerous times, the PHP License is a perfectly valid choice as long as the software are distributed under *.php.net. This reading clearly fails DFSG#3 and OSD#3 at the very least, and makes *all* software using the PHP Licence non-free, because redistribution of derived works is only permitted from *.php.net which is clearly inaccep- table. This makes not just forking the software impossible but also dis- tribution of binaries made from modified sources, for example. On the other hand, my own reading of the PHP Licence is that we may not, in fact, distribute (binaries of) modified versions of PHP software (the interpreter as well as everything else under that licence), period - but that distributing the original source alongside patches is okay (e.g. as 3.0 (quilt) source package). Since Debian isn't distributing source pak- kages, this does not help us. A written permission from gr...@php.net is not helpful either, because of DFSG#8. (In BSD ports, we also do not distribute binaries of PHP.) I think you should rethink your stance and the PHP licence on all of the issues listed. Similar issues arose from the Firefox trademark after all (and it would be fun if Debian distributed Icescriptinglanguage, instead of PHP, except for those affected). bye, //mirabilos -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lrajm9$j5p$1...@ger.gmane.org
Re: [PHP-QA] Debian and the PHP license
Lucas Nussbaum wrote: However, based on my own (possibly limited) understanding of the issue[1], this is case of a license (the PHP License) with sub-optimal wording that is misused by third parties, as it was initially designed for PHP itself, and is used for random software written in PHP. That, too. But AIUI that licence also forbids us from shipping a modified version of PHP without rebranding (like Firefox(tm)). bye, //mirabilos -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lrb022$oik$1...@ger.gmane.org
trademark vs. renamed derivates
Hi everyone, is there any example language for something like the following around already, which I could reuse? “This software Y is based on the software X, which was written by the company Z; both X and Z are trademarks, but Y is not, nor do we intend to use these trademarks (which is why we renamed it in the first place), but we mention this because this is a derivate and we want/must name the initial developers, but don't want to infringe on their trademarks either, so what do we do?” Thanks, //mirabilos -- 15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1407211722420.3...@tglase.lan.tarent.de
Re: Ghostscript licensing changed to AGPL
On Wed, 7 May 2014, Bálint Réczey wrote: 2014-05-07 14:37 GMT+02:00 Thorsten Glaser t...@debian.org: Which you may want to do, in order to patch a security issue you just found, locally, before filing it upstream. In my interpretation in this case I would have some reasonable time to comply, i.e. I don't have to publish all 0days on my site if I run AGPL-covered software.. No. The licence does not provide for such a delay. Or because you’re a user of Debian and used to be able to do just that. Hmm, as a Debian user I'm used to respecting the license of any software being it BSD, GPL or AGPL... Right, but the AGPL (and, to some extent, the GFDL… I smell a pattern here) are unique in that they restrict usage without reproducing the software itself. On Wed, 7 May 2014, Clint Byrum wrote: The things that link to ghostscript as a library will now need to be evaluated. If they are contacted via network ports, they'll need to have source download capabilities added. This is impractical; upstreams will probably just answer to use an older (or the commercial) Ghostscript version. Where the AGPL fail to be clear, is when we ask what to do with a program which listens over the network, and executes an AGPL licensed program. The AIUI the AGPL triggers if the program is accessed over the network; local execution does not normally use “the network”. If the program executing it is called over the network, it does not directly expose the AGPL software, but to draw the line is very hard. Also, see below. On Thu, 8 May 2014, Riley Baird wrote: Should it then communicate that it is Debian version X and that the source can be found on any Debian mirror near you? What if the network in question is not the internet? Right, the AGPL is not technology-neutral. I have to agree with Francesco Poli here that the AGPL has no place in main, not just because of its freeness but also because of its impact at reuse and maintainability (think security updates; we had this in the Berkeley DB 6.x thread already). bye, //mirabilos -- 15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1405081138520.20...@tglase.lan.tarent.de
Re: Creative Commons 4.0 licenses published
On Thu, 28 Nov 2013, Paul Wise wrote: Mike Linksvayer suggests upgrading to CC0 instead: This is not a good idea: CC0 is up for a rework too, they just decided to get CC 4.0 out of the door first, and the current CC0 version is *explicitly* discouraged for use with software. (Also, Public Domain without a fallback copyright licence is problematic, which is why CC0 needs very careful review.) Go MIT or MirOS instead. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.10.1311281200350.8...@tglase.lan.tarent.de
Re: [License-review] For Approval: Scripting Free Software License, Version 1.3.5 (S-FSL v1.3.5)
FWIW, the GMane thread view for the Debian bug on this is: http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/1099104 The bugreport is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728716 although I’d have put it into the ITP bug #721447 instead. Elmar Stellnberger dixit: What about binaries? such as python, bash or perl. As the license says nothing about binaries I would presume that it is not forbidden to derive such binaries as long as the No, binaries are derived works. However at some point we do strongly recommend to get all changes incorporated into the main line. I believe it would really become a problem if the software is unmaintained or incompatible upstreams. However for this case we can either This has led to catastrophes, but also to improvements (full forks). I think you’re too restrictive here, especially for the all of the OSS ecosystem. one; not which one. The way I conceive things it is a right of the user to know who has changed what. Everyone who does a change to the software will be There’s CVS for it ;) and drop everything to the community we have a huge quality problem as no one feels responsible for the outcome. I don’t think forcing people like this would help. [ desert island ] As far as I have studied law if there is a force majeure that prevents you from notifying the original authors or if there is some unreasonable burden to do so then you do not need to do that. - and on a desert island force majeure is Yes, but this is a metaphor for less “majeure” things. Please do not assume special provisions for the “desert island”, otherwise the test’s metaphor will obviously fail – it’s used to help comprehend the issue *behind* the test, not for its own good. upstream party will thus be o.k.. Note also that public distributors do not need to notify at all; only 'closed' distributions which obfuscate their sources need to. Consequently I would regard this as minor infringement. You don’t define “public distributors”, and this will make some parts of the licence specific to certain people _and not their downstreams_ which is an issue. […] program and finally coded it in the first place. Invention includes primary requirements engineering. S-FSL assumes a proper software engineering and […] I think your ideas are really right, but trying to put them into this form will not work out. People do get along with the already-approved licences plus *asking* (but not legally requiring) to e.g. keep the “powered by FusionForge” comment on the output HTML, plus *reminding* people that things used in academic papers *must* be cited/acknowledged properly and that this-and-that is the correct citation for this piece of OSS software. For this, these things do not need to be in the licence. And, I think removing copyright/authorship remarks is not legal either so it doesn’t need to be explicitly required (maybe mentioned, sure). group denominated as new copyright holders. The bottom up development approach that is 'hack and drop to the community' is the way I believe rarely a good Sure, the hack’n’drop is bad, but: Please do not put all bottom-up development into that category though. I find bottom-up SWE (after designing, of course) very nice for smaller things, basically where you can have an idea in your head. (But this is going off-topic.) starting point for high quality assurance. IMHO this doesn’t belong into the licence. Maybe in an academic or commercial environment, yes, but definitely not in OSS. Also the design of the initial inventors should be followed by later contributors. This is a point I am prepared to vehemently disagree, by pointing out that some peoples’ designs just suck. You may not fall under it (I’ve looked at your website to see what the programs mentioned are, but not at the code itself), but I know others who most certainly do. (Incidentally, they seem to end up at RedHat.) My argument against this is that patches for my software can not be produced without my software Forward ed(1) diffs with no context can. (Mostly §24 UrhG which is especially interesting for Fanfiction, not so much for software.) Parts of the new code may need to be written in order to fit with the existing code, but that’s just interfacing. and are thus to be regarded as derived works. And here we also disagree: if forward ed(1) diffs can be works of their own, so can be unified/context diffs iff the country in question permits “fair use” (Germany doesn’t but the USA do). It can never be seen independent from the program it was designed to patch because otherwise it would be meaningless. Leaving mathematic terms aside (I tried hard to forget them and am in no particular mood to figure out which ones to use), yes, a “patch” can contain (and thus be) an independent work; for example something written for another program and then just fitted to match the interfaces of yours. (This is, incidentally, the reason nobody can
Re: [License-review] For Approval: Scripting Free Software License, Version 1.3.5 (S-FSL v1.3.5)
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
Re: Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
On Mon, 4 Nov 2013, Paul Tagliamonte wrote: This license will be considered non-free in Debian. ACK. We have a thread about this on the OSI mailing list as well: http://projects.opensource.org/pipermail/license-review/2013-November/thread.html starting at http://projects.opensource.org/pipermail/license-review/2013-November/000679.html I’ve raised my concerns there, as did others. bye, //mirabilos -- http://tapoueh.org/images/postgresql_versus_mysql.jpg -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.10.1311061105430.14...@tglase.lan.tarent.de
Re: incompatible licenses in the debian directory
Paul Tagliamonte paultag at debian.org writes: So, the way *I* see this is so long as the GPL code isn't being put into a combined work with anything (e.g. GPL'd patches), it *should* be OK. Unfortunately, GPLv3 considers build scripts (thus, d/rules plus the input for the declarative dh* commands, plus d/control which is parsed by some, etc.) to be part of the “complete” source code. This means that even the previous maintainer was unable to legally upload the package with debian/* being GPLv3, unless he added an exception. Make out of that, consequences-wise, whatever you want… just saying… there have been precedences of upstream being forced to relicence because they have distributed something they couldn’t under the choices they made themselves. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130927t150424-...@post.gmane.org
Re: incompatible licenses in the debian directory
Paul Tagliamonte dixit: This is a GPL restriction. Since the upstream code isn't GPL, why are you using a GPL argument about build scripts? -- in theory this would apply to build scripts for the GPLv3'd debian/* files, but there are none that Hm unsure. It really depends on how far you acknowledge the virality of the GPL – Debian, AFAIK, tends to go more with the FSF’s extreme interpretation… But if the new maintainer is willing to completely remove the old stuff that’s probably the best outcome, considering the old maintainer is unwilling to cooperate. (Personally I think debian/ should be permissive, especially if there’s not too much “magic” in it… and others even think there should be no magic in it…) bye, //mirabilos -- gcc ncal.c: In function 'parsemonth': warning: comparison between pointer and integer • mirabilos ↑ hab da „in function parselmouth“ gelesen Natureshadow ICH AUCH! • Natureshadow Ich hab gerade gedacht Häh? Wie, hab da parselmouth gelesen ... steht da doch auch :o? -- too much fanfic… -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1309271522590.30...@herc.mirbsd.org
Re: data and software licence incompatabilities?
Clark C. Evans cce at clarkevans.com writes: Francesco Poli has been a longtime subscriber to the debian-legal mailing list. He has quite extensive knowledge about licensing, and is often the first person to answer inquiries about new licenses sent to the list. Not only that, but he reaches out to help you personally and does an excellent job on giving a fair shake to opposing view points. It'd be a serious loss without his involvement, even if I disagree with him. And that is why I suggested to him to become a DD. (I’m not in favour of a list ban if it can be solved otherwise.) (By the way, I just looked, DD is the term for both packaging/uploading and nōn-uploading project members.) bye, //mirabilos -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130904t150801-...@post.gmane.org
Re: AGPL request for summary of recent discussion
Paul Wise pabs at debian.org writes: Likewise. I don't appreciate the disrespectful tone some folks have displayed in this and other recent threads. I would like to remind Oh great, and who’s going to deal with trolls then? You’re not holding Francesco to them, I’m noticing. I’ve heard that Francesco is the reason people are considering unsubscribing from this list. Yes, it’s *that* bad. I do *not* think we should keep the velvet gloves on every time – but if you want to do that, feel free to, just ignore me. (And, for the record, I did try to make constructive suggestions how Francesco can try to get his point across better.) Sorry I’m brutally honest. And yes, I stand by my actions. And, tbh, if this is official (someone finally says something against a long-standing annoyment, to the rejoicing of other people including DDs who suffered under said annoyment, only to be flamed by people who have failed to contribute so far) I can understand unsubscribing. It’s “only” Debian that suffers. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130902t131005-...@post.gmane.org
[OT] Re: AGPL request for summary of recent discussion
MJ Ray mjr at phonecoop.coop writes: Well, we hear things like that every time someone doesn't agree about In this case I talked with other DDs on IRC. whether software follows the DFSG or not, yet the number of subscribers seems to be generally increasing towards some asymptote http://lists.debian.org/stats/debian-legal.png You know that l.d.o is not the only interface to those lists, right? I noticed a suggestion that Francesco should work to become a DD because he's not even a Debian Developer! which seems a bit of a throwback to the non-package-maintaining contributors not welcomed dark ages. Even DD does no longer equal “maintaining packages” (I notice we do not have a short term for “nōn-packaging project member” because DM is already used for packaging nōn-members). And I really meant DD as in “project member” here. I also noticed a suggestion that Francesco should shut up and then try to convince the project about the problems with the AGPL from within(huh?), which seemed rather absurdly destructive to me: how does someone convince others without explaining the problems? I never said he shouldn’t explain the problems. I merely suggested he explain it in places where they can be addressed instead of in the place where Debian contributors go when they want advice on the project’s position on something, or sth. like that. Maybe this explains my reasoning better? If it does, EOT from me. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130902t222406-...@post.gmane.org
Re: AGPL request for summary of recent discussion
MJ Ray writes: Look, […] My reply was specifically to this newsgroup, a long-needed “request” to shut up, and explicitly *not* soliciting *your* personal(!) opinion on those licences either. I do not require the “added value”, and this newsgroup is spammed enough by the likes of you two. Besides, linking a bugreport from 2008 when I specifically asked whether anything had changed as result of the recent, i.e. last quarter year, discussion, was absolutely ZERO added value. Francesco Poli invernomuto at paranoici.org writes: You asked whether it's still acceptable for Debian main: I answered by describing what the FTP Masters think Look, as I said above, that was 2008. Not the recent discussion. *And* paultag already answered by question, to which you even REPLIED, so you KNEW your answer would be redundant. and what I myself think. I absolutely am NOT interested in your personal opinion. Heck, I looked it up: you’re not even a Debian Developer! If you want to make changes and care about licencing, how about being constructive and starting on that path, then working together with ftpmasters on resolving all these issues? (Again, I personally do not think AGPL, and possibly even GPL, are fully DFSG free either, and I’ve got a totally different opinion on firmware, with backing, but when I act as Debian Developer sponsoring a prospective NM’s packages, I act with DD hat on, not by using my own opinions.) My own opinion was just a side-note. Yes. What annoys people is that you solicit it in EVERY THREAD in this newsgroup. Stop that, period. I am surprised to see that you are so annoyed by my answer, which described the official Debian position on the AfferoGPL The one from 2008, and in a redundant message, since paultag already answered my question. *That* is the annoying thing. It really makes you look bad. I thought I could add some more information. You apparently didn't appreciate it. Oh, well, that's a pity. Do not trivialise your response. You’re acting on an agenda, one that can clearly be seen by you soliciting, unasked for, your opinion on this-and-that licence in EVERY thread here, disagreeing on principle. (Hey, that’s my job! ☺) Anyway: stop annoying people like that and try to be constructive by changing the official project stance on those problematic licences from within as an option. But first, “shut up”. bye, //mirabilos (with backing from other DDs in this group, by private mail) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130901t190342-...@post.gmane.org
Re: AGPL request for summary of recent discussion
Francesco Poli invernomuto at paranoici.org writes: In the recent discussions, the main concerns were about the switch of a Yes, I know, but the discussion was raised, so I wanted to make sure. So, is AGPLv3 still acceptable for main? For the record, I personally disagree with their conclusion: Francesco, I specifically did *not* ask for your personal opinion but whether it’s still acceptable for Debian main. I even wrote in my original message that I’m not exactly happy with AGPL either, but you writing your personal disagreement with everyone else in *every* *single* *thread* I happen upon on this newsgroup is, to say it frankly, annoying. (Especially since I, who normally is the annoying one, notices it.) Please do not take this personal, merely as a suggestion to improve your communication behaviour (meaning, sometimes silence is golden; since paultag already answered my question your message had precisely zero “added value” to the thread). bye, //mirabilos -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130829t171256-...@post.gmane.org
AGPL request for summary of recent discussion
Hi, there were several threads around AGPL recently, mostly re-stirred due to Horracle using AGPLv3 for Berkeley DB. I was unable to follow them totally and remember there being raised at least two points: • The inability to provide security support for AGPL software (embargoed fixes)/ • The requirements for source delivery using the network once someone patches it. • The “viral” component, like GPL, only worsened by the above. I’d like to see whether there was anything decided, since I’ve been asked yesternight to sponsor some packages, and one of them contained AGPLv3+ code (and it’s a plugin for an LGPLv2.1+ program, so I asked the prospective maintainer to hit upstream with a big foamy cluebat about their choice of licence – which he did – since it’d Conflicts with e.g. GPLv2-only plugins). So, is AGPLv3 still acceptable for main? Personally I’m ambiguous, but then, I’m not a fan of GPL either. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130827t135650-...@post.gmane.org
