TrueCrypt developer says no to license change for forking
pastebin.com
pastebin.com
The default licensing arrangement certainly meant we were (legally) covered, but we sought out the author and offered a financial arrangement in terms of support (we weren't proposing an especially onerous arrangement, and were quite clear in our 'improvements we fund, we're happy to go back to GPL' and it was very much an early stage of negotiations from our perspective). Weirdly it was dismissed outright.
Highly anecdotal, and the guy I had that contacted the TrueCrypt author may have given the wrong impression (unlikely), but since then I've always felt the project was in the 'slightly odd' category.
Sometimes it is better to not be associated with certain sources of funding if you want to keep your reputation clean and not being the subject of 'sold out' claims even if that isn't the case.
I'm a long-term free software advocate, and the network admin that was talking to the TrueCrypt author(s) was similarly minded, so there was absolutely no question we were seeking to taint the licence, risk the independence, demand credit or attribution, or anything along those lines.
Part of advocating free software in government agencies then (and probably also now) is that you are obliged to CYA in terms of having some mechanism by which you can demonstrate you can obtain support in the unlikely event of problems. It's a real pain in some cases (such as this), but in practice it's usually lip service at worst.
We were under no illusions - we'd heavily tested the software, and knew it was fit for purpose (it was a Windows XP rollout, so pretty well trodden ground). We were confident we'd never have to contact them again, once we'd thrown them some cash.
Just trying to evaluate what those might include could be a very extensive and unachievable exercise.
I can imagine someone in a position like that of the TrueCrypt developers being loathe to enter into a scenario bringing with it such ramifications. Even setting aside any personal ideology, it has the appearance of a swamp in need of the obligatory sign, "Here Be Dragons".
Just my blue sky speculation, but based upon a number of years of casual and outside observation of facts and anecdotes that make it into the sphere of public knowledge.
But there was no 'come work for us' implied or explicit, of that I'm sure.
This was small to medium-sized Australian government agency, knowingly talking to people we (assume) were based in either Europe or the USA, either way off-shore.
We didn't even have a tentative contract to hand, and as I say I can't remember the details, but I suspect our opening inquiry was along the lines of 'has anyone else talked to you about this type of deal', leading into a 'we'd just like something on paper that will satisfy management that we've done due diligence'. Our expectation was that it would effectively be a donation to the project.
Clearly there was, for us, back then, no perceived risk at all TrueCrypt was about to be abandoned - and the project's response to fixing bugs far exceeded any non-free / proprietary software we were concurrently deploying.
Also, did they guy who contacted the TrueCrypt author mention any dollar amounts?
That aside ... :)
We hadn't talked cash at all, it hadn't even gotten that far.
I would speculate, thinking back at it, that I'd have been happy to throw somewhere around $10k at them. I'd just managed to save about $150k on MS licences, so my budget was looking healthy, and TrueCrypt solved a goodly number of our regulatory problems.
As I mentioned above we were in the very early stages, and were likely couching the arrangement in terms of a donation (in return for some vague assurances of assistance if it all went titsup).
1. https://www.ohloh.net/licenses/TrueCrypt_Collective_License (see section III)
Resources were invested by some to audit the code. The developer is uninterested in letting the code go on. I think the lesson is, don't invest significant resources in supporting a shared codebase, unless it's got a license that will let people continue to use/develop the codebase even without the original developer/owner's permission.
If you take and modify the source, you must remove all references to the "TrueCrypt" name inside of the source code and program interface and not call it TrueCrypt. If you redistribute it unmodified, you must leave the "TrueCrypt" name intact. I don't have a source for the second term, but it would seem to be impossible to have an unmodified work that didn't call itself TrueCrypt -- by removing TrueCrypt branding, you fulfilled the terms of the first part, even if the functionality of the software was actually unchanged.
The intent of the advertising clause is to assert and maintain control over the software in the hands of the creator/owner; this is fundamentally incompatible with FOSS ideology, where anyone can fork and edit, and the leadership of the project is "de-facto" as in the eyes of a community rather than "de-jure". That being said, it is annoying.
But why try to keep the dead horse alive? TC is really weirdly written, as a GUI app that has a command-line stapled onto it, instead of the other way around. (Last time I built it for a headless machine, I still needed wxWidgets.) Especially with the specter, even unlikely, that some unknown person may possibly rise up to claim ownership of the project someday.
We should understand TC because we're using it, but we should think about the next thing.
This may be another Lavabit situation.
Thanks buddy!
But from this response and how their website changed really makes me inclined to believe something is fundamentally broken in truecrypt.
We likely won't know what happened for several years after, if we ever learn at all.
How about we stop bothering the poor developer(s) and let them be. They have already contributed more to the world than most of us here - time for them to get the well deserved rest they seek.
What I don't like is to have some piece of infrastructure I've come to depend on yanked out suddenly, being mislead about the reasons, and being left with only onerous alternatives (rewrite the whole thing or stick with 7.1a indefinitely). That these two options are onerous is not speculation or simply some kind of bad attitude. It is a fact.
Whether this action was deliberate or just incredibly clueless and negligent, treating TrueCrypt users this way is crappy, and I think it's OK to say so publicly. I'm grateful for the development of TrueCrypt. But that gratitude doesn't translate to a free pass for all subsequent terrible behavior afterward.
If the dev's identity was known, he/she might take a lot more heat than a few harsh words. Considering the needless trouble he's putting people through, a strongly-worded letter of protest is a pretty mild reaction.
He tweeted: Most commercial encryption products are junk.
I put it this way --- bluntly, aggressively --- because there's a drive-by element to your comment; "critical flaw", "fundamentally broken", but absolutely no details whatsoever.
And I'd say he has a point. Laying aside your expertise for a moment, and without going all the way to declaring it fundamentally broken, don't you think there's something a little fishy in all this?
For whatever reason, he[1]'s done with the project. Maybe the wife and kids are more interesting these days. Maybe he got offended at auditors being paid and not him. Maybe he feels a responsibility towards his users and since he cannot actively defend them he wants them to move inside someone else's castle. Maybe he died and his brother took over the account long enough to say "we're done" and his brother really doesn't want to talk about it no matter how weird you think it is that his brother doesn't want a bunch of people on the Internet on his lawn like they were on Satoshi's.
It's like a bunch of blind cryptographers trying to describe an elephant.
[1] Assuming a heterosexual singular male just for convention.
I know that's shocking to OSS developers, but not everyone cares (at all) about Linux.
I may refer to this thread the next time someone asks "why don't companies give explanations to candidates they don't hire?" The answer is that the candidates feel compelled to prove that the company's reasons are flawed. Look how they react to someone deciding to stop working on a project.
So if I have to deal with The-Worst-Code-Base-Ever™ I create a new project and copy the code into the new project file by file in the order you would develop from scratch and clean it up before moving on to the next file. Improve the naming, split large functions, extract common code, unify similar code, look for and fix bugs, improve algorithms, comment out code that references code not yet in the new project or code not yet used and when there is a good opportunity improve the architecture - given that you already understand the code base well enough. It takes time, you touch some files a hundred times and move around bits and pieces seemingly forever, but I am pretty confident the result is better than rewriting everything from scratch. All this might be not such a good idea without good tool support, but if moving and renaming things or changing function signatures project wide is just a matter of seconds, there is real value in doing it incrementally instead of trying to do and get it right all at once.
If you can find parts to replace into separate services, that is best. So you can slowly migrate the system, whilst gaining the benefits quickly for the new code. That way, if the project takes a year, bug fixes can happen in the new code. Also features can be added to the new code.
Also, if after a year and the old system is still being used, then valid questions may be asked about what use the new system is.
YMWNV
There is no guarantee that a rewrite would be better than the original. And it will take man-years worth of effort to get even to where TrueCrypt is right now.
Pretty standard for the Hacker News crowd in my experience.
And I'm pretty sure crypto is hard to work with and get right, and one mistake removes the purpose of software.
The people who publish easy stuff are typically new developers/entrepreneurs, simply people with less practice. There aren't all that many amazing, experienced developers with deep toolkits and skills. Better to commend people for trying and critique their work for what it is, than bemoan the lack of depth.
This sort of comment slings mud at the efforts of the young and inexperienced, when we should be trying to form a welcoming community that helps them grow. Our duty is to be supportive and help comb through the chafe to help find the diamond tech, content, and comments. That's the point of being here.
I think it's critical for HN to welcome a wide spectrum of original work. We want to see major technical achievements, of course. But we also want to see the minor one-offs. The bar for sharing your work on HN should be low.
The relationship between major work and minor one-offs is mysterious. Things that start off playful and trivial can develop in unexpected ways. Or maybe a success at something trivial inspires someone to a more ambitious next effort. If we want to have a culture of people sharing things they've made—which we do—we need to accept that most won't seem very impressive.
A good example is 2048. That game and its many variations weren't necessarily technically impressive. But the way in which a whole bunch of people riffed on each other's work for a few weeks—that was one of the most creative things ever to happen spontaneously on HN. If the game itself had been less trivial, I doubt that would have happened. The barrier to entry would have felt too high, so people without much time or experience wouldn't have gone for it. But because it was so simple, making one's own variation felt doable, and lots of people did.
Heyyyy... FBaaS was my next big thing!
A similar observation can be made about web-based encrypted chat systems versus encrypted block device drivers.
Maybe something that is LUKS compatible so it works straight away on Linux and with a simple GUI for Windows that makes it as seamless as possible? (Sits in tray, autodetects when a container containing device is inserted and offers to mount it?)
It's not hard (as such), yet no such program exists.
With that being said there's many brilliant polyglot developers with lots of experience and maybe it's a task for developers with more years than average under their belt as the project will take more effort than an MVP.
The problem is the IO driver abstractions available on each platform are wildly different. Getting working filesystem driver code on Windows (7/8), Mac OS, and Linux is a non-trivial task that requires a lot of kernel mode hacking.
If you are willing to live with the performance impact, at least initially, you could use FUSE for MacOS/Linux. I don't recall if the Windows UMDF (User Mode Driver Framework) supports file system drivers or not.
Srsly: TC always had a weird license and we accepted it because the rest of the product (seemed to) work so well. He doesn't owe anyone anything.
"I don't feel that forking truecrypt would be a good idea,[...]. I believe that starting from scratch wouldn't require much more work than actually learning and understanding all of truecrypts current codebase."
?
Last but not least, the audit that took place some time ago went fine so there are no reasons to consider TrueCrypt less secure then anything else (in fact, it's quite the opposite) and no 'rewrite' is necessary.
Because they would be saying that they were going to do something that they had no plans to do?
>there are no reasons to consider TrueCrypt less secure then anything else (in fact, it's quite the opposite) and no 'rewrite' is necessary.
You have a different opinion than the one of the authors, and you're entitled to it. It's not nice to attack someone who has a different opinion, though, especially when it's about a piece of software that they developed, and offered free of use for many years. Their opinion may be more informed than yours, but it's at least as informed as yours.
He doesn't owe anyone anything.
EDIT Fox must have good lawyers because I couldn't find Comic Book Guy complaining about how Itchy & Scratchy owe him because they've given him hundreds of hours of entertainment for free.