Re: [emergency] Public as responders: Royalties

["Carl Reed" <creed@opengis.org>]

On the issue of royalties . . .  in a way this emerging discussion sounds
very similar to discussions that occurred for a period of time in the IETF
GeoPRIV Working Group. This group is concerned with privacy and location
information in the mobile world. For a period of time they gnashed their
teeth on trying to address all the possible implications of the various
privacy laws around the world and thought perhaps that they could define
some level of privacy policy. While this provided them a level of
understanding regarding requirements for privacy and location it got them no
closer to a specification solution. So they decided to step back one level
of abstraction and have now defined a draft specification for encoding
privacy rules as part of a payload (could be DHCP) in the Internet world.
What this means is that they removed themselves from the legal and policy
issues surrounding privacy and moved into an environment in which the
application worries about all of this and is responsible for defining the
privacy rules. In this way, the spec does not concern itself with a nations
or organizations specific privacy policies.

Also, in the OGC we have a similar situation. Many producers of geospatial
information require pay for use. So how can we provide seamless access in an
interoperable world of geospatial information sharing - such as in an
emergency response situation? There are definitely royalty, copyright,
legal, and payment issues. On thing we discovered is that we do not try to
solve the royalty/copyright issue at the data access interface or payload
level. This is silliness. Perhaps more importantly what we discovered is
that not only do we have technical interoperability issues but also
institutional and political interoperability issues. These two latter
interoperability issues are related to but are independent of the actual
interface specification or payload specification standard. The institutional
and political issues of data sharing need to be ironed out by the
constituents BEFORE an Emergency event occurs. In effect, the constituents
need to have some level of "contract" that enables full and complete sharing
of public, private, for fee, or free spatial data.

So, I might suggest that 1.) the CAP interface/payload specification needs
slots (MIME?) to accommodate the ability to reference something like an
MPEG-4 but 2.) the actual requirements for dealing with royalty and
copyright and for fee should be handled at the application level and is
therefore 3.) not at the CAP spec level.

Sorry for the long missive - I am usually short and blunt :-)

Carl

----- Original Message ----- 
From: "Rex Brooks" <rexb@starbourne.com>
To: "Bullard, Claude L (Len)" <clbullar@ingr.com>; "'Poindexter, Gary W
(BearingPoint)'" <gpoindexter@bearingpoint.net>;
<emergency@lists.oasis-open.org>
Sent: Thursday, October 09, 2003 9:48 AM
Subject: RE: [emergency] Public as responders (was RE: [emergency]...PPW l
etter re CAP)


> I have been so wrapped up in the Broadcast Media discussion that I
> almost missed this. I hope that this is the sort of concern we can
> take up in the public comment period after we release CAP but now it
> seems moot until that issue gets some kind of resolution since we
> might not vote to release CAP, even though we had agreed to a
> Committee Specification status back before the demonstration at the
> Global Homeland Security Conference last month.
>
> This particular concern strikes me as something that should be added
> to the list of items for consideration in v1.1 of CAP, if that is
> even the correct place for it. I am beginning to think that Broadcast
> Media ought to take compatibility with CAP as a priority
> consideration for requirement in its own standard because I don't
> think that any public service use of Broadcast Assets can be
> separated from the quagmire of patents and royalties and when you add
> liability considerations by even thinking about conferring official
> Emergency Management Asset status on members of the public it just
> grows more thorns.
>
> And, if we really need to focus on obtaining RFP-Requirement status
> in governmental solicitations dealing with life and death issues,
> then it really might be best to duck this whole area in favor of
> fielding a standard that can stand up to large liability concerns.
>
> Ciao,
> Rex
>
> At 9:04 AM -0500 10/9/03, Bullard, Claude L (Len) wrote:
> >Right.  This thread confuses me because it seems to indicate
> >that civilian responders might be providing information directly
> >to the public broadcast media and while that can happen, it is
> >not typically part of emergency response asset management although,
> >as in the case of citizens band and other weather disaster monitoring,
> >it can be part of the warning and tracking reporting to the news
> >outlets.  I'd be somewhat wary of an official sounding alert message
> >that goes directly from the public to the public through the broadcast
> >media.  That isn't what is being suggested is it?
> >
> >len
> >
> >
> >From: Poindexter, Gary W (BearingPoint)
> >
> >Identifying assets and their
> >attributes is essential. Identifying a path or multiple paths to/from an
> >asset is essential. How an asset is used in an emergency situation is not
a
> >standards issue.
> >
> >To unsubscribe from this mailing list (and be removed from the
> >roster of the OASIS TC), go to
>
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgr
oup.php.
>
>
> -- 
> Rex Brooks
> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
> W3Address: http://www.starbourne.com
> Email: rexb@starbourne.com
> Tel: 510-849-2309
> Fax: By Request
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
>