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
GPL applications using Python (OpenSSL issue?)
Can GPLv3+ applications written in Python exist in Debian main? The applications in question do not use an openssl exception. Python uses OpenSSL so the moment the application starts, it is linking against it too: $ objdump -p /usr/bin/python2.6 | grep NEEDED NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libssl.so.0.9.8 NEEDED libcrypto.so.0.9.8 NEEDED libz.so.1 NEEDED libm.so.6 NEEDED libc.so.6 In my case I am talking about a GPLv3+ package that exists in Debian -- kupfer Where do I draw the line for using/linking against ssl? a) Using Python2.6 b) Unintentionally introducing _ssl or ssl into the imported modules (import any of urllib, httplib, socket etc!) c) Unintentionally using ssl (use urllib.urlopen on URL provided by user -- if it's https we are using openssl) d) Intentionally using ssl (import ssl and use httplib.HTTPSConnection and verify certificates) Kupfer is today at (c) in the debian archive. It exists in development version at (d). Clearly (d) has provoked thought but upon investigation I see that import ssl only triggers import _ssl which in turn is an almost no-op because _ssl is a built-in module in Python 2.6. Is this easier to answer than I think it is? Ulrik -- 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/aanlktik0qlvls_1ugcwbzeu3skmbfxzmeuf6na8p1...@mail.gmail.com
Re: GPL applications using Python (OpenSSL issue?)
On Mon, Mar 7, 2011 at 7:48 PM, Ulrik Sverdrup ulrik.sverd...@gmail.com wrote: Can GPLv3+ applications written in Python exist in Debian main? The applications in question do not use an openssl exception. Python uses OpenSSL so the moment the application starts, it is linking against it too: $ objdump -p /usr/bin/python2.6 | grep NEEDED NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libssl.so.0.9.8 NEEDED libcrypto.so.0.9.8 NEEDED libz.so.1 NEEDED libm.so.6 NEEDED libc.so.6 In my case I am talking about a GPLv3+ package that exists in Debian -- kupfer Where do I draw the line for using/linking against ssl? a) Using Python2.6 b) Unintentionally introducing _ssl or ssl into the imported modules (import any of urllib, httplib, socket etc!) c) Unintentionally using ssl (use urllib.urlopen on URL provided by user -- if it's https we are using openssl) d) Intentionally using ssl (import ssl and use httplib.HTTPSConnection and verify certificates) e) use something like http://fedoraproject.org/wiki/FedoraCryptoConsolidation and port python to http://fedoraproject.org/wiki/Nss_compat_ossl Bastien -- 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/AANLkTikNs1j0DyR9KD0ra4dZ0wU2b=wsl0ctdcyqf...@mail.gmail.com