[OSGeo-Discuss] on Google Code and export restrictions

[Wilfred L. Guerin]

This pda was spiked 3 times now in an attempt to block this message.
The sections triggering the attacks, namely specific policies and
example conditions, have been sticken to at least get this out.....


Google earth is CIA keyhole.

DHS has stolen toy balls from children on a pretense of national security.

DieBold.
--

According to UN, you are bound to the laws of the country in which you
are registered as human. There are very few individuals ithout a UN
country, and it is close to impossible to declare an identity which is
not based within the UN / white crown policy.

The primary problem, is that, as most things are forced through an
american portal or front (such as sf or google, all american
imperialist companies) and as the infrastructure is controlled by the
americans, you have few outlets.

By the laws binding microsoft, any work created within that
environment is required to adopt the laws of the host environment.

Knoppix still follows EU/DE policy, though you are likely not in the
german military intel division which is the recognised flag sponsor.

The situation is quite grim; if any party contributor (including by
maillist) is american, you are screwed.

I, for example, am granted export exemptions by us on childrens' toys
used for remote imaging, however, I can not hand anyone code that
works nor provide direct guidance. They now attack this device to
hinder this message creation. I can teach children to empower
themselves, however the racket of crimes against humanity by the
american imperialists makes it impossible to automate the task without
dependent technologies.

I can not encourage, as per the threats of the americans, any american
party to take pictures of archeological or historical locations
because such, they claim, would be a critical threat to national
security and a making available of weapons technology of hostile
intent. Yes, taking or sharing pictures of indiginous artworks with
any type of correlation or image processing, is supposedly a threat to
american national security.

US coast guard and various others have even tried to take plastic
balls, used as a color and physical reference, from the cildren under
guise of american national security.

DieBold.



On 5/26/08, jo at frot.org <jo at frot.org> wrote:
> 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
>