SourceForge Balances Between Community, Lawmakers

February 19, 2010, 4:26 PM —

Late last month, the folks over at SourceForge.Net found themselves in a bit of a kerfuffle regarding their decision to start enforcing US export laws regarding the transfer of technology to certain individuals, companies, and entities (a.k.a. nations the US has deemed bad news). The way they decided to enact this enforcement was block the IP addresses from these nations (which include Cuba, Iran, North Korea, Sudan, and Syria).

That this was in also in compliance with a clause in SourceForge's own Terms and Conditions that has been there since, according SourceForge, 2003 seemed lost on the participants and industry watchers who raised a huge hue and cry about the move. Yet another case of not reading the fine print.

The reaction from the community was predictable, and understandable: open source, by its very nature, is designed to be shared. Plus, there was this irony: the exclusion of potentially innocent users from technology that is not only useful in a general sense but could ultimately help reform or overthrow the very regimes that are the cause of so much misery seemed, like many things bureaucratic, insane. Literacy is an enemy of tyranny.

Also clouding the issue is that while SourceForge's servers are located in the US, many of the developers and project owners are decidedly not US citizens. Why should projects from non-US citizens get blocked based on US laws?

The good news is, SourceForge is attempting to mitigate the concerns of the community while complying with US law. Last week, SourceForge announced that it was changing its blanket IP blocking policy. By default, every project hosted on SourceForge will still be blocked, but now project owners can turn such restrictions off if they determine that their project is not subject to US export regulations.

While many users are willing to work with the new policy, others are voicing questions along the lines of "how should they know if they are in compliance with US export laws?" Many applications, for instance, implement passwords as part of their normal operations. If those passwords are strongly encrypted, maintains Greg Roach project maintainer for PhpGedView, even to the point of "calling a library md5() or sha1() function... [it] is against US law."

This is a difficult situation to parse out. US companies have an obligation to obey US law, whether they agree with it or not. SourceForge makes it very clear that they regret having to do any of this, because they acknowledge this runs against the grain of open source philosophy. On the other hand, non-US citizens should not be obligated to obey US laws.

There is, though, an apparent out for open source developers. The Export Administration Regulations seem to allow for open source releases of software with encryption included, provided the developers inform the US Department of Commerce's Bureau of Industry and Security. Note, I am being deliberately vague here, because I am not a lawyer, so read the fine print.

For now, this is likely the best move SourceForge can make. It meets their legal obligations, and reduces the pain factor for SourceForge participants. Not a perfect solution, put we don't live in a perfect world.