I just got caught up on this thread, sorry to all for my late reply. First of all, I don't necessarily agree with Bruce that $45 is *necessarily* unreasonable, although it might be. I *do* think it's a lot of money just to get a copy of source code.
I nevertheless don't want to judge before knowing all the facts. I think if this matter were up for litigation over copyright infringement in the USA, this would be a question of fact for the jury: was the $45 fee actually a "charge no more than [Mikrotik's] cost of physically performing source distribution"? However, I don't think we should engage in enforcement *merely* over the "charge/price no more than…" clauses in GPLv2§3(b) and GPLv3§6(b). Speaking for my own GPL enforcement work, I'd be unlikely to pursue a matter if the *only* violation of GPL was, for example, "they charged $45, but it only actually cost them $25 to perform the source distribution". If they did that, as Arnt says, it *would* be a GPL violation and *would* be copyright infringement, and it would cause them to lose their rights of distribution per GPLv2§4 and GPLv3§8. However, you'd only be able to *prove* that violation via the legal discovery process (in a USA lawsuit, anyway), and it's not worth bringing the case for that sort of GPL violation "misdemeanor". I've got hundreds of "felonies" to go after anyway. Thus, what concerns me here most is that there are accusations going back to 2008 on this mailing list that Mikrotik's source code is not complete, corresponding source (CCS) for their distributed GPL'd binaries. If that's the case, then we should investigate. However, during that investigation, we should give Mikrotik the benefit of the doubt, and determine whether or not what they've provided is CCS. Those who want to look further in this matter are encouraged to contact me privately over at the GPL Compliance Project for Linux Developers ( http://sfconservancy.org/linux-compliance/ ) via <[email protected]>. Finally, with regard to Ralph and Arnt's discussions of binary checksum as way of CCS verification: I've do a *lot* of GPL compliance CCS verification; frankly, I've surely done and/or overseen more of it than anyone else in history. And, AFAICT, most GPL compliance training courses (like Linux Foundation's) and would-be GPL enforcers completely ignore this most important issue of GPL compliance: the source code must correspond to the binaries distributed, and must include "scripts used to control compilation and installation of the executable". And, if it doesn't, then it's IMO missed the point of the GPL entirely and is thus a serious and grave violation. (I often feel like one of just a few people in the world who has even ever *read* GPLv2§3's penultimate paragraph.) I'm thus grateful that folks on this list are discussing this important issue. That said, rote verification of a sha256sum of the binary virtually never works in CCS verification. I can't remember a single GPL enforcement case where I got the same md5sum/sha1sum/sha256sum [0] for the built binaries. However, I have determined GPL compliance in most of those cases where the checksums didn't match. What Ralph hints at is indeed right: All the GPL experts that I know believe that GPL requires the "scripts used to control compilation and installation of the executable" to include details about what specific compiler/linker should be used to build the software. However, compilers are famous for doing things like including a timestamp in the binary or a dozen other things that will yield a correct, corresponding binary but one that doesn't share the exact same checksum as the original binary. As such, if the checksums don't match, the CCS may still be adequate, and further investigation is needed to determine compliance. [0] I've been doing GPL enforcement since md5sum was the preferred checksum technique. :) -- -- bkuhn
