[OSGeo-Discuss] on Google Code and export restrictions

Mon May 26 09:06:55 PDT 2008

Hi Jo,

the issue has been eagerly discussed in gvSIG and OSGeo Spanish mailing lists. The matter arised as no alternate download site was available for stable versions of Sextante project.

I think that googlecode.com is subject to certain regulations, as many other similar sites, and they cannot get round them.

There have been some way to go round similar problems, as sb. told in gvSIG user list [1] for Debian case.

IMO, the point is not to set-up alternative sites, but to promote the use of fully accesible sites, with no restrictions depending on where you live.

The shock around the issue with the Cuban guy, was that nobody in Sextante, nor gvSIG project had realized that the restriction was in force (yes, for sure nobody fully read the legal bla bla). I think that maybe there are many other similar cases.

So my suggestion is to check the universal availability of Free and Open Source Code promoted by OSGeo. Maybe another check in the incubation checklist?

I know this is a thorny question, that maybe does not affect almost all of this list's subscribers, but we must avoid unfairness, regardless of where we live.

Regards,

[1] http://www.debian.org/mirror/list-non-US 

Miguel Montesinos

________________________________

De: discuss-bounces at lists.osgeo.org en nombre de jo at frot.org
Enviado el: lun 26/05/2008 15:11
Para: discuss at lists.osgeo.org
Asunto: [OSGeo-Discuss] on Google Code and export restrictions

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

--
_______________________________________________
Discuss mailing list
Discuss at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 11491 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20080526/f7a4e427/attachment-0002.bin>