Re: About a couple of licenses in Japanese
2008/1/8, Ian Lewis [EMAIL PROTECTED]: Point taken. Japanese courts seem to be a bit more concerned with intent rather than the strength of the wording of a written agreement. If non-commercial use being prohibited without permission is non-free then this work should be interpreted as non-free. Yup, I'll consider it non-free then. Thanks everybody in the thread, you've been of great help!! :) Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GDAL HDF4 (HDF-EOS) driver license
It may be my english skills that are failing me, but is that ``without fee'' piece DFSG-compliant, or not? $ cat gdal/frmts/hdf4/hdf-eos/README The following source files are taken from the HDF-EOS package EHapi.c, GDapi.c, SWapi.c, HDFEOSVersion.h, HdfEosDef.h, ease.h and have the following copyright notice: Copyright (C) 1996 Hughes and Applied Research Corporation Permission to use, modify, and distribute this software and its documentation for any purpose without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. $ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GDAL HDF4 (HDF-EOS) driver license
This one time, at band camp, Ivan Shmakov said: It may be my english skills that are failing me, but is that ``without fee'' piece DFSG-compliant, or not? Yes. 'Without fee' in this context is a modifier for 'permission', not for 'purpose'. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: GDAL HDF4 (HDF-EOS) driver license
On Jan 8, 2008 11:05 AM, Ivan Shmakov [EMAIL PROTECTED] wrote: It may be my english skills that are failing me, but is that ``without fee'' piece DFSG-compliant, or not? Permission to use, modify, and distribute this software and its documentation for any purpose without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. I think this is fine. Similar wording is found in a number of licences (including some parts of QT and Python). Personally I think it is very poor drafting as it does cause confusion over what without fee is referring to. However, as in other similar cases, it seems clear that the wording means you are permitted to use, modify or distribute the software without having to pay a fee to the licensor. It does not mean that you are prohibited from charging a fee yourself for any use, modification or distribution of the software. So this is DFSG-free. John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GDAL HDF4 (HDF-EOS) driver license
John Halton [EMAIL PROTECTED] writes: It may be my english skills that are failing me, but is that ``without fee'' piece DFSG-compliant, or not? Permission to use, modify, and distribute this software and its documentation for any purpose without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. I think this is fine. Similar wording is found in a number of licences (including some parts of QT and Python). Personally I think it is very poor drafting as it does cause confusion over what without fee is referring to. Indeed. However, as in other similar cases, it seems clear that the wording means you are permitted to use, modify or distribute the software without having to pay a fee to the licensor. It does not mean that you are prohibited from charging a fee yourself for any use, modification or distribution of the software. So this is DFSG-free. Thanks for the clarification. I'm much less anxious now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
licensing of XMPP specifications
Back in October, I posted about the licensing of XMPP specifications produced by the XMPP Standards Foundation (XSF): http://lists.debian.org/debian-legal/2007/10/msg00055.html The membership and Board of Directors of the XSF have discussed this issue and we have consensus that we would like to change the licensing so that it is Debian-friendly (and, more broadly, freedom-friendly). After some discussion and wordsmithing, we have consensus on the following wording (for which the permissions section is essentially a modified MIT license): ** Legal Notices Copyright This XMPP Extension Protocol is copyright (c) 1999 - 2008 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the Specification), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. IPR Conformance This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at http://www.xmpp.org/extensions/ipr-policy.shtml or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). Warranty This Specification is provided as is, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ** Final feedback would be appreciated from the debian-legal list before the XSF Board of Directors votes to approve this licensing. Thanks. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: licensing of XMPP specifications
On Tue, Jan 08, 2008 at 11:53:20AM -0700, Peter Saint-Andre wrote: The membership and Board of Directors of the XSF have discussed this issue and we have consensus that we would like to change the licensing so that it is Debian-friendly (and, more broadly, freedom-friendly). Thank you for the work you have put in on seeking to achieve this. I'm sure I'm not the only one who greatly appreciates the commitment to software freedom this represents. (Some people would have stalked off by now, shouting fundamentalists! back over their shoulder...) Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the Specification), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. I can't see any problem with any of that. The final section (Unless separate permission is granted...) is a form of moral rights or protection against passing off rather than imposing any copyright restrictions. IPR Conformance This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at http://www.xmpp.org/extensions/ipr-policy.shtml or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). I'm assuming this is a statement of fact provided for information, rather than imposing any requirement on licensees to comply with that policy. So on that basis, that paragraph is fine. Though (as an aside) it seems to me that the protocol has _not_ been contributed in full conformance given the provisions of para 4 of the policy, but I'm assuming the board is empowered to waive that requirement. Warranty This Specification is provided as is, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. Again, no problem there, is all pretty standard stuff. John (TINLA, TINASOTODP) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: licensing of XMPP specifications
Ben Finney wrote: Peter Saint-Andre [EMAIL PROTECTED] writes: After some discussion and wordsmithing, we have consensus on the following wording (for which the permissions section is essentially a modified MIT license): This raises the question, then, why the exact MIT/X11 license terms were not used? That was discussed in the previous thread. ** Legal Notices Copyright This XMPP Extension Protocol is copyright (c) 1999 - 2008 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the Specification), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. I can't see a substantial difference in effect, yet the terms are different to the MIT/X11 license and thus contribute to license proliferation, which is bad. Better would be simply to copy the MIT/X11 permission text directly, so that countless people could save effort in determining that the license terms are identical. As it stands, they are not identical and must be scanned manually and understood separately. Please see the previous thread. IPR Conformance This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at http://www.xmpp.org/extensions/ipr-policy.shtml or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). Uses the overly vague term intellectual property rights URL:http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty, and sadly contributes to its unwarranted appearance of legitimacy URL:http://www.techliberation.com/archives/041256.php. I agree that the term is vague (in fact I don't agree with the premises behind the term), however that is the term used in common parlance and I cannot impose my viewpoint on the organization. Fortunately seems to have no effect on the freeness of works to which the license is applied. I'd be happier if this section was not here at all. Since it has no effect on the freeness, we will leave it in because it is there for organizational reasons. Warranty This Specification is provided as is, without warranty of any kind, express or implied, [...] Thank you, authors if this document, for writing a Warranty section that isn't needlessly in SHOUTY CAPITALS. Yes I hate those too. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: licensing of XMPP specifications
John Halton wrote: On Tue, Jan 08, 2008 at 11:53:20AM -0700, Peter Saint-Andre wrote: The membership and Board of Directors of the XSF have discussed this issue and we have consensus that we would like to change the licensing so that it is Debian-friendly (and, more broadly, freedom-friendly). Thank you for the work you have put in on seeking to achieve this. I'm sure I'm not the only one who greatly appreciates the commitment to software freedom this represents. (Some people would have stalked off by now, shouting fundamentalists! back over their shoulder...) Well if it were up to me everything would go into the public domain, but that's another story... Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the Specification), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. I can't see any problem with any of that. The final section (Unless separate permission is granted...) is a form of moral rights or protection against passing off rather than imposing any copyright restrictions. True. I'm not particularly concerned about passing off either (it's easy to determine who published the canonical version of the specification), but some members of the XSF were concerned. IPR Conformance This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at http://www.xmpp.org/extensions/ipr-policy.shtml or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). I'm assuming this is a statement of fact provided for information, rather than imposing any requirement on licensees to comply with that policy. So on that basis, that paragraph is fine. Correct. Though (as an aside) it seems to me that the protocol has _not_ been contributed in full conformance given the provisions of para 4 of the policy, but I'm assuming the board is empowered to waive that requirement. The IPR policy will be updated to reflect the licensing changes, but only once those changes are approved by the Board. We can't update the website until an official decision is made, thus the mismatch. :) Warranty This Specification is provided as is, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. Again, no problem there, is all pretty standard stuff. Thanks for the feedback. John (TINLA, TINASOTODP) Naturally. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: licensing of XMPP specifications
Peter Saint-Andre [EMAIL PROTECTED] writes: After some discussion and wordsmithing, we have consensus on the following wording (for which the permissions section is essentially a modified MIT license): This raises the question, then, why the exact MIT/X11 license terms were not used? ** Legal Notices Copyright This XMPP Extension Protocol is copyright (c) 1999 - 2008 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the Specification), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. I can't see a substantial difference in effect, yet the terms are different to the MIT/X11 license and thus contribute to license proliferation, which is bad. Better would be simply to copy the MIT/X11 permission text directly, so that countless people could save effort in determining that the license terms are identical. As it stands, they are not identical and must be scanned manually and understood separately. IPR Conformance This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at http://www.xmpp.org/extensions/ipr-policy.shtml or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). Uses the overly vague term intellectual property rights URL:http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty, and sadly contributes to its unwarranted appearance of legitimacy URL:http://www.techliberation.com/archives/041256.php. Fortunately seems to have no effect on the freeness of works to which the license is applied. I'd be happier if this section was not here at all. Warranty This Specification is provided as is, without warranty of any kind, express or implied, [...] Thank you, authors if this document, for writing a Warranty section that isn't needlessly in SHOUTY CAPITALS. -- \ I met my girlfriend in Macy's; she was buying clothes, and I | `\was putting Slinkies on the escalators. -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious doubts about the distributability of a file
Francesco Poli wrote: Probably OK in non-free given that Debian is a non-profit organisation. Wait, wait: IIUC, we are talking about a work which is licensed under the terms of the GNU LGPL v2 or later as a whole, but includes code licensed under a non-profit-only license. The two licenses are incompatible, as you noticed, hence the Debian Project has no valid permission to redistribute the work, even in non-free. More precisely, in order to comply with Section 4 of LGPLv2, the Debian Project should distribute the whole work under the terms of the LGPL, but this is impossible without violating the UNC Chapel Hill license. Consequently, I would say that the work is legally undistributable (regardless of the archive section Debian chooses to distribute from). That is what I was afraid of. We'll have to play with the upstream of the package so that this code is not used anymore (there seem to be a replacement around). Many thanks, Vincent -- Vincent Fourmond, Debian Developer http://vince-debian.blogspot.com/ -- pretty boring signature, isn't it ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: licensing of XMPP specifications
On Tue, 08 Jan 2008 14:09:41 -0700 Peter Saint-Andre wrote: Ben Finney wrote: Peter Saint-Andre [EMAIL PROTECTED] writes: After some discussion and wordsmithing, we have consensus on the following wording (for which the permissions section is essentially a modified MIT license): This raises the question, then, why the exact MIT/X11 license terms were not used? That was discussed in the previous thread. Yeah, and I think we explained why our recommendation was to adopt the exact Expat/MIT license (or the exact X11/MIT license, if you prefer). The proposed license talks about a Specification, which becomes a bit problematic, as soon as I modify the Specification to the point it is not a Specification anymore. I could turn it into a poem, or into a summary description, or into a sci-fi novel, or into... But I'm repeating myself: as you yourself said, that was discussed in the previous thread. Nonetheless, the situation hasn't improved from this point of view... [...] Warranty This Specification is provided as is, without warranty of any kind, express or implied, [...] A better title for this section would be Disclaimer of warranty, or No warranty, I think. My reiterated disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html New! Version 0.6 available! What? See for yourself! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp2EuIB9c70t.pgp Description: PGP signature
Re: licensing of XMPP specifications
On Wed, Jan 09, 2008 at 12:36:07AM +0100, Francesco Poli wrote: The proposed license talks about a Specification, which becomes a bit problematic, as soon as I modify the Specification to the point it is not a Specification anymore. I could turn it into a poem, or into a summary description, or into a sci-fi novel, or into... But I'm repeating myself: as you yourself said, that was discussed in the previous thread. Nonetheless, the situation hasn't improved from this point of view... To be fair, Specification is just a defined legal term. It does not impose any legal restriction on the nature of the amended work, though if you did turn it into a poem then the wording of the licence would seem a little odd! I don't think it causes any legal problems using that word, and I don't think there is any need to change it. [...] Warranty This Specification is provided as is, without warranty of any kind, express or implied, [...] A better title for this section would be Disclaimer of warranty, or No warranty, I think. Fair point, though not the end of the world if it stays in the current form (lawyers are trained to ignore section headings ;-)). Also, as regards the SHOUTY CAPITALS thing, I gather some jurisdictions in the US make this a legal requirement, so the board may want to check their local legal position before finalising the non-shouty version. John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: licensing of XMPP specifications
Francesco Poli wrote: On Tue, 08 Jan 2008 14:09:41 -0700 Peter Saint-Andre wrote: Ben Finney wrote: Peter Saint-Andre [EMAIL PROTECTED] writes: After some discussion and wordsmithing, we have consensus on the following wording (for which the permissions section is essentially a modified MIT license): This raises the question, then, why the exact MIT/X11 license terms were not used? That was discussed in the previous thread. Yeah, and I think we explained why our recommendation was to adopt the exact Expat/MIT license (or the exact X11/MIT license, if you prefer). Yes, and I respectfully disagreed with you because I want the XMPP Standards Foundation to make it perfectly clear to the developers and service providers who implement and deploy the protocols specifications we define exactly what they can do with the specifications, in language they can understand, with no possible confusion on their part. That, to me, is more important than using the precise wording of the X11/MIT license. The proposed license talks about a Specification, which becomes a bit problematic, as soon as I modify the Specification to the point it is not a Specification anymore. I could turn it into a poem, or into a summary description, or into a sci-fi novel, or into... But I'm repeating myself: as you yourself said, that was discussed in the previous thread. Nonetheless, the situation hasn't improved from this point of view... Is the license free or not? That is the question. Warranty This Specification is provided as is, without warranty of any kind, express or implied, [...] A better title for this section would be Disclaimer of warranty, or No warranty, I think. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: licensing of XMPP specifications
John Halton wrote: Also, as regards the SHOUTY CAPITALS thing, I gather some jurisdictions in the US make this a legal requirement, so the board may want to check their local legal position before finalising the non-shouty version. Well I notice that even the MIT License formats the disclaimer of warranty in SHOUTY CAPITALS, so it may be wise to retain them. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Warranty disclaimers with SHOUTY CAPITALS (was: licensing of XMPP specifications)
John Halton [EMAIL PROTECTED] writes: Also, as regards the SHOUTY CAPITALS thing, I gather some jurisdictions in the US make this a legal requirement, For what it's worth, the GPLv3 drafters researched the commonly-held belief that SHOUTY CAPITALS are required for warranty disclaimers, and concluded there was no such requirement: The warranty exclusions that were in GPL2 have not been changed saving one way: I took them out of all uppercase. [...] because no lawyer on Earth knows [why] they aren't in mixed case and everybody seems to think that everybody else knows and that he's the only one that doesn't know and he was absent that day in law school. URL:http://www.ifso.ie/documents/gplv3-launch-2006-01-16.html#em-warranty so the board may want to check their local legal position before finalising the non-shouty version. If the board reveals something more substantive on the reason for writing disclaimers in SHOUTY CAPITALS than because that's what everyone says you have to do, I'm sure many people would be interested. -- \ Probably the earliest flyswatters were nothing more than some | `\ sort of striking surface attached to the end of a long stick. | _o__) -- Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Warranty disclaimers with SHOUTY CAPITALS
Ben Finney [EMAIL PROTECTED] writes: For what it's worth, the GPLv3 drafters researched the commonly-held belief that SHOUTY CAPITALS are required for warranty disclaimers, and concluded there was no such requirement: The warranty exclusions that were in GPL2 have not been changed saving one way: I took them out of all uppercase. [...] because no lawyer on Earth knows [why] they aren't in mixed case and everybody seems to think that everybody else knows and that he's the only one that doesn't know and he was absent that day in law school. URL:http://www.ifso.ie/documents/gplv3-launch-2006-01-16.html#em-warranty Sadly, checking the released version of GPLv3, I see that the sections 15. Disclaimer of Warranty. and 16. Limitation of Liability. both contain all text in SHOUTY CAPITALS. That's disappointing :-( I wasn't aware they'd been reverted from readable text. It must have happened shortly before the release. so the board may want to check their local legal position before finalising the non-shouty version. If the board reveals something more substantive on the reason for writing disclaimers in SHOUTY CAPITALS than because that's what everyone says you have to do, I'm sure many people would be interested. This still stands. I'm still entirely unaware of what the legal reason is. -- \ It's easy to play any musical instrument: all you have to do | `\ is touch the right key at the right time and the instrument | _o__) will play itself. -- Johann Sebastian Bach | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Warranty disclaimers with SHOUTY CAPITALS
Ben Finney wrote: Sadly, checking the released version of GPLv3, I see that the sections 15. Disclaimer of Warranty. and 16. Limitation of Liability. both contain all text in SHOUTY CAPITALS. That's disappointing :-( I wasn't aware they'd been reverted from readable text. It must have happened shortly before the release. so the board may want to check their local legal position before finalising the non-shouty version. If the board reveals something more substantive on the reason for writing disclaimers in SHOUTY CAPITALS than because that's what everyone says you have to do, I'm sure many people would be interested. This still stands. I'm still entirely unaware of what the legal reason is. This is explained in the rationale document that accompanied the third public draft of GPLv3, http://gplv3.fsf.org/gpl3-dd3-rationale.pdf at p. 61, n. 108: [quoting] There is authority under United States law suggesting that effective warranty disclaimers must be conspicuous, and that conspicuousness can be established by capitalization and is absent when a disclaimer has the same typeface as the terms surrounding it (see Stevenson v. TRW, Inc., 987 F.2d 288, 296 (5th Cir. 1993)). We have reason to doubt that such authority would apply to copyright licenses like the GPL. Nevertheless, pending further research, we have cautiously decided to restore the capitalization of both the warranty disclaimer and the liability limitation in Draft 3. [end of quote] Cheers, Richard E. Fontana Counsel Software Freedom Law Center -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Warranty disclaimers with SHOUTY CAPITALS
Richard Fontana [EMAIL PROTECTED] writes: Ben Finney wrote: This still stands. I'm still entirely unaware of what the legal reason [for SHOUTY CAPITALS in disclaimers] is. This is explained in the rationale document that accompanied the third public draft of GPLv3, http://gplv3.fsf.org/gpl3-dd3-rationale.pdf at p. 61, n. 108: Thanks for this rapid response. You've answered my question completely. -- \ When we call others dogmatic, what we really object to is | `\their holding dogmas that are different from our own. -- | _o__) Charles Issawi | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Translated man pages licenses
Hi While investigating manpages-cs licensing, I looked at other manpages-* packages copyright files and some of them really look strange for me. manpages-de/copyright[1], manpages-hu/copyright[2] and manpages-jp/copyright[3]: commercial distribution may impose other requirements (e.g., acknowledgement of copyright or inclusion of the raw nroff sources with the commercial distribution) Shouldn't this make these packages move into non-free? I didn't investigate packages content and licensing details, I just looked at copyright files, but this sentence looks strange. [1]:http://packages.debian.org/changelogs/pool/main/m/manpages-de/manpages-de_0.5-2/manpages-de.copyright [2]:http://packages.debian.org/changelogs/pool/main/m/manpages-hu/manpages-hu_20010119-5/manpages-hu.copyright [3]:http://packages.debian.org/changelogs/pool/main/m/manpages-ja/manpages-ja_0.5.0.0.20071215-1/manpages-ja.copyright PS: Please CC me, I'm not subscribed. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
