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

Mon May 26 11:10:02 EDT 2008

Hello,
It seems to me that Roger has laid out a helpful analysis and some  
options for the short-term issues. Given the difficulties of changing  
foreign policies, I think we should underscore that open-source  
developers need to take heed of US export restrictions they may become  
subject to and look for alternative distribution channels and software  
packages.

This is an important issue and far more then a dot on an "i" as it  
could come to impact many users of open-source.

Francis Harvey

On 26 May 2008, at 09:31, Sergio Acosta y Lara wrote:

> 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
>>
>>
>
>
> _______________________________________________
> Legal-Econ mailing list
> Legal-Econ at lists.gsdi.org
> http://lists.gsdi.org/mailman/listinfo/legal-econ