Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 241650 - truecrypt has a dangerous license.
Summary: truecrypt has a dangerous license.
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Crypto team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-12 19:33 UTC by Donnie Berkholz (RETIRED)
Modified: 2011-04-22 15:30 UTC (History)
15 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
TrueCrypt license 2.6 as of 2009-02-09 (TrueCrypt License 2.6 as of 2009-02-09.txt,25.24 KB, text/plain)
2009-02-09 10:30 UTC, Mike Auty
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Donnie Berkholz (RETIRED) gentoo-dev 2008-10-12 19:33:04 UTC
Please refer to http://lists.freedesktop.org/archives/distributions/2008-October/000273.html. In particular:

Recently, we had a request to add TrueCrypt to Fedora, and as part of
that, we did due diligence on the license. What our legal counsel
discovered was truly horrifying: not only was the license non-free, it
almost certainly opens the user and the distributor to serious risk of
legal action from the copyright holder, even if all conditions of the
license are met.

Since we'd rather not get involved in legal action, we might want to mask and remove this package.
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-10-12 21:19:59 UTC
Reading the Fedora thread, and in particular this email with the actual legal details:
http://lists.freedesktop.org/archives/distributions/2008-October/000276.html

I propose we update RESTRICT to be RESTRICT="mirror fetch bindist" as well as including a large warning. We already have RESTRICT=fetch in 6.0a, and the entire statement should be added to 4.3a.

That should resolve liability for Gentoo, but not for any end-user, placing truecrypt into the same status as proprietary applications that we package.
Comment 2 Daniel Black (RETIRED) gentoo-dev 2008-11-03 17:25:58 UTC
I've gone for Robin's suggestion at the moment. I'm open for reexamining it if the truecrypt folks change. Happy to rexamine inclusion later.

Thanks Donnie and Robin.
Comment 3 Daniel Black (RETIRED) gentoo-dev 2008-11-03 17:54:30 UTC
package masked due the the cascading failure legal troubles. adversion to patches by upstream,  and build problems #237493
Comment 4 Marcin Marszalek 2008-11-04 00:30:57 UTC
Seems like TrueCrypt is communicating on the issue, see http://lists.freedesktop.org/archives/distributions/2008-October/000280.html

Also the license was adjusted to address the most serious "sueing problem", see http://www.truecrypt.org/legal/license
Comment 5 Thomas Navara 2008-11-04 22:13:36 UTC
Please be much more careful when masking system-level packages. Political issues really are not reason to say CEO "sorry, closing business - we cannot access our HDD anymore"...

I have nothing against debates about licences on mailing lists, but this brutal action is like lightning directly into your NAS - if not noticed, requesting full backup recovery.
Comment 6 Michael 2008-11-05 07:59:19 UTC
I have read the lisece and tried to understand all aspects. As far as I see they want to protect themself against people re-releasing TrueCrypt with compromised Security (bogus features, security holes etc) that would harm the reputation of TrueCrypt. Becuase projects can be destoyed by destroying ther reputation.

A few things are not 100%ly clear and could be turned against the user / distributors maybe (I am no expert on this field), but certainly this is not the intend. So I would not call is 'dangerous'. I am sure the TrueCrypt people will look into the issue given some time.
Comment 7 Mike Auty gentoo-dev 2009-02-09 00:27:00 UTC
Is anyone keeping an eye on this topic to ensure we can reinstate truecrypt if they fix the issue?

Do we have our own legal team that we can ask to look over this kind of thing, or are we relying on devs/other distributions to determine what's legal for us and what's not?

I'm concerned that this package might go unmaintained simply because it's been masked.  The build problems that were also cited as reason to mask this package have been closed as WONTFIX because the package is masked, which is a little cyclic.  One or the other of these bugs should be open...

