http://blog.gmane.org/gmane.user-groups.foss.libreplanet hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1067 <pre> Postfix for SMTP, SpamAssassin, Pyzor, Razor, DSPAM, procmail, mutt, and some custom code that looks up the AS number, GeoIP, and RBL memberships of incoming IP addresses. I use Postfix, procmail, and mutt more or less unmodified. By themselves, they'll easily handle hundreds of thousands of emails per day on a modern server machine, so they'll serve the needs of a few individual users many times over. Spam filtering is a whole different matter. If you're not intentionally running a spam trap and you get less than 1000 spam per day, SpamAssassin and DSPAM on an entry-level dedicated server is fine, as long as you pay attention to what happens under worst-case load conditions and plan/configure for them (e.g. if your VPS has 1024MB of RAM it can reliably filter no more than two or three emails simultaneously, so the MTA default limit of 100 local delivery processes at once is probably too high). My custom AS/GeoIP/RBL lookup code isn't really important. Only the RBL lookups are useful for spam filtering, and SpamAssassin already does those. The GeoIP and AS number lookups had to be debugged and working so I could get the data that shows they're not as relevant as RBL data, but I've had no reason to take them out since (and it's kind of nice to have a header in every message that says what ISP and what part of the world it came from). I also publish some graphs on how often the RBL memberships match the final message's spam status, and those graphs need data different from what SpamAssassin provides. I run SpamAssassin configured to run only its static rules engine and network checks, and annotate messages with lists of matching rules in the headers; however, it is DSPAM that ultimately decides whether a message is spam or not. SpamAssassin's false positive rate is far too high for me (well over 0.1%, which would make lost mail a weekly event), its algorithm for combining rule results (adding scores) makes no mathematical sense, and its machine learning storage backends are too slow to keep up with my mail load; however, SA's static rules can identify pattern-based message features like "fake Outlook headers" or "looks like Nigerian 419 scam" and the network checks can add information like "listed in Pyzor" or "contains blacklisted URI" which help DSPAM make better filtering decisions for specific flavors of spam. DSPAM is a Bayes classifier, so it automatically learns what my non-spam email looks like (and which SA rules and RBL listings are reliable indicators of non-spam or spam and which are noise). The price for configuration simplicity is that I have to provide timely feedback to the filter every single time spam gets through (or non-spam gets trapped), or DSPAM learns the wrong things. I have macros in mutt to retrain the filter on misclassified messages, so in practice this is a single keypress per message. Any Bayes classifier will work as long as it looks at mail headers (beware, some do not!). What I like in particular about DSPAM is the API for remote storage, so I can split filtering between one machine that has access to the readable message text and another that has hashed token statistics. A well-trained spam filter can end up knowing who your friends are, where you shop, where you live, and what work you do, so the token stats DB has some privacy implications. DSPAM's architecture helps since the DSPAM data store is not as easy to read as a folder full of plaintext email messages (though it's still possible to extract some private information with a dictionary attack). Presumably you are not visiting your VPS mail server in its data center, so if you have a significantly more capable machine to run your MUA you can do the spam filtering on that, and let your VPS server handle only unsophisticated MTA and storage tasks. Having used both, if I had to build my mail server again, I'd use Exim instead of Postfix. Postfix has a lot of configuration restrictions designed to protect unsophisticated administrators from their own ignorance, like not being able to use back-references in regexp rules, or having to jump through obscure hoops to match multiple SMTP envelope fields in a single message (e.g. you want to redirect a message when client IP = x AND recipient address = y). In practice I want to do these things fairly often. Exim can easily express these kinds of rules in its configuration language, but Postfix requires external mail filter daemons, internal code changes, or non-default build options. If it's a personal Gmail account you can set it up to do SMTP forwarding (Google pushes to your server) or enable IMAP access (your server pulls from Google, e.g. with fetchmail) on the Gmail side. I use IMAP because IMAP lets me scrape my Gmail Spam folder (Google false-positives almost as badly as SpamAssassin, and the SMTP forwarding will not forward anything it believes is spam). This lets you transition gracefully to a new email address. In the future, when the only people sending mail to your Gmail address are spammers, you can turn the Gmail account off. Pick a MUA (or set up an IMAP server) and a spam filter, set up local delivery, and you're mostly done already. </pre> Zygo Blaxell 2013-05-22T17:46:14 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1066 <pre>Le 21/05/2013 22:03, Ted Smith a écrit : [EN] I would say rather that the free software take more and more space in society, and Gloogle sees just an additional outlet and if possible with the backing of the free software. ----- [FR] Moi je dirais que le Logiciel Libre prends de plus en plus de place dans la société, et que Gloogle y voit plutôt un débouché supplémentaire pour fourguer ses solutions et si possible avec l'aval du Logiciel Libre. Librement. Mimmo D.DN </pre> d.dn 2013-05-22T13:27:54 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1065 <pre>Dnia wtorek, 21 maja 2013 o 10:08:24 Alexander Berntsen napisał(a): This just in - DuckDuckGo fires up their own XMPP service: https://dukgo.com/blog/xmpp-services-at-duckduckgo DuckDuckGo seems both willing and able to offer a viable, privacy-friendly alternative to Google, and I am very happy to see they are also seizing the moment to roll out another service and try to challenge Google on yet another market. </pre> Michał 'rysiek' Woźniak 2013-05-22T06:38:53 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1064 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lavabit.com offers gratis mail and XMPP, being very concerned about privacy: https://lavabit.com/personal_e_mail.html (I pay for extra features, but non-paying users are not left aside; see the page for more info). Em 21-05-2013 12:20, Carlos Solís escreveu: [1] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJRm6NMAAoJEN9QbufXvqzWcZ8QAJumWWQ7O7TRcFANUnrswwGS LTMAqMO/0vzsiZT1VNQBs5OHxksI7LVVk1e5C036394WpWvjwYXadxnMg5usl5sc bmtTXrWJ1cgbR3K+imIhMsn89ghSJ4N4Fx8LDfiGON/Z70OvMTe/Kbzym9gLf1Fm QPKdegsMtKyn3BDZ5+4Fsg/Y01J+FfQD1ioXJLJiGGpP7BeMClIgm9WQv++cqJD3 6d/Y6bJ5ZpZRnjUarqSYQ6wAQlRmI7tZ/zWkw+VP9QJiOddtffv5o80pkd3h4DQb Ya37W6ZvPH/RYzWVnvnoAmoqeWVxpyKHrOViHzhxWVHrY2Hayd5/HcGjFn82hl1c bRD4WHKBzMfzvNHdoKeGhOw/JKdMWZYy39CaC1SSp4mxrzzYpr3oth2+/Fy7NW+h tV8aIbe4ZRuhR4ra3Qg26STTWx9n209JiUQL+zWUxp0nXTjZTl1c9AlmEzarVTVa gZxGHm5iqQqfJQotsbb27gF3/bT1M3YK058+FF/wPYRLuDO2zqq83J04lwfPMSKa dyIlKdQcWyVYbUcQHiLaK5usDTrFQvghWDPzsQ4pXJyD1aRxx1R6nzFqLYSLUGKE 1EKiLLj3guM4Gg8SZA+/Isbnq6eguLxHcljEGQm2OVrNUv46nthDB/U9Ttz7keQe PuAMpuyeoLzHo+SgiUML =mES4 -----END PGP SIGNATURE----- </pre> Gustavo C. M. 2013-05-21T16:39:49 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1063 <pre> I never said "let's stop trying." I just said "Google Glass doesn't make our existing situation worse, just more blatant." The concepts behind Glass have existing for a long time (there are several people with libre homebrew equivalents that have been wearing them constantly for decades now). It adds nothing new but packaging. We have to keep trying. This is a very head-meets-sand reaction. You (hopefully) interact with people in public, around other people carrying mobile phones running proprietary software. Interacting with someone wearing Google Glass doesn't seem meaningfully different to me. Again, Glass just makes existing problems more blatant. Reacting as if it imposes new problems is short sighted and counterproductive. Well, there are some technical solutions: http://cvdazzle.com/ But it isn't clear whether they're sustainable. Computer vision is a hard, mostly unsolved problem space, and the ability for computer systems to perform meaningful surveillance against an active defender isn't yet known. It's possible that there are algorithms that can get around things like cvdazzle. It's also possible that there aren't, or that they're so expensive that cvdazzle is a practical act of asymmetric warfare against surveillance apparatuses. Well, you won't get Linux.com to toe the LibrePlanet line (and I will give you good odds that doing so is a waste of time for any near-term time frame), so the only thing you can do is respond in an effective way in your own media. The question is how. Glass probably auto-uploads pictures and videos the user takes to Google Plus/Youtube. So this is mostly correct. But this is probably a feature you can disable, and have reasonable trust that checking the "disable auto-upload" box will result in it not auto-uploading your pictures. Not even Google can blatantly lie about privacy issues. The Glass hardware has already been rooted, however -- what happens when you have Replicant on Glass, or CM on Glass? The future is clearly trending towards pervasive surveillance. Computing devices and cameras aren't going to stop getting smaller and cheaper. Supporting free software *cannot* become synonymous with supporting luddism, or it loses. This is already dangerously the case. </pre> Ted Smith 2013-05-21T20:03:39 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1062 <pre> Actually, this event was more of a negative -- decentralized surveillance, and volunteer policing got several people falsely accused of being the bombers, and one person ended up being deported as a result. However, it doesn't seem like Google Glass would make this event significantly different -- events like the Boston Marathon are already heavily "surveilled" in a decentralized way. To try to tie this back to software freedom, there are a few things that you'd need to have safe decentralized surveillance: * The abolition of features like the photo auto-upload to google plus in Android. Any picture uploaded to G+ can't be "deleted" in any meaningful sense. This is a classic 'antifeature' from a privacy sense. * Free mobile platforms with the ability to truly strip any identifying metadata from media, allowing activists to share that media (possibly after editing out faces or other identifying characteristics) without fear of reprisal. Existing free software that already does this: Obscuracam, by the Guardian Project: https://guardianproject.info/apps/obscuracam/ The best google glass angle I can see is that having free platforms makes it easier to remedy privacy problems inherent in having pervasive decentralized surveillance. As it stands, Google could easily 'auto-upload' everything from all the Glass devices just because they aren't free, and turn decentralized (and mostly benign) surveillance into centralized (and highly threatening) surveillance. </pre> Ted Smith 2013-05-21T19:47:42 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1061 <pre>Alexander Berntsen &lt;alexander-DBtYv1bHjG2sTnJN9+BGXg&lt; at &gt;public.gmane.org&gt; escribió: I use a combination of Riseup[1] (for mail and XMPP), a public instance of Friendica[2] (for social networking), and Owncloud[3] (for file sharing and contact management). Unfortunately, the first and third are invite-only. I was lucky enough to get the invites, but most others can't. And since most people (myself included) have zero budget for a server, a donation-funded site that offers at least the services above is urgent, perhaps to the point of being in the FSF's critical list. [1] http://www.riseup.net [2] http://friendica.free-beer.ch [3] http://allthefil.es - Carlos Solís</pre> Carlos Solís 2013-05-21T15:20:52 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1060 <pre>Hi Zygo, What is your email setup specifically? Like, what software do you use? And does anyone on list have any experience with migrating out of Gmail to a self-hosted setup for email? I have a VPS, and I'm using exim to just forward messages sent to my domain to my Gmail account, but I would really like to be just keeping it all on my server and dropping the Gmail. If anyone else is in a similar situation, maybe we can work it out together. Cheers, Ramana On Wed, Aug 8, 2012 at 9:28 PM, Zygo Blaxell &lt; BPYZs1fx-NrEFc28nzVELdAb9qmlgy6J6PTuglH/l&lt; at &gt;public.gmane.org&gt; wrote: </pre> Ramana Kumar 2013-05-21T11:55:13 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1059 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 21/05/13 02:52, Michał 'rysiek' Woźniak wrote: I recommend not using Google for communication. Set up your own XMPP server, or use DuckDuckGo[0] or the Free Software Foundation[1] for your XMPP needs. [0] &lt;https://duck.co/topic/duckduckgo-s-new-public-xmpp-jabber-service-on-dukgo-com&gt; [1] &lt;https://www.fsf.org/blogs/membership/help-us-sign-up-71-new-members-by-january-31st-and-use-your-new-jabber-account&gt; - -- Alexander alexander-DBtYv1bHjG2sTnJN9+BGXg&lt; at &gt;public.gmane.org http://plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlGbK3gACgkQRtClrXBQc7XtJwEAgRajR41YBqmoHcpLWiThDWaV KU/Jcpt7HG7epZKaoxQBAJvO5612WUqhQC/nwcI/Mpdk10hNCVfzkVJwlcHlAzI9 =uKp/ -----END PGP SIGNATURE----- </pre> Alexander Berntsen 2013-05-21T08:08:24 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1058 <pre>Hi there, grim day for federated, decentralised IM is nigh. Google is dropping support for XMPP: http://windowspbx.blogspot.com/2013/05/hangouts-wont-hangout-with-other.html I'm just waiting when they decide they can do the same thing with e-mail. This is not as crazy as it seems, "everybody has gmail", right? </pre> Michał 'rysiek' Woźniak 2013-05-21T00:52:42 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1057 <pre> Hi Will, Congratulations, thank you for sharing such details. It's nice to see another LibrePlanet team organize and become more active! Make sure to let us know if you or anyone from your group comes to visit Quebec province, it's not too far :) Cheers, Fabian LibrePlanet Québec http://libreplanet-qc.org </pre> Fabian Rodriguez 2013-05-20T19:01:17 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1056 <pre> Great to see this! -john </pre> John Sullivan 2013-05-20T15:29:15 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1055 <pre>Dnia niedziela, 19 maja 2013 o 18:39:52 Adam Bolte napisał(a): +1 But they need to be redistributed with the text in question while at the same time being considered part of the work, and I can understand how that can be seen as a problem. If any part of the work cannot be modified under a given license, the license is not libre. Period. That's a strong assumption right here - that they "aren't harming anyone". I am not sure I completely agree. They do cause issues, as stated below. It would be enough to just look at reasons why Wikipedia decided to go CC-By- SA, and why WikiVoyage decided to not use GFDL at all. "Grief" is too strong a word, maybe, but there are valid arguments against using GFDL. I do not have a strong opinion on this, mind you (and this is why GFDL is not mentioned explicitly in my text). But I do see how the invariant sections can be problematic. From what I can tell GFDL with invariant sections is just an attempt at doing something CC-By-* with explicit attribution guidelines (you know you can decide how the CC-By-* mandated attribution is to look like for your work, right?[1]) does much better. GFDL and CC-*-ND/GNU Verbatim seem to come from different philosophical stances. Specifically, I think that it would be worthy discussing/writing about how the same that GFDL tries to achieve with invariant sections can be achieved by CC- By-* attribution guidelines in a way that is at the same time better, less cumbersome and less problematic to freedoms (as here the "invariant text" would be a part of the attribution, not of the work itself). And I would really love to see the GFDL documentation move to CC-By or CC-By- SA license (possibly with some specific attribution guidelines) to clear up the confusion and finally put this issue behind us all. [1] http://creativecommons.org/licenses/by/3.0/legalcode -&gt; Section 4(b) So for the time being for me GFDL is simply redundant, as CC-By-* can do the same thing while being less problematic (as it does not create some portions of the *work itself* that cannot be modified). </pre> Michał 'rysiek' Woźniak 2013-05-19T21:52:39 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1054 <pre>Dnia niedziela, 19 maja 2013 o 22:11:06 Thomas Harding napisał(a): That's because such people feel strongly about these issues. But that's okay as long as we at least try to have a civil discussion. Sometimes it does work, trust me. :) We are already capable of reasoned debate, we just don't take advantage of that often enough. That's laziness, not lack of ability. </pre> Michał 'rysiek' Woźniak 2013-05-19T21:29:22 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1053 <pre>Le 19/05/2013 15:40, Michał 'rysiek' Woźniak a écrit : *Agree*. Unfortunately, any debate on what freedom is between persons which aims freedom will most likely turn into flamewars ;) Fortunately, that's immaterial. Just take a look at "Poum" on WikiPedia and see what divergences on implementations of an idea has caused... and how today could be different if nobody claimed for the only good one. Note at time capitalism is also turned into an ideology, it immediately fails too. Regarding history, the ideology is most often the problem. Humanity as capable of a reasoned debate is the next step of its evolution... I expect the last will never be reached. Or too late. </pre> Thomas Harding 2013-05-19T20:11:06 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1052 <pre> Let's try and keep this civil. When reading the article, consider the reasoning on each point as to why it says what it says. All arguments (but one which I'll discuss below) are basically "because someone might want to do X, Y, Z and we can't if it's non-free". But the invariant sections in GFDL don't cover the text in the scenarios given, so there does not appear to be cause for concern. Then there is the argument (not saying that I agree) that having the invariant section is pointless because things might be protected in other ways. How does this matter? What practical reason is there to remove those parts if they aren't harming anyone? In my opinion, Debian (as an example) is missing out on a lot of GFDL documentation - but at what cost? As I indicated to you previously, I have yet to see an actual example of a GFDL non-variant section causing anyone grief. So back to my point; even if the non-variant section is pointless, it's on the people who have issue with it to explain why it's an issue - not for the FSF or the authors to drop it just for the sake of consistency or whatever it is that people are upset about. What do you mean by "other unmodifiable parts"? The invariant sections - the "Secondary Sections" - appear to be quite specific in what they can do, which is the *only* reason they aren't a problem. Software documentation (as an example) under licenses like CC-*-ND are indeed a problem - no argument from me there. Again, let's not confuse the issue by brining unrelated licenses into this. Regards, Adam </pre> Adam Bolte 2013-05-19T16:39:52 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1051 <pre>[...] Really? That doesn't make sense to me. You don't see any of the article's concerns take issue with anything the GFDL does? How about "I DON'T WANT MY WORK TWISTED!" and "SOME WORKS SHOULD BE INVARIANT!" where he argues these are invalid reasons to use a no derivatives licence (such as GFDL with Invariant Sections or other unmodifiable part). Actually, how about the whole article he posted. I'd like know why you think GFDL with Invariant Sections or other unmodifiable parts is good for free software manuals and yet for the article posted you "agree with many of your [its] points". I recommend re-reading what he posted. Regards, Mike. </pre> Michael Dorrington 2013-05-19T16:04:30 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1050 <pre> The part above that got cut out in the [...] was when Michael said: "I posted in December 2012 and January 2013 to this list about how including manuals which are under the GFDL with Invariant Sections or other unmodifiable parts (which is similar to a CC with ND licence) in a distribution makes that distribution non-free." Yet the document you posted only covers points specific to CC-*-ND and GNU Verbatim licenses. For the licenses in question, I agree with many of your points. However, those are entirely different beasts to the GFDL, which is the license that seems more commonly used for software documentation in GNU/Linux distributions. I don't see any of your concerns take issue with anything the GFDL does, given the strict limitations placed on non-variant sections. In any case, let's make sure we don't confuse licenses. Regards, Adam </pre> systemsaviour.com 2013-05-19T15:50:18 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1049 <pre>Dnia niedziela, 19 maja 2013 o 15:39:57 Michael Dorrington napisał(a): Ask and ye shall receive: http://rys.io/en/101.txt WHY I FIND -ND UNNECESSARY AND HARMFUL ====================================================================== *'UPDATE: highlighted the harmfulness of incompatibility of "no derivatives" licenses with libre licenses (including other CC-licenses); heartfelt thanks to Carlos Solís[1] for the Spanish translation[2]. ¡Gracias! * There are two basic arguments for licensing some works under a "no derivatives" license (e.g. any -ND Creative Commons license[3], or the GNU Verbatim Copying License[4]): - some authors do not wish for their works to be modified, twisted, used in ways they do not approve of; - some works (for example, expressing somebody's opinion) are fundamentally different from other kinds of works and should remain invariant. I believe both are specious. And I feel "no derivatives" licenses are both ineffective and counter-productive. Here's why. "I DON'T WANT MY WORK TWISTED!" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So you're an author and you do not wish your work to be twisted or modified to say something you didn't want to say. There are two possibilities of such modification: - somebody takes your work, twists it and publishes it under your name, suggesting you wrote this; - somebody modifies your work and publishes it under their own name, as a derivative work. /The first possibility would be illegal regardless of the license! /Nobody has the right to claim your authorship over something you did not create; nobody has the right to modify your work and claim it is still your work. -ND licenses are unnecessary for that purpose, it's already in the copyright law. As far as derivative works that build upon the original but change the meaning are concerned (/without misrepresentation of authorship/), I do not feel we need licensing restrictions for that. That feels too close to censorship for my liking -- /"thou shall not use my own words against me"/; /"I don't like what you're trying to say so I will use copyright law to stiffle your speech"/. Besides, creating parodies is fair use and no amount of "no derivatives" licensing clauses willl change that. Same goes for quotes. Your words /will/ be used in works that say something you do not wish to say, whether you like it or not! In that sense, "no derivatives" licenses are ineffective. "SOME WORKS SHOULD BE INVARIANT!" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This argument hinges upon an assumption that some works (memoirs, documentation, opinion pieces) are fundamentally different than others and hence should be preserved as they are. First of all, all of what I wrote above applies here. Such works cannot be "modified" anyway, "modification" is in fact creation of a derivative work, nobody can (legally) misrepresent authorship or the derived work as the original; such works, also, can be quoted and parodied, regardless of the license. "No derivatives" is ineffective. /"No derivatives" licensing stops people from doing things most of us would say are desirable/. Like /improving/ upon some work, creating better arguments or updated versions. Like /translating/ into another language to disseminate knowledge and argumentation. These things are genuinely /good/, but people that would like to do them /will/ look at the license, and will then get the message they cannot proceed... More importantly, however, this argument assumes that there is only one context in which a given work can be used. E.g. "an essay on free software" as an article to read and get argumentation from. Or a "memoir" as a historical document describing one's views and furtune. Thing is, any work can be used in any context, and often is. Think for a moment about a teacher in an IT class using an essay on free software as educational material, modifying it just a bit so that the class can better understand it or relate to it, or using it as a basis for an in-class discussion. "No derivatives" would not allow for that. Think about how artists used different kinds of "materials" for their works of art -- for example Duchamp's "Fountain"[5]. A "memoir" or an "opinion piece" could easily be used in an "art" context, for example as a basis of vocabulary for some free-software scripted (as in: done by scripts in interpreted programming languages) poem writing contest. An example of something similar is HaikuLeaks[6]. I bet we could find similar haikus in GNU documentation, FSF policy papers, Linux documentation. "No derivatives" would not allow anybody to use these in such a context -- and I would say that's a genuine loss. And in that sense "no derivatives" licenses are counter-productive. MUDDYING THE WATERS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "No derivatives" licensing is also truly harmful. They make it harder to explain what libre licensing is. Many people believe that any CC or GNU license is "free as in freedom", while in fact CC-*-ND and GNU Verbatim licenses cannot be considered as such. This distinction is both crucial and hard to convey. They also cause segmentation within the CC/GNU-licensed group of works: some such works (often co-existing on a single OS or in a single[7] repository[8]) are licensed in a way that makes them incompatible with others. Some cannot be modified or used (namely, "no derivatives"-licensed) in new works, while others can. This muddies the waters, makes libre licensing this much harder to explain and this much harder to take advantage of. TL;DR - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "No derivatives" licensing does not protect against things we want it to protect against (either because these are explicitly allowed for by the copyright law, or because the copyright law already disallows them); - and at the same time stops people from doing things we might consider interesting or beneficial; - while making it harder to promote libre licensing and libre-licensed works. Links: ------ [1] http://azkware.ticoblogger.com [2] http://rys.io/es/101 [3] http://creativecommons.org/licenses/by-nd/3.0/legalcode [4] http://www.gnu.org/licenses/license-list.html#GNUVerbatim [5] http://en.wikipedia.org/wiki/Fountain_%28Duchamp%29 [6] http://haikuleaks.tetalab.org/ [7] http://www.flickr.com/search/advanced/ [8] http://www.jamendo.com/en/search </pre> Michał 'rysiek' Woźniak 2013-05-19T15:08:37 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1048 <pre> The key here is that the Invariant sections in the GFDL may only apply to what the FSF refers to as Secondary Sections. From the GFDL-1.3, section 1 paragraph 3: "A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject." As such, the examples you gave earlier of texts of things that the four essential freedoms should apply to (recipes, computer programs, manuals and textbooks, reference works like dictionaries and encyclopedias) are not impacted by these invariant sections at all. There are good reasons for including invariant sections such as those you have mentioned in the post you linked. However, there do not appear to be any practical reasons why limited invariant sections which do not cover the useful components of the texts present a problem. We know that having sections of source code that cannot be modified is detrimental to society. Qmail is an example of this, which has apparently proven very difficult to maintain. However, what is not clear is how an invariant section at the start or end of a document which does not hinder freedom of actual subject matter have ever presented an actual practical problem for anyone. My suggestion is that you start by addressing this. Regards, Adam </pre> systemsaviour.com 2013-05-19T14:33:39 http://permalink.gmane.org/gmane.user-groups.foss.libreplanet/1047 <pre>Dnia niedziela, 19 maja 2013 o 15:20:25 Thomas Harding napisał(a): The solution is a reasoned debate with the FSF and GNU communities to try and convince them why -ND/GNU Verbatim is not a good idea. ;) </pre> Michał 'rysiek' Woźniak 2013-05-19T13:40:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.user-groups.foss.libreplanet