[OSGeo-Discuss] on Google Code and export restrictions

Wilfred L. Guerin wilfredguerin at gmail.com
Mon May 26 12:53:57 PDT 2008


I appologise for that fragmented message, 80% and all facts and data
references were stripped out over the 20 blocked attempts to post that
message.

I have been put on the UN ETED counter-terrorism watch list for
teaching children to find balls in a picture to use for 3d image
extrapolation and for encouraging the creation of humaitarian
automation by means of hot glue or soda bottle plastic, a camera or
cell phone, and basic automation control tools like two transistors
and a diode.

Are the western imperialists sick beyond recovery or what?

Can YOU find a ball in a picture? 3?



On 5/26/08, Wilfred L. Guerin <wilfredguerin at gmail.com> wrote:
> 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
>>
>



More information about the Discuss mailing list