It doesn't sound like it's any fun to maintain, but it's a relatively important package to have, and I'd hate to see it masked and forgotten just because it was tricky to deal with.  Yaroslav (from bug 245322) seems eager to help keep the package alive, perhaps he could be drafted in to help maintain it, even in its masked state?
Comment 8 Daniel Black (RETIRED) gentoo-dev 2009-02-09 06:57:39 UTC
(In reply to comment #7)
> Is anyone keeping an eye on this topic to ensure we can reinstate truecrypt if
> they fix the issue?

I think I said I would - just running out of time as usual.

> Do we have our own legal team that we can ask to look over this kind of thing,
> or are we relying on devs/other distributions to determine what's legal for us
> and what's not?

I assumed the foundation has access to a legal team. What was really required was for a good summary to be made of all issues/public legal statements.

> I'm concerned that this package might go unmaintained simply because it's been
> masked.  The build problems that were also cited as reason to mask this package
> have been closed as WONTFIX because the package is masked, which is a little
> cyclic.  One or the other of these bugs should be open...

I'm voting for the legal ones to be fixed first. Once there is a clear go-ahead there then the rest can follow.
 
> It doesn't sound like it's any fun to maintain, but it's a relatively important
> package to have, and I'd hate to see it masked and forgotten just because it
> was tricky to deal with.  Yaroslav (from bug 245322) seems eager to help keep
> the package alive, perhaps he could be drafted in to help maintain it, even in
> its masked state?

Sure. I still see legal issues as the first thing to resolve though. Volunteers welcome - please attach a summary of dates, license changes and what decisions were made by other distros because of this and your recommendation and we can pass it to the Gentoo Foundation/Gentoo devs list and see if they want to escalate it to lawers.
Comment 9 Mike Auty gentoo-dev 2009-02-09 10:30:39 UTC
Created attachment 181425 [details]
TrueCrypt license 2.6 as of 2009-02-09

That's a difficult task for a non lawyer, since there's an awful lot of hearsay and non-legal talk to dig through and it's not clear what would be relevant and what woudln't be.  Otherwise it seems just to be the fedora guy's post (since all the Debian/etc posts are pretty ancient) and a copy of the license.  Would it not be possible simply to ask the foundation whether TrueCrypt license 2.6 (as found on their website as of today, and pasted below) has any issues for us?
Comment 10 Ferris McCormick (RETIRED) gentoo-dev 2009-02-28 00:06:35 UTC
I'll look at it in a bit (realistically, probably Monday), once I break down the extremely long lines into something I can easily read and print.

My first impression is that we should not have much problem with it because all we do is distribute the source (and so Chapter III would not seem to apply:  we're not modifiying anything).  Now, our users would have to comply with the license as well if they plan to distribute it themselves, and I suppose the ebuild should make this clear (don't we have other packages like that?).

I'm probably just going to contact the truecrypt people (there is a contact name on the license) if there are any questions and explain the situation and see what they say.  But first I have to read the license carefully myself.

For the Foundation,
Ferris
Comment 11 Ferris McCormick (RETIRED) gentoo-dev 2009-03-03 15:54:44 UTC
A couple more comments.  Current version is 6.1a and the license is changed to 2.6, so the ebuild and licenses directory need to be updated to reflect that.  The attached file is not quite correct (it is misnumbered:  E.g., III.1.4 instead of III.1.d.  The license on the site and included with the source seems to be correct.

1.  We should add the license from the source to our licenses and update the ebuild to reflect this.  I do not know if the license is available as a text file at the truecrypt.org site or not.  The html version is:
http://www.truecrypt.org/legal/license
and it is distributed in text form as:  truecrypt-6.1a-source/License.txt.

2.  Except for the misnumbering, the attached license 2.6 seems to be the same as the referenced official version and the version distributed with the source, so we should take the text version from the current source.

3.  We should continue to ask the users to download the source themselves because they really must explicitly accept the license in order to download the source.  Source download is still:  http://www.truecrypt.org/downloads2.php
(and ask for the .tar.gz version for Mac/Linux of course).

4.  Since we do not provide source nor do we modify anything, my first reaction is that providing the ebuild under these conditions creates no problems.

5.  RESTRICT=bindist is probably a good idea as long as the user can build binary packages with a warnning, because the license allows any user to distribute it among the user's own systems.  Beyond that, it is the user's responsibility to comply with the license, but generally there are no problems unless someone changes the source or repackages truecrypt into something else.

6.  I will consider this further and perhaps contact the truecrypt foundation, but right now I don't see a problem.

7.  Current license seems to address some of Fedora's concerns, but not all.  On the other hand, we do not distribute truecrypt except as an ebuild, and should continue to RESTRICT="mirror fetch".  I suggest also BINDIST just to make sure the user is aware of possible problems.  Also, the warning in the ebuild is a good idea.

This is probably more cautious than it needs to be, but (1) we should not distribute the source from our mirrors without permission from truecrypt (which I'll pursue if people wish), (2) more importantly, to protect ourselves and our users, we must make our best effort to get the users to read the license and agree to it.

Nothing here is meant to suggest that we should mask or withdraw the ebuilds for trueuecrypt.  I am not sure that -4.3 is available at all anymore, though, and I don't think source for -6.0 is available, either (at least, if it is, it's not clear where).  Thus, we should provide an ebuild for -6.1a.
Comment 12 Ferris McCormick (RETIRED) gentoo-dev 2009-03-03 19:29:57 UTC
By the way, for an ebuild for -6.1a, all patch files in the ebuild for -6.0a ebuild are wrong, and I think you need a depend on dev-libs/nss (at least, the source wants to get at pkcs11.h, and the only one I have lying around is
/usr/include/nss/pkcs11.h)
Comment 13 Mike Ruskai 2009-03-10 08:54:21 UTC
I'm updating a few of my Gentoo boxes right now, and because of the problems caused by masking this package, I ended up here.

I have to say, this "bug" is pure rubbish.  Masking a package due to some sloppy wording in a license, which has no impact whatsoever on the users of Gentoo (unlike the act of masking a package), is irresponsible at best.

Leave petty squabbling about licenses out of the guts of Portage.  Put one of those lame warnings at the end of the build, if it assuages your nit-picking compulsion.  But don't break the damn system for what amounts to absolutely nothing of actual consequence.
Comment 14 ZeLegolas 2009-03-10 10:35:11 UTC
(In reply to comment #13)
> I'm updating a few of my Gentoo boxes right now, and because of the problems
> caused by masking this package, I ended up here.
> 
> I have to say, this "bug" is pure rubbish.  Masking a package due to some
> sloppy wording in a license, which has no impact whatsoever on the users of
> Gentoo (unlike the act of masking a package), is irresponsible at best.
> 
> Leave petty squabbling about licenses out of the guts of Portage.  Put one of
> those lame warnings at the end of the build, if it assuages your nit-picking
> compulsion.  But don't break the damn system for what amounts to absolutely
> nothing of actual consequence.
> 

I agee 100%!!!
Comment 15 ZeLegolas 2009-03-10 10:38:23 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > I'm updating a few of my Gentoo boxes right now, and because of the problems
> > caused by masking this package, I ended up here.
> > 
> > I have to say, this "bug" is pure rubbish.  Masking a package due to some
> > sloppy wording in a license, which has no impact whatsoever on the users of
> > Gentoo (unlike the act of masking a package), is irresponsible at best.
> > 
> > Leave petty squabbling about licenses out of the guts of Portage.  Put one of
> > those lame warnings at the end of the build, if it assuages your nit-picking
> > compulsion.  But don't break the damn system for what amounts to absolutely
> > nothing of actual consequence.
> > 
> 
> I agee 100%!!!
> 

Fix: I agree 200%!!!
Comment 16 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2009-03-10 15:37:58 UTC
Hi,

If we screw up and get sued, its *our* trustee's asses who get dragged to court, not yours.  So why not let us deal with the licensing issues (which are real for Gentoo, since Gentoo is US-based).  You are free to unmask the package, to write your own ebuild, to copy our ebuild and modify it, and basically do a bunch of other stuff to get this working; most of these steps take less time than whining about it on this bug.
Comment 17 Martin DiViaio 2009-04-05 21:48:08 UTC
Is there an ETA on unmasking this package?
Comment 18 Roy Bamford gentoo-dev 2009-05-03 19:16:15 UTC
Added this bug to the agenda for the trustees May 17 meeting.
Comment 19 Robin Bankhead 2009-05-09 10:48:00 UTC
Hoping a solution can be reached. This saga led me to replace truecrypt with cryptsetup/luks, and after a couple of weeks' use I can say the Windows support (FreeOTFE) is light-years behind truecrypt in usability and stability.  A BSOD on attempting to mount became the expected behaviour.

That leaves truecrypt as the only viable cross-platform FOSS (more or less) disk-encryption software available. It's needed, and I'd say (though IANAL) that Ferris's analysis in comment #11 holds water: hardly the first time you've had to work around a dangerous license.
Comment 20 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-05-17 20:08:14 UTC
crypto team:
per the Trustees meeting of May 17th, 2009, you're free to include the ebuild, however it should have RESTRICT="mirror fetch bindist" as well as an ewarn in the ebuild that the user must accept the license and should be aware of the distribution restrictions from upstream.
Comment 21 Mike Auty gentoo-dev 2009-05-17 20:19:07 UTC
Just to add, truecrypt-6.2 is now out.
Comment 22 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2009-05-17 20:24:16 UTC
(In reply to comment #21)
> Just to add, truecrypt-6.2 is now out.

We know about it due to bug #245322 :) .
Comment 23 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2009-05-18 02:33:39 UTC
app-crypt/truecrypt has been unmasked.
Comment 24 Marko Weber Bürgermeister 2009-05-25 22:17:29 UTC
(In reply to comment #23)
> app-crypt/truecrypt has been unmasked.
> 

i get this error on compiling

x86_64-pc-linux-gnu-g++ -MMD -I/var/tmp/portage/app-crypt/truecrypt-6.2/work/truecrypt-6.2-source -I/var/tmp/portage/app-crypt/truecrypt-6.2/work/truecrypt-6.2-source/Crypto -I/usr/include/pkcs11-helper-1.0 -O2 -fno-strict-aliasing   -DTC_UNIX -DTC_LINUX -fdata-sections -ffunction-sections -Wall -Wno-sign-compare -Wno-unused-parameter -O2 -pipe -c ../Common/SecurityToken.cpp -o ../Common/SecurityToken.o
In Datei, eingefügt von ../Common/SecurityToken.h:43,
                 von ../Common/SecurityToken.cpp:25:
/usr/include/pkcs11-helper-1.0/pkcs11.h:1263:1: Warnung: »NULL_PTR« redefiniert
In Datei, eingefügt von ../Common/SecurityToken.cpp:25:
../Common/SecurityToken.h:20:1: Warnung: dies ist die Stelle der vorherigen Definition
../Common/SecurityToken.cpp: In member function »TrueCrypt::Pkcs11Exception::operator std::string() const«:
../Common/SecurityToken.cpp:660: Fehler: »CKR_NEW_PIN_MODE« wurde in diesem Gültigkeitsbereich nicht definiert
../Common/SecurityToken.cpp:661: Fehler: »CKR_NEXT_OTP« wurde in diesem Gültigkeitsbereich nicht definiert
make[1]: *** [../Common/SecurityToken.o] Fehler 1
make[1]: Leaving directory `/var/tmp/portage/app-crypt/truecrypt-6.2/work/truecrypt-6.2-source/Volume'
make: *** [all] Fehler 2
 *
 * ERROR: app-crypt/truecrypt-6.2 failed.
 * Call stack:
 *               ebuild.sh, line   48:  Called src_compile
 *             environment, line 3414:  Called die
 * The specific snippet of code:
 *       emake ${EXTRA} NOSTRIP=1 NOTEST=1 VERBOSE=1 CC="$(tc-getCC)" CXX="$(tc-getCXX)" AR="$(tc-getAR)" RANLIB="$(tc-getRANLIB)" TC_EXTRA_CFLAGS="${CFLAGS}" TC_EXTRA_CXXFLAGS="${CXXFLAGS}" TC_EXTRA_LFLAGS="${LDFLAGS}" WX_CONFIG="${WX_CONFIG}" PKCS11_INC="${pkcs11_include_directory}" || die "emake failed"
 *  The die message:
 *   emake failed


emerge --info

Portage 2.1.6.11 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r1, 2.6.29.4weberV2.2 x86_64)
=================================================================
System uname: Linux-2.6.29.4weberV2.2-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5600+-with-glibc2.2.5
Timestamp of tree: Mon, 25 May 2009 19:45:01 +0000
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p39
dev-java/java-config: 1.3.7-r1, 2.1.7
dev-lang/python:     2.4.4-r13, 2.5.4-r2
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.6-r2
sys-devel/autoconf:  2.13, 2.63
sys-devel/automake:  1.4_p6, 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://de-mirror.org/distro/gentoo/ ftp://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ ftp://mirror.netcologne.de/gentoo/ "
LANG="de_DE.utf8"
LC_ALL="de_DE.utf8"
LDFLAGS="-Wl,-O1"
LINGUAS="de en"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="X acl amd64 animgif apache2 authdaemond bash-completion berkdb bindist bzip2 caps clamav cli cracklib crypt ctype cups curl daemon deflate doc dovecot-sasl dri examples fam filter fontconfig fortran fpx gd gdbm gif gpm graphviz gs hdri iconv imagemagick imap ipfilter isdnlog jbig jpeg jpgraph latin1 lcms logrotate managesieve midi mmx mudflap multilib munin-apache mysql mysqli ncurses nls nptl nptlonly openexr openmp pam pcre pdo perl php png pop3d pppd python q32 q8 quotas readline reflection restrict samba sasl session sieve sockets spamassassin spl sse sse2 ssl symlink sysfs syslog tcpd tiff tools transparent-proxy truetype unicode user-homedirs xinetd xml xmlreader xmlrpc xmlwriter xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Comment 25 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-05-25 23:27:04 UTC
weber@zackbummfertig.de:
please file your error as a new bug.
Do NOT reuse closed bugs like this.
Comment 26 Mike Auty gentoo-dev 2009-05-26 00:03:25 UTC
Marko, you're experiencing bug 271186 which is itself a duplicate of bug 271141, please post any additional comments you might have there...
Comment 27 Anna 2011-04-22 15:30:12 UTC
What follows is my opinion as a concerned citizen, not as a lawyer, since I am not a lawyer. As such, it should not be taken as professional legal advice. I will, however, point out that I am literate, and that the entire reason for the invention of written law, all those millenia ago, was so that common people like us would be able to know what precisely the law was. Well, literate common people, at least, or those who knew people who were literate.

Take a look at VI.7
"7. IF (IN RELEVANT CONTEXT) ANY PROVISION OF CHAPTER IV OF THIS
LICENSE IS UNENFORCEABLE, INVALID, OR PROHIBITED UNDER
APPLICABLE LAW IN YOUR JURISDICTION, YOU HAVE NO RIGHTS UNDER
THIS LICENSE AND YOU MUST NOT USE, COPY, MODIFY, CREATE
DERIVATIVE WORKS OF, NOR (RE)DISTRIBUTE THIS PRODUCT, NOR ANY
PORTION(S) THEREOF."

Okay, so if any part of Chapter IV is unenforceable, invalid, or prohibited where I live, I'm not allowed to use, copy, modify, create derivative works of, or redistribute Truecrypt? What am I allowed to do with it, then? Read it, I guess. Chapter IV is the "Disclaimer of Liability, Disclaimer of Warranty, Indemnification" chapter, so I'm not sure the "in relevant context" restriction would help me challenge VI.7.

While we are on the topic of portions of licenses being "prohibited by law", I would point out that the last part of this segment "nor any portion(s) thereof" is prohibited by law. The Truecrypt people have no legal right to prevent my from using any portion of Truecrypt which is under a third party license, e.g. the parts by Brian Gladman under his BSDish license, even if some part of Chapter IV is unenforceable where I live, so long as I comply with said third party license. Thus, it should be modified, "nor any portion(s) thereof, excepting of course those portions released under third-party licenses."

Still, it would be a lot saner if they removed VI.7 and allowed VI.8 to become the new VI.7:
"8. Except as otherwise provided in this License, if any
provision of this License, or a portion thereof, is found to be
invalid or unenforceable under applicable law, it shall not
affect the validity or enforceability of the remainder of this
License, and such invalid or unenforceable provision shall be
construed to reflect the original intent of the provision and
shall be enforced to the maximum extent permitted by applicable
law so as to effect the original intent of the provision as
closely as possible."

VI.6 is also pretty terrifying.
"6. IF YOU ARE NOT SURE WHETHER YOU UNDERSTAND ALL PARTS OF THIS
LICENSE OR IF YOU ARE NOT SURE WHETHER YOU CAN COMPLY WITH ALL
TERMS AND CONDITIONS OF THIS LICENSE, YOU MUST NOT USE, COPY,
MODIFY, CREATE DERIVATIVE WORKS OF, NOR (RE)DISTRIBUTE THIS
PRODUCT, NOR ANY PORTION(S) OF IT. YOU SHOULD CONSULT WITH A
LAWYER."

Okay so if there is any portion of this license that I am not 100% sure of my understanding and ability to comply with, I don't get to use, copy, modify, create derivative works of, nor redistribute Truecrypt. (Again, the prohibited-by-law "nor any portion(s) of it", which ought to be "nor any portion(s) of it, excepting of course those portion(s) under third-party licenses".) Look, I'm all for complying with licenses, but what normally happens between civilized open source developers when one does their best to comply with license of another, but fails for whatever reason, the developer(s) who have been infringed upon contact the infringing developer and tell that developer, sometimes not too nicely, what is wrong and what they have to do to fix it. And it gets fixed, it's a huge embarrassment, not to mention the inconvenience of removing the infringing versions from the source history, yada yada yada. What doesn't happen is the infringing developer is told they are never allowed to so much as use the software they accidentally infringed upon ever again. Because people who mean well do sometimes screw up, particularly when they are better at reading C than legalese.

Now, let's go on to this segment of III.1.d:
"   Portions of the source code of Your Product not contained in
    This Product (e.g., portions added by You in creating Your
    Product, whether created by You or by third parties) must be
    available under license(s) that (however, see also
    Subsection III.1.e) allow(s) anyone to modify and derive new
    works from the portions of the source code that are not
    contained in This Product and to use, copy, and redistribute
    such modifications and/or derivative works. The license(s)
    must be perpetual, non-exclusive, royalty-free, no-charge,
    and worldwide, and must not invalidate, weaken, restrict,
    interpret, amend, modify, interfere with or otherwise affect
    any part, term, provision, or clause of this License. The
    text(s) of the license(s) must be included with every copy
    of Your Product that You make and distribute.

Now, I have already proven that the Truecrypt license does not meet the conditions of "non-exclusive" or "worldwide". Who is excluded? Anyone who lives somewhere where any portion of Chapter IV is unenforceable, invalid, or prohibited under applicable law, and anyone who is unsure of their understanding or ability to follow the license. So if you are modifying Truecrypt, you aren't allowed to release your modifications under the Truecrypt license or anything terribly similar to it. However, the parts of Truecrypt already under the Truecrypt license must remain under it. So all modifications have to be released under a license that is one-way compatible with the Truecrypt license, something that does not prohibit itself from being distributed along with the code that is under the Truecrypt license, but which is freer that the Truecrypt license is. A 3-clause BSD license would work, I think.

This makes me wonder if/how they manage to modify their own software without infringing on anyone's rights.

For reasons mentioned by others, for the reasons I mentioned above, and for reasons no one has bothered to mention, I do not believe the Truecrypt license is something third-party distributors have much hope of being able to follow. In fact, unless you live in a country that has no copyright laws, there seems to significant reason to doubt if it is even legally safe to use Truecrypt.

Software has been removed from various projects' ports and packages before for licenses that were impossible or created too much hassle to follow.
http://archives.neohapsis.com/archives/openbsd/2001-08/thread.html#2543

Now, instead of Darren Reed's IPFilter and its weird license, we have OpenBSD's pf, which is even better and is under a nice happy BSD license.

If some people really wanted to port Truecrypt compatibility to their open source operating system, they could do it the way the BSD developers port compatibility with GPL'ed code to a new BSD-licensed code: One person reads the source, treating it as documentation, and explains what needs to be done. The second person, who has not seen the original code, only the first person's explanations, then writes new code under the desired license. (Reverse engineering, basically, but easier than reverse engineering binaries because someone actually gets to read the source code.)

However, if a cross-platform block-level encryption system is what is desired, it would probably be less of a legal nightmare to simply take something that is already under a sane license, e.g. 2-or-3-clause BSD or GPL (personally, I prefer BSD), and proceed to port it to a variety of operating systems (Linux, OpenBSD, FreeBSD, NetBSD, DragonflyBSD, Mac OS X, Windows). So that leaves geli, cgd, softraid, dm-crypt, and loop-aes, among others, each with their advantages and disadvantages.