Re: The Evil Cookie Producer case
Hi, and thanks for the effort of providing the complete information. Le lundi 07 mars 2011 à 09:31 +, Andrew Ross a écrit : The software itself is the current version of iText, which is licensed under the AGPL with the following additional term: In accordance with Section 7(b) of the GNU Affero General Public License, you must retain the producer line in every PDF that is created or manipulated using iText. I’m not sure how to interpret this restriction. If it is in accordance to Section 7b, it means you cannot remove from iText the code that produces this line in PDF files. You are still free to remove the line in the generated PDF file if you want. If the intent is to restrict modifications that can be made on generated PDF files themselves, the license is clearly non-free (and considered a “further restriction” in the AGPL). Cheers, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1299599115.18970.15.camel@meh
Re: The Evil Cookie Producer case
Op 8/03/2011 16:45, Josselin Mouette schreef: Hi, and thanks for the effort of providing the complete information. Le lundi 07 mars 2011 à 09:31 +, Andrew Ross a écrit : The software itself is the current version of iText, which is licensed under the AGPL with the following additional term: In accordance with Section 7(b) of the GNU Affero General Public License, you must retain the producer line in every PDF that is created or manipulated using iText. I’m not sure how to interpret this restriction. If it is in accordance to Section 7b, it means you cannot remove from iText the code that produces this line in PDF files. You are still free to remove the line in the generated PDF file if you want. If the intent is to restrict modifications that can be made on generated PDF files themselves, the license is clearly non-free (and considered a “further restriction” in the AGPL). Copy/paste from a previous answer. If company B is using iText, Company B is bound by the license. This doesn't mean the producer line can't be changed; there are different options to add extra data: - They can add data to the existing producer line (created by product A; modified by product B) - They can use an other metadata field (Application in Document Properties) to add whatever they want. Read ISO-32000-1 to find out more about metadata in PDF. If company C is using PDFs produced by company B, it doesn't enter in the AGPL, but has the right to know that Company B uses iText. During post-processing operations, the producer line may change or even disappear. Now that I think of it: company B can be identical to company C. Maybe it's better to talk about product X using iText and product Y processing PDFs produced by iText. -- 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/4d7650ea.7050...@gmail.com
Re: The Evil Cookie Producer case
* Andrew Ross: In accordance with Section 7(b) of the GNU Affero General Public License, you must retain the producer line in every PDF that is created or manipulated using iText. What is a producer line? Is this visible on the page, or is this some information in the PDF header? In any case, pdftk uses libitext-java and needs to avoid such changes, I think. We also should not package software (especially libraries) under the AGPL which do not provide means to access their own source code over the network, otherwise it is going to be difficult for our users to run the software in a way that complies with its licensing requirements. -- 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/87ipvtqxx7@mid.deneb.enyo.de
Re: The Evil Cookie Producer case
On 08/03/11 15:53, Bruno Lowagie wrote: Copy/paste from a previous answer. If company B is using iText, Company B is bound by the license. This doesn't mean the producer line can't be changed; there are different options to add extra data: - They can add data to the existing producer line (created by product A; modified by product B) - They can use an other metadata field (Application in Document Properties) to add whatever they want. Read ISO-32000-1 to find out more about metadata in PDF. If company C is using PDFs produced by company B, it doesn't enter in the AGPL, but has the right to know that Company B uses iText. During post-processing operations, the producer line may change or even disappear. Now that I think of it: company B can be identical to company C. Maybe it's better to talk about product X using iText and product Y processing PDFs produced by iText. Bruno, I think the problem with your last paragraph is that if company B is identical to company C then company C is also bound by the license. So during post processing C is not allowed to change the producer line. So I think it needs the additional term to talk about the product using iText rather than the person. So then a derivative work of iText, i.e. one using iText to create/modify a pdf, must retain the producer line. And once the PDF is written then it's not affected by the additional term. Andy -- 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/4d76ac4f.3090...@rossfamily.co.uk
Re: The Evil Cookie Producer case
Op 7/03/2011 2:17, MJ Ray schreef: Bruno Lowagie wrote: Please don't avoid the question: does the freedom to hide information prevail over the freedom to get information? You mean like you avoided the question: what is the actual case here? No problem. Let me describe the context. I've been programming since I was 12 years old (1982). I've been working as a developer since 1996. I've been publishing free / open source software since 1999. Depending on the context, I've use the LGPL, the MPL, the GPL and the AGPL as licenses. A library such as iText is already shipped with Debian, and different other projects depend on it. Other projects aren't part of the distribution, for instance because of their poor quality (e.g. the iText Toolbox which was never meant as a real product), or RUPS (a specialist tool aimed at a very small audience). Last week, I received a request from a Debian developer who wanted to ship an AGPL product with Debian, but he wanted me to change the license. I'm not a lawyer, but I've been working with (and for) a plethora of lawyers in the last 10 years, and I'm always eager to learn. So I asked an attorney (one that knows F/OSS licenses) to read the DFSG at my own expense (he's paid by the hour), to help me decide whether or not I should change the license as asked by the Debian developer. I received an answer from my attorney: there's no reason to change. The license passes the tests. This legal advice didn't convince the Debian developer. In an attempt to help the Debian developer, I wrote a metaphor (exaggerating a bit, but the essence remains: does the freedom to hide a truth prevail over the freedom to get information). I had hoped to get arguments to help the Debian developer, but it turned out differently. Two out of the three replies tell me that the AGPL is accepted, but controversial. If that is the case, I'll advise the Debian developer NOT to ship that particular product with Debian. Thank you for your advice, I've learned something I didn't know before. -- 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/4d7490b1.3070...@gmail.com
Re: The Evil Cookie Producer case
On 07/03/11 08:00, Bruno Lowagie wrote: A library such as iText is already shipped with Debian, and different other projects depend on it. Other projects aren't part of the distribution, for instance because of their poor quality (e.g. the iText Toolbox which was never meant as a real product), or RUPS (a specialist tool aimed at a very small audience). Last week, I received a request from a Debian developer who wanted to ship an AGPL product with Debian, but he wanted me to change the license. I'm not a lawyer, but I've been working with (and for) a plethora of lawyers in the last 10 years, and I'm always eager to learn. So I asked an attorney (one that knows F/OSS licenses) to read the DFSG at my own expense (he's paid by the hour), to help me decide whether or not I should change the license as asked by the Debian developer. I received an answer from my attorney: there's no reason to change. The license passes the tests. This legal advice didn't convince the Debian developer. In an attempt to help the Debian developer, I wrote a metaphor (exaggerating a bit, but the essence remains: does the freedom to hide a truth prevail over the freedom to get information). I had hoped to get arguments to help the Debian developer, but it turned out differently. Two out of the three replies tell me that the AGPL is accepted, but controversial. If that is the case, I'll advise the Debian developer NOT to ship that particular product with Debian. Thank you for your advice, I've learned something I didn't know before. Hi all, I'm the maintainer (a maintainer of Debian packages, rather than a Debian maintainer) in question, and to be clear, what is under discussion is software licensed under the AGPL with an additional term which could potentially make the software non-free in the eyes of Debian. So even though we accept the AGPL in raw form there is still something to discuss. The software itself is the current version of iText, which is licensed under the AGPL with the following additional term: In accordance with Section 7(b) of the GNU Affero General Public License, you must retain the producer line in every PDF that is created or manipulated using iText. The full license can be found at http://itextpdf.com/terms-of-use/agpl.php I asked Bruno about this term, and he was very willing to discuss the implications as he saw them. It's clearly slightly complicated, and I've been trying to follow the implications in the worst-case. In reality I personally would probably be happy to use iText in a project, but that doesn't mean I'd be happy to upload it to Debian where everything needs to remain free in the Debian sense. It's my belief that this term could be interpreted to read that I must not remove the producer line added by iText, which affects what follow on processing I can do to that pdf, unless of course follow on processing actually counts as creating a new pdf, which is of course a possibility. My reasoning goes that if I write some software which uses iText to produce a pdf, then if I use some other piece of software to modify that pdf then I have potentially broken the license, since the producer line may have been changed to reflect the name of this second piece of software. The point is less problematic for an end user of a web app - if I write a web app that uses iText to produce them a pdf then they haven't entered into the AGPL with this extra term, and so they are free to do what they like. But what about an end user who has also written some software using iText - since they are bound by this term, then they're no longer free to do as they wish with this PDF. Or an end user of standalone software running on their computer? I don't want to mis-represent what Bruno has said, so hopefully he'll chime in and expand further if I get anything wrong here. I think the following paragraph from Bruno sums up his viewpoint: The AGPL and the extra term ensure the consumer's RIGHT to know that the PDF was produced by iText. Denying this right is IMO exactly the abuse of Free Software the AGPL wants to avoid. Writing this email I do now wonder if the problem is solely how far this term appears like it could apply. If the term clearly only applied to software which uses iText to produce or modify a PDF then I think my issues disappear. So maybe something along the lines of: In accordance with Section 7(b) of the GNU Affero General Public License, a covered work must retain the producer line in every PDF that is created or manipulated using iText. This would make it clear that the when writing software using iText (the covered work) you must retain the producer line, but would leave you open to do what you want with the PDF afterwards, since you would no longer be using a covered work to do the manipulation etc. I'll think more about this later. Andy -- Andrew Ross -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe.
Re: The Evil Cookie Producer case
In accordance with Section 7(b) of the GNU Affero General Public License, you must retain the producer line in every PDF that is created or manipulated using iText. Hello, in my understanding of section 7 of the AGPL, the supplemental terms are there to ensure compatibility with other free license, and the ‘legal notices or author attributions’ that are the object of the paragraph b) are typically found in the program's source code, not in code or the data generated by the program. The GPL has a similar section. Regardless of the purpose and the intentions behind requiring to ‘retain the producer line in every PDF that is created or manipulated using iText’, if this addition to the AGPL does not fall under Section 7(b), this makes iText potentially incompatible with other works released under the (A)GPL license. That alone may be a reason to reconsider this additional term. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20110307100240.gc22...@merveille.plessy.net
Re: The Evil Cookie Producer case
For some reason, my latest answers weren't sent to the list, but to individual people. Sorry for that. This is my latest response: Andrew Ross wrote: My reasoning goes that if I write some software which uses iText to produce a pdf, then if I use some other piece of software to modify that pdf then I have potentially broken the license, since the producer line may have been changed to reflect the name of this second piece of software. The point of view of my attorney: - company A = 1T3XT BVBA - company B = a company using iText in software to create PDFs - company C = a company using the PDFs created by company B Company B is bound by the license. This doesn't mean the producer line can't be changed; there are different options to add extra data: - They can add data to the existing producer line (created by product A; modified by product B) - They can use an other metadata field (Application in Document Properties) to add whatever they want. Read ISO-32000-1 to find out more about metadata in PDF. Company C doesn't enter in the AGPL, but has the right to know that Company B uses iText. Why is this important? Typically, we get PDFs sent to us by companies that have never used iText; sometimes they don't even know iText, BUT they have an issue with a PDF created by iText. In general the problem is caused due to postprocessing by a third party app. Nevertheless, we can help out in many cases: thanks to the fact that the consumer of the PDF can trace the PDF down to iText. This is what the end consumer wants, and this is what 1T3XT wants, regardless of the opinion of any other party in-between. The AGPL and the extra term ensure the consumer's RIGHT to know that the PDF was produced by iText. Denying this right is IMO exactly the abuse of Free Software the AGPL wants to avoid. That is what I honestly believe: the producer line is non-intrusive. It doesn't show up when the PDF is printed (be it on paper, or using a virtual printer); it doesn't show up when the PDF is viewed, unless the viewer (third party software) decides to show it (for instance because the consumer opens the Document Properties dialog in search for more information). The producer line doesn't take away any freedom from company C. On the contrary: if company C wants to know which ingredients were used to create the PDF, they can find out thanks to the producer line. Suppose that some company B wants to hide this information, then company B takes away this freedom from company 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/4d74ad9b.5040...@gmail.com
Re: The Evil Cookie Producer case
Op 7/03/2011 11:02, Charles Plessy schreef: Regardless of the purpose and the intentions behind requiring to ‘retain the producer line in every PDF that is created or manipulated using iText’, if this addition to the AGPL does not fall under Section 7(b), this makes iText potentially incompatible with other works released under the (A)GPL license. That alone may be a reason to reconsider this additional term. Is there any jurisdiction about this I can forward to my attorney? -- 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/4d74ae1e.1010...@gmail.com
Re: The Evil Cookie Producer case
Andrew Ross wrote: The full license can be found at http://itextpdf.com/terms-of-use/agpl.php [...] I don't want to mis-represent what Bruno has said, so hopefully he'll chime in and expand further if I get anything wrong here. I think the following paragraph from Bruno sums up his viewpoint: The AGPL and the extra term ensure the consumer's RIGHT to know that the PDF was produced by iText. Denying this right is IMO exactly the abuse of Free Software the AGPL wants to avoid. I doubt that the AGPL wants to be a souped-up advertising clause, given the FSF's past arguments such as http://www.gnu.org/philosophy/bsd.html (Please don't personify the AGPL. It hates that.) I feel that this case depends on whether specifying a particular exact wording of a legal notice is reasonable (as it says in the AGPL). I'm pretty sure it's not, but I'd welcome any evidence either way. Would someone more knowledgeable about the case like to clarify the point with licensing@fsf or shall I? Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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/20110307101022.ce8644f...@nail.towers.org.uk
Re: The Evil Cookie Producer case
Le Mon, Mar 07, 2011 at 11:06:22AM +0100, Bruno Lowagie a écrit : Op 7/03/2011 11:02, Charles Plessy schreef: Regardless of the purpose and the intentions behind requiring to ‘retain the producer line in every PDF that is created or manipulated using iText’, if this addition to the AGPL does not fall under Section 7(b), this makes iText potentially incompatible with other works released under the (A)GPL license. That alone may be a reason to reconsider this additional term. Is there any jurisdiction about this I can forward to my attorney? I do not have experience in contacting them, but I think that if I were in your case, I would ask directly to Free Software Foundation, since they probably know the best what is the intention behind Section 7. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20110307101252.gd22...@merveille.plessy.net
Re: The Evil Cookie Producer case
Op 7/03/2011 11:12, Charles Plessy schreef: Le Mon, Mar 07, 2011 at 11:06:22AM +0100, Bruno Lowagie a écrit : Op 7/03/2011 11:02, Charles Plessy schreef: Regardless of the purpose and the intentions behind requiring to ‘retain the producer line in every PDF that is created or manipulated using iText’, if this addition to the AGPL does not fall under Section 7(b), this makes iText potentially incompatible with other works released under the (A)GPL license. That alone may be a reason to reconsider this additional term. Is there any jurisdiction about this I can forward to my attorney? I do not have experience in contacting them, but I think that if I were in your case, I would ask directly to Free Software Foundation, since they probably know the best what is the intention behind Section 7. It has been a long time since I last had to contact the FSF (certainly more than 5 years ago, probably longer), but this is indeed a case that could benefit from their opinion. -- 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/4d74b08f.5090...@gmail.com
Re: The Evil Cookie Producer case
On 3/7/11, Andrew Ross ubu...@rossfamily.co.uk wrote: The AGPL and the extra term ensure the consumer's RIGHT to know that the PDF was produced by iText. Denying this right is IMO exactly the abuse of Free Software the AGPL wants to avoid. Exaggerating a bit with the cookie metaphore, I see. ;-) Sure, maybe the consumer has a RIGHT to know that the PDF was created with iText, but he almost certainly doesn't care. In the interest of full disclosure, I think I should mention that the message you're reading now was sent through Gmail, which I accessed on a TMobile-locked BlackBerry Bold 9780 (connected over WiFi to a Linksys router), running v6.0.0.285 of the BlackBerry OS. Portions of the browser are copyright 4thpass. If you want to discuss the opinions I've expressed here, please do so in a way that respects people's right to know which technologies I used to express them. ;-) -PJ -- 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/AANLkTinY9aSMO56fEWKcpQ=vdgLJHnUCvgd+NC=hl...@mail.gmail.com
Re: The Evil Cookie Producer case
On Mon, 07 Mar 2011 at 11:04:11 +0100, Bruno Lowagie wrote: This is what the end consumer wants, and this is what 1T3XT wants, regardless of the opinion of any other party in-between. I think there's an important distinction between I believe that it's beneficial for everyone that this is done, this is sufficiently important that someone should cause it to be legally binding, and this is sufficiently important that I, personally, need to enforce it via my copyright license. I'd like it if nobody forked my Free Software and everyone sent me patches for their changes, but there seems to be a general consensus (which I agree with) that enforcing this via a license is too high a price to pay for this good behaviour - the right to fork is also valuable. So, I can request it, but if I try to enforce it we consider that to be a non-Free restriction. A couple of relevant things to think about: suppose I fork iText (and call it smcvText). * Do you intend your extra term to force me to put iText in the producer line, which is arguably not true any more since I'm using a modified version with exciting new bugs? * Or, do you intend your extra term to force me to put smcvText, or smcvText (based on iText), in the producer line? * If I don't do either (or if I choose the wrong one!), presumably when you found out you'd ask me to fix that. If I refused, would you sue me? If the answer is no then it doesn't seem as though you'd have gained anything by adding the term to the license; there's no point jumping through hoops to make something enforcable if you're not going to enforce it. I don't think your extra term complies with AGPL 7(b) as it claims, because 7(b) requires preservation of legal notices/attributions in material you add to a covered work or in the Appropriate Legal Notices displayed by works containing it - you can force people to keep your attribution in iText's Help - About or --version output or equivalent, but I don't think this applies to iText's *output* (unless its output contains enough of a copy of iText that all PDFs produced by it are *also* covered by the AGPL, but I think that'd imply a lot of practical problems anyway). So, you've effectively created an AGPL-like, but incompatible, license. Because of your modified license, I can't combine iText with code from another GPL'd or AGPL'd work. Is that an acceptable price to pay? We strongly discourage the use of non-standard licenses because of practical problems like these. A non-standard license can be DFSG-compliant but still a bad idea (look at OpenSSL and all the practical problems that's caused). In this particular situation I'd suggest making the extra term a non-binding request, something like: The author of this software requests that you retain the iText producer line in every PDF that is created or manipulated using iText. or even: The author of this software requests [...etc...] to facilitate debugging of any post-processing issues and [... other reasons? ...] or even just insert similar wording as a comment in the source code, next to the code that adds the producer line. Anyone who's not being deliberately awkward will probably comply with your request, particularly if the reasons are as compelling as you imply, and if they *are* being deliberately awkward, perhaps they don't deserve your help :-) - Rather off-topic, but back to your cookie analogy: I don't think using copyright law or private contracts as a way to enforce may contains nuts labelling would be appropriate either. The reason that those labels are legally mandated (in many countries) is that society has decided that the burden of labelling products is an acceptable price to pay for not having people who're allergic to nuts accidentally eating them and dying. If it's important enough to be enforced (and IMO it is), then it's important enough to be enforced for everyone, not just users of your particular brand of cookie-making machines. Enforcing society's consensus on everyone, so individuals don't have to, is what governments are for... In the desert island situation, attempting to create unrelated laws via copyright seems rather futile; if there's nobody who can enforce safety labelling, probably nobody's enforcing copyright either. (I hope your analogy is exaggerated and nobody actually has an anaphylactic-shock reaction to iText output :-) Regards, S -- 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/20110307122654.ga6...@reptile.pseudorandom.co.uk
Re: The Evil Cookie Producer case
Op 7/03/2011 13:26, Simon McVittie schreef: In this particular situation I'd suggest making the extra term a non-binding request, something like: The author of this software requests that you retain the iText producer line in every PDF that is created or manipulated using iText. or even: The author of this software requests [...etc...] to facilitate debugging of any post-processing issues and [... other reasons? ...] or even just insert similar wording as a comment in the source code, next to the code that adds the producer line. Anyone who's not being deliberately awkward will probably comply with your request, particularly if the reasons are as compelling as you imply, and if they *are* being deliberately awkward, perhaps they don't deserve your help :-) That's what Andrew already suggested, at which point I asked an attorney to look at it. The attorney said it wasn't necessary to change the line as it wasn't a problem. Thank you for the elaborate answer. Plenty of things to think about. -- 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/4d74d383.70...@gmail.com
Re: The Evil Cookie Producer case
On Sun, 06 Mar 2011 12:43:02 +0100 Bruno Lowagie wrote: Hello, Hi! I'm confronted with a very special case for which I've written a metaphor. I'd like your opinion on this case. Imagine that using software is like baking cookies. [...] I would like to hear your opinion on this case [...] A few considerations: * metaphors may be useful to discuss an issue, but only focusing on the metaphor may be very misleading, since almost no metaphor is a perfect analogy: I think you'd better present your actual case, rather than a metaphor * I personally think that the GNU AfferoGPL v3 fails to meet the DFSG (see my own analysis [1]), despite the opposite opinion of FTP Masters (see their response [2] and my own counter-response [3]): as a consequence, you'll probably fail to convince me that _another_ restriction may be added to the GNU AfferoGPL v3 without harm (I already consider the license problematic as it is, let alone after the addition of further restrictions!) [1] http://lists.debian.org/debian-legal/2007/11/msg00233.html [2] http://bugs.debian.org/495721#17 [3] http://bugs.debian.org/495721#28 -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpLvYyGe6rYQ.pgp Description: PGP signature
Re: The Evil Cookie Producer case
Le dimanche 06 mars 2011 à 12:43 +0100, Bruno Lowagie a écrit : I'm confronted with a very special case for which I've written a metaphor. I'd like your opinion on this case. This is not a metaphor. It is about something that is not software, for which you try to apply software reasoning. I fail to see where you want to go with this. Now suppose that nuts are part of the ingredients list of the recipe created by Company A. To protect cookie consumers, Company A adds an extra term to the AGPL: as long as there are traces of nuts down the production line, all products that may contain traces of nuts must retain the notice may contain traces of nuts. Copyright (and copyleft) isn’t here to protect consumers, it is here to protect your intellectual property. This kind of protection should be provided by law. In many countries there a rule that forces resellers to warn consumers when there are traces of nuts in their products. You can’t take the place of such a law by using your copyright license as a vessel. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: The Evil Cookie Producer case
Op 6/03/2011 18:00, Josselin Mouette schreef: This is not a metaphor. It is about something that is not software, for which you try to apply software reasoning. I fail to see where you want to go with this. *10 Q: Does the DFSG apply only to computer programs? **A:* No, we apply our standards of freedom to all parts of all software in Debian. Recipes are very much like software: they are series of instructions that are to be processed in a specific order. We can very well build a machine that runs Debian and that uses a recipe in the form of a F/OSS program to bake cookies. This kind of protection should be provided by law. Yes, it should, but the FAQ mentions: a. The Desert Island test. Let's imagine a community of castaways on a desert island with a solar-powered computer and a solar-powered kitchen. There is no law on that Island; our license is the only means available. Please don't avoid the question: does the freedom to hide information prevail over the freedom to get information? This is a theorical thought experiment. I'm asking you to use your imagination, as is done in the FAQ with metaphors such as the Desert Island test, the Dissident test and the Tentacles of Evil test.
Re: The Evil Cookie Producer case
Bruno Lowagie wrote: Please don't avoid the question: does the freedom to hide information prevail over the freedom to get information? You mean like you avoided the question: what is the actual case here? This list works better when it is discussing actual software which be considered for debian. So I dislike this discussion of food and anyway, I think all cookies are evil, so what does it matter? ;-) The FAQ and its tests are illustrative but slightly controversial and not decisive - although I think I've posted how I believe they follow from the DFSG in the past. The AGPL is a known big dispute in this group. Mentioning both in one post with no software smells fishy. I particularly liked it when the original post asked if I'd prefer to die. Can I choose to die at the hands of Hitler force-feeding me one of those nutty cookies? If only that worked... Happy Sunday! -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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/20110307011736.d3c2b4f...@nail.towers.org.uk
