Re: Why TPM+Parallel Distribution is non-free
On Tue, 10 Oct 2006, Terry Hancock wrote: > Prohibiting TPM *distribution* is fine under DFSG. No, it's not. Prohibiting TPM distribution is quite clearly a restriction on a field of endeavor. > This is exactly what the Aug 9 draft of CCPL3.0 says: > > """ You may not impose any technological measures on the Work that > restrict the ability of a recipient of the Work from You to exercise > their rights granted under the License """ The critical aspect here is that parallel distribution does not cause the rights of a recipient of the work to be restricted; they retain all abilities that they had originally and gain additional ones (namely, being able to run the work on a TPM-inflicted device.) > The requirement is needed to ensure that copyleft preserves the > freedoms granted by the content's author. No, they're not. They're a lazy means of hacking in a small bit of copyleft protection into licenses by outlawing legitimate uses. Any attempt via licensing to deal properly with TPM and or DRM must necessarily address the need for free software works to be capable of running on such a device when the end user desires it. There are two choices: You either 1) allow parallel distribution 2) require distribution of keys or information needed to deploy modified versions to the device. Whether or choosing to do 2) has the pratical effect of not allowing the use on TPM devices is a separate issue; it in itself does not outlaw their use or distribution. [It just minimizes their effectiveness.] If you're seriously interested in discussing how to do copylefted TPM and DRM properly, I strongly suggest reading my position statement from committee D on the first discussion draft of the GPL and also checking out the logs of seth schoen's conversations with the other members of Commitee D on #committeed on freenode. [Logs are available in http://svn.donarmstrong.com/don/trunk/projects/gplv3/] Don Armstrong -- If it jams, force it. If it breaks, it needed replacing anyway. -- Lowery's Law http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Why TPM+Parallel Distribution is non-free
MJ Ray wrote: Terry Hancock <[EMAIL PROTECTED]> wrote: > The case has been made that CCPL3.0 is DFSG-non-free because it > does not allow the distribution of content in TPM'd format[0]. I > assert that not only is this argument false, it is actually > reversed: allowing TPM distribution, even with parallel > distribution of non-TPM versions of the same content actually > permits a violation of the DFSG, [...] I agree that Terry Hancock asserts allowing TPM-parallel licences is "a violation of the DFSG" but does not support that with any evidence. No. I said it permits a violation. What a platform owner may do, is take an otherwise free+copyleft work and release it under non-free terms. He may do so in a way that obstructs competition from free+copyleft works. It is essentially the removal of the copyleft on the work. You are of course right that effective copyleft is not required by the DFSG. However, I find it highly disturbing to imagine that the Debian Project is taking a position against the support of copyleft to retain future freedoms for users. So is finding For the rest of this message, I concentrate on the argument that prohibiting all TPM is fine under the DFSG. Prohibiting TPM *distribution* is fine under DFSG. This is exactly what the Aug 9 draft of CCPL3.0 says: """ You may not impose any technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise their rights granted under the License """ The entire section refers to *distribution*, not *use* (this should be obvious from the wording -- if we aren't talking about distribution, then who is the "recipient"?). The requirement is needed to ensure that copyleft preserves the freedoms granted by the content's author. Note that it occurs in parallel with the standard copyleft statements which make it clear that no further restrictions may be imposed. TPM is merely being included as one such means of applying restrictions against users' freedoms. > I think it is not because it hinders free redistribution and discriminates against use of some platforms. Not only is this untrue, but it is in fact reversed. Allowing TPM distribution allows a platform-owner to obstruct redistribution of the work. > Debian's determination that parallel distribution of non-TPM files > alongside TPM files will solve this problem is based on the FALSE > idea that binary/source distribution is analogous to TPM/non-TPM > distribution. Problems I see with this argument so far: > 1. AFAICT, parallel distribution was first suggested as a TPM-countermeasure [in 2003 at least] long before the binary/source analogue was first used in explanation [in 2005] so how can it be based on it?; Oh give me a break. Like they weren't thinking of that in 2003. The analogy is obvious. That it is incorrect is less so. This has little to do with my argument, though. It just shows a plausible explanation for a mistaken consensus. But explanable or not, the consensus is mistaken. > 2. the restrictions of a licence that permits parallel distribution need not be non-copyleft; The anti-TPM clause is part of the copyleft. It is essential to preserve the freedom of the work, hence it is essential to copyleft. Saying that a work distributed for platform A is "free" because you can play derivatives on platform B, even though you can't play them on A, is just double-speak. Obviously, a real copyleft insists that you can modify a work and play it back on the platform the work was designed for (that you can do so on other platforms is also required). > 3. Debian has not determined it - we are not at that late a stage yet; Good. Let's *not* determine it, because it's wrong. > 4. Debian is a distribution - probably the above meant the debian project. That's called "synecdoche". > However it misses the most critical point about TPM systems, which > is that they acquire their force not from "technology" (despite the > name), but from "law". As I mentioned on cc-licenses, this is incorrect. The technology is potentially problematic. But it is only when the law is coupled to it that it becomes a serious impediment. A purely technologic obstacle can always be overcome (and once the solution is available, then it can be shared legally if the solution is not itself illegal). Consider DeCSS. The technology was overcome quickly, but Debian still can't distribute the resulting library for legal reasons. > Also, CC3.0draft appears to prohibit use of that technology, regardless of whether or not a bad law is active - it appears to export the DMCA to everywhere. Actually, that's a valid point. I'd be happier if it made it clear that "TPM" means only legally-backed TPM. I can't see that it makes any real difference with the current wording, though. > It is not truly the fact that TPM is difficult to reverse that is > the problem, but rather that it
Re: Non-free IETF RFC/I-Ds in source packages
Simon Josefsson wrote: http://wiki.debian.org/NonFreeIETFDocuments A useful thing to add to that page would be simple instructions on how those authoring IETF documents could make them available under a DFSG-free licence (presumably in parallel to the IETF one) - perhaps some sample boilerplate text to include. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: compatibility of bsd and gpl
Markus Laire wrote:
On 10/9/06, Arnoud Engelfriet <[EMAIL PROTECTED]> wrote:
Matthew Wala wrote:
> Is clause 3 of the BSD license ("The name of the author...")
GPL-compatible?
Yes, because GPL article 1 has a corresponding requirement.
I don't see any such requirement in GPLv2[1] article 1:
I don't see there anything which says anything like BSD[2] clause 3:
: Neither the name of the nor the names of its contributors
: may be used to endorse or promote products derived from this software
: without specific prior written permission.
Is there a good reason why this isn't considered an additional restriction?
As I understand it, most trademark laws already stop you from claiming
that Joe Random Hacker endorses things when he hasn't given you
permission to say so.
Thusly, clause 3 of the BSD license isn't so much adding a restriction
as failing to grant an additional permission, and then drawing your
attention to something that would be the case with or without the license.
--
Lewis Jardine
IANAL, IANADD
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why TPM+Parallel Distribution is non-free
Francesco Poli wrote: On Sun, 08 Oct 2006 21:45:46 -0500 Terry Hancock wrote: > So, are you asserting that if the CCPL3.0 included an allowance to > distribute TPM'd files, so long as the key necessary to apply TPM > to modified works based on the non-TPM'd version were publically > available (or always available as part of the non-TPM'd > distribution)? Am I asserting that if $LONG_SENTENCE, then what? I'm not sure I understand your question, since something seems to be missing in it... :-/ Yes, you're right. Obviously, I was asking that if this were true, "... you would claim the license were DFSG free". I would agree with you in that case, but I would also claim that such agreement implies the existing license is DFSG free (because there is no difference in principle between them. Both restrict certain platforms in exactly the same way -- they do not allow distribution of works already encrypted to work only on that platform). > What is the basis for Debian's objection to the anti-TPM clause? > Isn't it that it is considered to be "discriminatory" against > "person or fields of use" because it (supposedly [1]) discriminates > against users of TPM systems? AFAICT, the objection is that an anti-TPM clause (such that it forbids any TPM in any case) forbids porting to some platforms. I would agree with you in the case that all application of TPM is forbidden, but as I've mentioned, that change is already conceded. The end user can apply TPM if needed. In the case of interest (the TPM key is publically available), this already provides the user with the freedoms you ask for (he is certainly able to use the content on that platform). In the case that the key is not available, your alternative wording continues to restrict the users ability to use the platform. But of course, that is not the license, the license-writer, or the licensor's fault. It is a decision made by the owner of the platform. > I think that no such porting should be disallowed, as long as it can be done without denying recipients the ability to exercise the rights granted by the license. But one of the rights granted by the license is to produce modified works that can also be used by the user on ANY platform, including the one he's currently using. Certainly if the platform is common enough for it to matter that use on it is unrestricted, then it's common enough for a restriction against making works for it to also matter? It seems paradoxical to me that Debian should take such pains to allow free works to be ported to restricted platforms, "because of freedom", but then to dismiss the loss of freedom that results from doing so. Likewise, a clause that forbade porting the work to Windows systems would be considered non-free. Then the GPL is "non-free" if Microsoft decides to implement a system to scan the package file and refuse to unpack, install, or run the file if it finds a copy of the GPL license in it. (Strictly speaking, I think it would have to look for the GPL notices that must be retained in the binary -- harder to implement, but the same in principle). > You see, I think the thing you might be missing here is that the > creator of the work has no control over whether the TPM key might > or might not be available: it is a property of the platform, just > like the platform being TPM-only. I am well aware of this. Just as the presence of a third-party software patent that covers a piece of software is not under control of its author. Again, you are inconsistent. If *this* is not non-free, then neither is the existing anti-TPM distribution clause. Both restrict distribution of files in a format that can only be read on a certain platform. If the key is publically available, then in practice, the user will have exactly the same freedoms, because it's possible to encrypt files after receiving them. Note that in the "anti-GPL platform" example above, the end user can remove the GPL license for the purpose of running a program (*use*). But he still has to include it when distributing the package (*distribution*). Likewise, the existing CCPL3.0 terms require the file to be distributed in a non-TPM'd format, but the end user may apply TPM in order to play the content. The anti-TPM clause in CCPL3.0 is a *distribution* requirement. It places NO *use* requirements whatsoever. If a platform uses TPM to prevent the work from running on it, and provides no means (e.g. a publically available encryption key) to allow the work to be run on it, there's nothing we should be required to do about it. > So the point is, no end-user freedom is gained by your proposal: > either proposal allows the end user to install content on TPM-only > platforms for which a TPM encryption key is publically available > and denies it on platforms for which it is not. In fact, the only > thing it gains is increased complexity of the license. The end-user freedom that is
Re: Non-free IETF RFC/I-Ds in source packages
Simon Josefsson <[EMAIL PROTECTED]> writes: > Bug #390664 inspired me to look in source packages for IETF RFC/I-D's > too, and the situation seem to be more problematic. I've put a list > of packages in testing (as of a few days ago, my mirror is slow) that > appear to contain IETF RFC or I-D's at: > > http://josefsson.org/bcp78broken/ietf-in-src.txt > > There are certainly false positives in that list (I know of some), and > some have already been reported. The regexp I used was: > > -e rfc[0-9]+\.txt \ > -e draft-.*[0-9][0-9]\.txt \ > > But still, that's 73 source packages. > > I will try to go through them and report bugs, but I could use help in > analysing the packages for false positives. Perhaps a page on > wiki.debian.org could be used to co-ordinate this. I've created a wiki page to co-ordinate the effort, see: http://wiki.debian.org/NonFreeIETFDocuments In particular, I'd like help on improving the bug report template. Unless it turns it is a bad idea to do so (thoughts welcome!), I'll send the bug reports next weekend. I've cc:ed debian-devel to reach a wider audience. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: compatibility of bsd and gpl
On 10/9/06, Arnoud Engelfriet <[EMAIL PROTECTED]> wrote:
Matthew Wala wrote:
> Is clause 3 of the BSD license ("The name of the author...") GPL-compatible?
Yes, because GPL article 1 has a corresponding requirement.
So there is no conflict in licensing terms, and therefore
you can release the whole under the GPLv2 license terms.
I don't see any such requirement in GPLv2[1] article 1:
: 1. You may copy and distribute verbatim copies of the Program's source code
: as you receive it, in any medium, provided that you conspicuously and
: appropriately publish on each copy an appropriate copyright notice and
: disclaimer of warranty; keep intact all the notices that refer to this
: License and to the absence of any warranty; and give any other recipients
: of the Program a copy of this License along with the Program.
:
: You may charge a fee for the physical act of transferring a copy, and you
: may at your option offer warranty protection in exchange for a fee.
I don't see there anything which says anything like BSD[2] clause 3:
: Neither the name of the nor the names of its contributors
: may be used to endorse or promote products derived from this software
: without specific prior written permission.
Is there a good reason why this isn't considered an additional restriction?
[1] http://www.gnu.org/copyleft/gpl.html
[2] http://www.opensource.org/licenses/bsd-license.php
--
Markus Laire
Disclaimer: IANAL, IANADD
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
