I'd wondered this, too. My first (wrong) assumption was that the author was aiming for a different license with the Windows version, but it's GPL. If I had a

I'd wondered this, too. My first (wrong) assumption was that the author was aiming for a different license with the Windows version, but it's GPL. If I had a guess, aside from "because I wanted to see if I could", it might be because of inherent differences in the way the OSes behave with regard to filesystems[0] would make a re-implementation from spec work better (faster, more reliably or whatever), though the author goes quite a ways to point out that he's used none of the original source, as if to state it's a clean-room implementation and I'd speculate (wildly) that though there are likely more than a few differences in Linux/Windows' APIs, there is almost certainly a lot about how btrfs works that isn't different when implemented on both platforms. These APIs would affect how the code is designed, and attempting to port by converting API calls that are Linux specific and plugging in similar Windows API calls could lead to a less-ideal implementation than if one read the spec and designed it targeting the operating system's API directly[1]. And then there's my original, wrong, assumption: if this individual is the only author, and it appears they might be, it does give him/her the ability to dual-license it later; i.e. offer a commercial license which doesn't have GPL-related requirements or switch it out to a less restrictive Open Source license if the author so chooses. [0] I'm not an expert or even a n00b in this area. I, almost completely, know nothing about filesystem API differences between Linux and Windows since I don't know either the kernel interfaces for Linux or the Windows APIs related to the filesystem at any level having never written anything targeting that technology, directly. [1] A former project that I built a long time ago comes to mind where I tasked with porting a tool to change what it used for storing records. The technology I started with had no concept of saving array records to disk, requiring a separate write for each record. Non-ideal, but not terrible because the technology was optimised at doing many small writes. The new target could accept an array of records and write them all in one call. I did a "compatible" re-implementation, replacing calls with their equivalent in the new record store and the performance made the product unusable. It wasn't until I redid all of the record I/O with the target platform in mind that things started working properly.