[GSDI Legal Econ] Something that the Legal & Socioeconomic Working Group should consider

Mon May 26 10:31:30 EDT 2008

Thank you, Roger, for your answer. These things annoy me particularly. I 
wish to hear more opinions from other list members.
Sergio Acosta y Lara

Roger Longhorn wrote:

> 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
>
>