[OSGeo-Discuss] on Google Code and export restrictions

jo at frot.org jo at frot.org
Mon May 26 06:11:03 PDT 2008


dear all, this is a good overview of the implications for FOSS of
being made available from a service whose ToC invokes export
restrictions and which uses Geo-IP filtering to enforce them.
(Specifically, Google Code where some gvSIG plugins are hosted.)

[[ If the problem is that some add-ons for gvSIG, such as the simple
geoRSS feeder at http://code.google.com/p/georssgvsigsupport/ use Google
code, then that is another matter altogether, since it is that specific code
that may be subject to the restriction on export.
... resulting applications were themselves restricted under the same terms.]]

Of course, this must also break the "No restrictions on persons or
groups" provision in the OSI open source definition unless the source
is also available from a non-restricted location.

----- Forwarded message from Roger Longhorn <ral at alum.mit.edu> -----

CC: GSDI Legal-Economic Work Grouup <legal-econ at lists.gsdi.org>

Sergio Acosta y Lara wrote:
>What do you think of this?
>http://www.mes.edu.cu/index.php?option=com_content&task=view&id=87&Itemid=2 
>
>Shouldn't the Legal & Socioeconomic Working Group express an opinion 
>about it? A colleague from Cuba tried to download a software called 
>Sextante that runs over gvSIG (the open-source GIS software developed 
>by the Government of Valencia, Spain) but he couldn't do it: a message 
>appeared telling him "you are accessing this page from a forbidden 
>country". Sextante is also open-source and was created by the 
>Universidad de Extremadura (also Spain); as it seems that they are 
>using googlecode.com, anybody from Cuba (and from Iran, Libya, North 
>Korea, Sudan or Syria) cannot download this open-source software (that 
>is located in Spain). Directly concerning GSDI, G goes for Global. 
>Aren't these decisions going just in the opposite direction? Just an 
>opinion.
>Regards,
>Sergio

Hello Sergio,

You offer an interesting comment on an issue concerning restricting 
access to what should be freely accessible, open source software, where 
the decision to restrict access is not made by the software owner but by 
a third party - in this case, Google code (code.google.com), a US-based 
organisation, acting within restrictions placed on software exporting by 
the US government. The relevant clause in the Google code "Terms of 
Service" is:

"5.2 You agree to use the Services only for purposes that are permitted 
by (a) the Terms and (b) any applicable law, regulation or generally 
accepted practices or guidelines in the relevant jurisdictions 
(including any laws regarding the export of data or software to and from 
the United States or other relevant countries)."

These regulations are set by the US Bureau of Industry and Security 
(http://www.bis.doc.gov/policiesandregulations/index.htm) - see below:

"The Bureau of Industry and Security is charged with the development, 
implementation and interpretation of U.S. export control policy for 
dual-use commodities, software, and technology. Dual-use items subject 
to BIS regulatory jurisdiction have predominantly commercial uses, but 
also have military applications. In order to accomplish this objective, 
BIS seeks to promulgate clear, concise, and timely regulations. This 
section of our Web site provides a link to the Bureau's regulations 
governing exports of dual-use items (the "Export Administration 
Regulations"), codified at 15 Code of Federal Regulations, Chapter 7. It 
also provides discussions of certain key regulatory policy areas, 
including policies governing exports of high performance computers, 
exports of encryption products, deemed exports, U.S. antiboycott 
regulations, special regional considerations, the multilateral export 
control regimes, and the technical advisory committees."
<ends>

Due to the many uses to which geospatial data and tools (GIS software, 
remote sensing analysis software, etc.) can be put for 'military 
applications' (in fact, an entire sector within the GIS and RS 
industries!), it is not difficult to see why much of this software can 
fall under the export restriction classification.

In typical non-joined up government style, the BIS web site will then 
lead you off to web sites from the US Treasury Department, US State 
Department, and, most importantly, the Export Administration Regulations 
web site (http://www.access.gpo.gov/bis/index.html) in your search for 
information on what you can "export" and to whom - or not - and under 
what licenses or restrictions.

The simple solution is for both these open source software providers to 
stop offering their software via code.google.com, due to these 
restrictive practices.

If your concern is about not being able to access the base software via 
code.google.com, then this is avoided by simply using the developers' 
own sites to access the same software - which in the case of gvSIG is 
certainly possible - simply go to:

http://www.gvsig.gva.es/index.php?id=1729&L=2&K=1

and for Sextante, go to: http://www.sextantegis.com/en/index.htm

If the problem is that some add-ons for gvSIG, such as the simple geoRSS 
feeder at http://code.google.com/p/georssgvsigsupport/ use Google code, 
then that is another matter altogether, since it is that specific code 
that may be subject to the restriction on export. This would also apply 
to Sextante and any other open source software that used code from 
Google that was deemed to be non-exportable to certain countries - or 
even named individuals (yes, there is such a list! - see the EAR site 
mentioned above). In other words, incorporating Google APIs into your 
software requires that you adhere to the rules that Google must follow 
in regard to export of software from the USA - even if neither you (the 
developer) nor your user are based in the USA.

Don't forget, the same restrictions apply to GIS software from US 
vendors, such as ESRI (see 
http://www.esri.com/legal/export/export-definitions.html) and Microsoft 
- where their standard EULA states:

9.         *EXPORT RESTRICTIONS*.  You acknowledge that the Software is 
subject to U.S. export jurisdiction.  You agree to comply with all 
applicable international and national laws that apply to the Software, 
including the U.S. Export Administration Regulations, as well as 
end-user, end-use, and destination restrictions issued by U.S. and other 
governments.  For additional information see 
_<http://www.microsoft.com/exporting/>_.


This is an issue that many researchers and software developers do 
ovelook and which we touched on in "Legal Issues in the Use of 
Geospatial Data and Tools for Agriculture and Natural Resource 
Management: A Primer" (freely downloadable as PDF from 
http://csi.cgiar.org/download/IPR_Primer.pdf) developed for the global 
Consultative Group on International Agricultural Research (CGIAR) 
Consortium for Spatial Information (http://csi.cgiar.org/IPR.asp) in 
2002. Most researchers were unaware that if they incorporated software 
into their final applications that was made available to them under 
export restriction rules, then the resulting applications were 
themselves restricted under the same terms.

I guess this is something for the open source community to take up with 
Google, but the possibility of changing US foreign policy (which is what 
drives the export restrictions) seems pretty remote to me!

Open source software developers - beware!

Kind regards

Roger Longhorn
co-Chair, GSDI Association Legal & Socioeconomic Working Group


----- End forwarded message -----

-- 



More information about the Discuss mailing list