Message from discussion
IPR Draft Guidelines
Received: by 10.214.46.9 with SMTP id t9mr160091qat.28.1217553276144;
Thu, 31 Jul 2008 18:14:36 -0700 (PDT)
Return-Path: <e...@hueniverse.com>
Received: from outbound.mse20.exchange.ms (outbound.mse20.exchange.ms [64.71.238.249])
by mx.google.com with ESMTP id 7si24619086yxg.1.2008.07.31.18.14.35;
Thu, 31 Jul 2008 18:14:36 -0700 (PDT)
Received-SPF: neutral (google.com: 64.71.238.249 is neither permitted nor denied by best guess record for domain of e...@hueniverse.com) client-ip=64.71.238.249;
Authentication-Results: mx.google.com; spf=neutral (google.com: 64.71.238.249 is neither permitted nor denied by best guess record for domain of e...@hueniverse.com) smtp.mail=e...@hueniverse.com
Received: from mse20be3.MSE20.exchange.ms ([172.28.1.16]) by
mse20fe2.MSE20.exchange.ms ([172.29.12.84]) with mapi; Thu, 31 Jul 2008
21:14:35 -0400
From: Eran Hammer-Lahav <e...@hueniverse.com>
To: "open-web-discuss@googlegroups.com" <open-web-discuss@googlegroups.com>
Date: Thu, 31 Jul 2008 21:14:33 -0400
Subject: Re: IPR Draft Guidelines
Thread-Topic: IPR Draft Guidelines
Thread-Index: Acjzci6vqmIsOZ+ZThOEb7iuuekL+QAAcXiT
Message-ID: <C4B7B189.584F%eran@hueniverse.com>
In-Reply-To: <489205AC.4090800@jkemp.net>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="_000_C4B7B189584Feranhueniversecom_"
--_000_C4B7B189584Feranhueniversecom_
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
I think there are two issues here. One is how to keep the foundation itself=
consistent with the ideals the founders had in mind. The other is how to k=
eep individual projects free of people who try to change the nature of the =
community that is working on a particular spec. I think the bylaws and clos=
ed membership will keep the foundation consistent. It works well for the AS=
F which is the model we are building on. As for the spec, I think it is rea=
lly up to the personalities involved and the communities will need to self =
regulate. The OAuth leads had an idea and we made sure the community didn't=
change.
EHL
On 7/31/08 11:34 AM, "John Kemp" <j...@jkemp.net> wrote:
Hi Eran,
Eran Hammer-Lahav wrote:
> In the past 2 years (don't care about earlier statistics), what do
> these numbers look like and what is the average time from suggesting
> a spec to final?
>
> Speaking only for myself, I never claimed other bodies are broken or
> don't work. I just don't think they works for me. They don't create
> the kind of community I want to be part of.
I drew the conclusion that the kind of community I want to be part of is
one where I feel (both myself, and on behalf of my company) I am in a
position to create something useful within a group of other like-minded
individuals. That has so far depended on a) a reasonable and written IPR
commitment from participants (and their companies) and b) the intent and
actions of others (a very vague concept not usually written down
anywhere!) to also create something interesting.
W3C (and others) have attempted to legislate the former, often with
apparent success (in that some members create and implement a
specification). However, there's still the b) part, which is (I think)
harder to legislate than the written legal language governing IPR as it
has largely to do with things like corporate politics and interpersonal
relationships.
I agree with you that standards bodies don't always create "the kind of
community I want to be part of", but if a standards body is successful
at achieving anything, it's a fair bet that at some point, some people
who join will have different motives than you or I for participating.
How will we get OWF to deal with this any better than others have been
able to do?
Regards,
- johnk
>
> EHL
>
> -----Original Message----- From: open-web-discuss@googlegroups.com
> [mailto:open-web-discuss@googlegroups.com] On Behalf Of Daniel
> Weitzner Sent: Thursday, July 31, 2008 10:42 AM To:
> open-web-discuss@googlegroups.com Subject: Re: IPR Draft Guidelines
>
>
>
> On Jul 31, 2008, at 1:16 PM, Ben Laurie wrote:
>
>> On Thu, Jul 31, 2008 at 3:50 AM, Daniel Weitzner
>> <djweitz...@gmail.com> wrote:
>>> Eran,
>>>
>>> One question and one comment...
>>>
>>> On Jul 30, 2008, at 8:50 PM, Eran Hammer-Lahav wrote:
>>>
>>>> This is a very good point.
>>>>
>>>> Before any company is going to sign a license or non-assert
>>>> they are going to review the exact scope and details of what
>>>> they are signing. That means you need to have a stable
>>>> document. For companies to do that early, you need a very well
>>>> defined scope that they can be comfortable with, which really
>>>> means you are writing the spec before you write the spec... :-)
>>>>
>>> I understand this in theory but not in practice. At least two of
>>> the more formal standard groups (W3C and OASIS) are able to get
>>> licensing commitments from participants based on a combination of
>>> a a charter (which is usually just a page or so) and an early
>>> draft of a spec. Is there are reason that OWF would need to give
>>> patent holders more leeway?
>> I don't know how W3C works in practice, but I've heard that OASIS
>> specs tend to be mostly done before they start the OASIS process.
>> Am I mistaken?
>
> I can't speak to OASIS, but W3C is a pretty even mix across the
> spectrum from starting with a charter and a blank page, to small
> fixes on a complete spec.
>
> For reference as of today, the W3C patent policy has produced:
>
> * 198 specifications, including 26 W3C Recommendations * produced by
> 48 W3C Working Groups operating under the W3C Patent Policy * 636
> licensing commitments made by 222 different W3C Members
>
> This is with a model the depends on a charter and first/second draft
> specs defining the scope of the RF license commitment.
>
>
>>
>>>> I would expect specs that take years to develop to publish
>>>> stable drafts along the way and get them IPR clearance. So you
>>>> can think about that as treating a draft as final for a short
>>>> period of time. That is, the license/non-assert is only good
>>>> for the duration in which the spec is valid (for example, IETF
>>>> expires draft after a fixed number of days).
>>> Can you explain this further? Does this mean that you think there
>>> will be lots of incrementally changing drafts each of which will
>>> have a non- assert from all participants?
>>>
>>> thanks,
>>>
>>> Danny
>>>
>>>>
>>>> The problem with asking for early non-asserts is that it takes
>>>> away from the value of the patent. When you go to court to
>>>> enforce your patent, the court looks at previous licenses you
>>>> granted when considering how to move forward. This means that
>>>> giving temporary licenses can take away from the value of the
>>>> patent even after the license expires.
>>>>
>>>>
>>>> We are starting from the end, making sure that final specs are
>>>> free to implement for ever. Protecting early adopters is an
>>>> issue we currently don't have good ideas on how to protect.
>>>> However, the reality is, this isn't really any bigger risk than
>>>> being sued by any other third party.
>>>>
>>>> EHL
>>>>
>>>>
>>>> On 7/30/08 2:38 PM, "Daniel Weitzner" <djweitz...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> Nice document. I'd like to offer one suggestion. Reconsider the
>>>> timing of the final patent non-assert/license commitment --
>>>> seek an earlier patent commitment for participants.
>>>>
>>>> As described here[1], participants make an initial 'intent to
>>>> sign a non-assert' and then have to sign the actual non-assert
>>>> when the spec is finished. While I am certainly aware that this
>>>> will provide greater certainty for patent holders, it puts the
>>>> developer community under significant pressure due to
>>>> uncertainty and seems out of sync with the stated preference to
>>>> resolve such tensions in favor of the community[2]. As a user
>>>> and implementer of OpenID, for example, I can say that early
>>>> uncertainty about licensing there was a real disincentive to
>>>> early use in my work. I see OWF as an effort to minimize this
>>>> uncertainty and suggest pushing as far as possible in that
>>>> direction.
>>>>
>>>> I'd suggest picking some earlier point in the process to seek
>>>> final commitments. Perhaps a set number of weeks after the
>>>> group starts working, perhaps after x number of spec drafts
>>>> have been produced. Or, perhaps the group can decide for itself
>>>> the point at which the spec is baked enough to request final
>>>> patent commitments. It's also possible to set early commitment
>>>> as a goal, though not a requirements. This would be a way to
>>>> bring positive community pressure to bear on the process.
>>>>
>>>> If a group's work is reasonably well scoped out, then it should
>>>> be possible even for large patent holders to make early
>>>> commitments.In most cases, the decision to make an open, RF
>>>> licensing commitment is really much about business strategy,
>>>> than about the low-level technical and legal details of which
>>>> patent claims are included and which excluded. The commitment
>>>> to license without seeking fees or restrictive conditions is
>>>> generally based on a decision that it is in the **business
>>>> interest** of the patent holder to have an open, unencumbered
>>>> spec in the particular technical area. (There may be some
>>>> exceptions to this, but EVEN in the W3C process, characterized
>>>> by some here as being just about the big-guys. :-), this is
>>>> what we found.)
>>>>
>>>> Thanks,
>>>>
>>>> Danny
>>>>
>>>> [1] Section on non-assert timing
>>>>> The CLA includes two other provisions. First, it includes a
>>>>> declaration in which the signing entity states their
>>>>> intention to sign a non-assertion agreement (non-assert) with
>>>>> regard to patents covered by the final specification. This
>>>>> declaration means that as long as the final specification is
>>>>> within the general boundaries of the project charter, the
>>>>> entity intends to sign a non-assert on the entire
>>>>> specification. While this does not guarantee that all
>>>>> contributors will sign the required patent non-assert, it
>>>>> places community pressure to do so and raises the bar for
>>>>> entities withdrawing their contribution from the project. The
>>>>> second provision is that the entity agrees to the language of
>>>>> the non- assertion agreement which will not be open for
>>>>> negotiation at the conclusion of the project.
>>>>>
>>>>> In order to graduate from incubation (again, beside other
>>>>> non-IPR requirements), the project must obtain signed Patent
>>>>> Non-Assert (PNA) agreements from all contributors to the
>>>>> particular specification. Without going into the legal
>>>>> details of the agreement, it basically means that the
>>>>> contributors promise not to sue anyone for implementing any
>>>>> part of the specification. If the project is unable to obtain
>>>>> such signature from a contributor, the project's community
>>>>> must resolve it by excluding any such contribution from the
>>>>> specification and obtaining signatures again for the modified
>>>>> specification. To graduate, the project's community must
>>>>> obtain such signatures from all contributors and it is up to
>>>>> the community as to how to reach that position. The
>>>>> incubation process might include provisions for handling such
>>>>> situations but the IPR process simply requires full coverage
>>>>> of all listed contributors. Projects are free to negotiate
>>>>> specification changes, remove contributions altogether, or
>>>>> engage in other means to reach the finish line with all
>>>>> contributions non-asserted.
>>>>
>>>> On Jul 28, 2008, at 10:51 PM, Eran Hammer-Lahav wrote:
>>>>
>>>> [..] [2] Section on balancing needs of community and patent
>>>> holders [from earlier in the document]
>>>>
>>>>> The process is an attempt to find the right balance between
>>>>> two conflicting needs: enable the community to participate
>>>>> freely and develop specifications organically vs. ensuring
>>>>> that the specifications emerging out of these communities are
>>>>> freely implementable from an IPR perspective. When such a
>>>>> balance is not attainable, the process goes in favor of the
>>>>> community,
>>>> [..]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>
>
>
> >
--_000_C4B7B189584Feranhueniversecom_
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<HTML>
<HEAD>
<TITLE>Re: IPR Draft Guidelines</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>I think there are two issues here. One is how to keep the foundation =
itself consistent with the ideals the founders had in mind. The other is ho=
w to keep individual projects free of people who try to change the nature o=
f the community that is working on a particular spec. I think the bylaws an=
d closed membership will keep the foundation consistent. It works well for =
the ASF which is the model we are building on. As for the spec, I think it =
is really up to the personalities involved and the communities will need to=
self regulate. The OAuth leads had an idea and we made sure the community =
didn’t change.<BR>
<BR>
EHL<BR>
<BR>
<BR>
On 7/31/08 11:34 AM, "John Kemp" <<a href=3D"j...@jkemp.net">j=
o...@jkemp.net</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
Hi Eran,<BR>
<BR>
Eran Hammer-Lahav wrote:<BR>
> In the past 2 years (don't care about earlier statistics), what do<BR>
> these numbers look like and what is the average time from suggesting<B=
R>
> a spec to final?<BR>
><BR>
> Speaking only for myself, I never claimed other bodies are broken or<B=
R>
> don't work. I just don't think they works for me. They don't create<BR=
>
> the kind of community I want to be part of.<BR>
<BR>
I drew the conclusion that the kind of community I want to be part of is<BR=
>
one where I feel (both myself, and on behalf of my company) I am in a<BR>
position to create something useful within a group of other like-minded<BR>
individuals. That has so far depended on a) a reasonable and written IPR<BR=
>
commitment from participants (and their companies) and b) the intent and<BR=
>
actions of others (a very vague concept not usually written down<BR>
anywhere!) to also create something interesting.<BR>
<BR>
W3C (and others) have attempted to legislate the former, often with<BR>
apparent success (in that some members create and implement a<BR>
specification). However, there's still the b) part, which is (I think)<BR>
harder to legislate than the written legal language governing IPR as it<BR>
has largely to do with things like corporate politics and interpersonal<BR>
relationships.<BR>
<BR>
I agree with you that standards bodies don't always create "the kind o=
f<BR>
community I want to be part of", but if a standards body is successful=
<BR>
at achieving anything, it's a fair bet that at some point, some people<BR>
who join will have different motives than you or I for participating.<BR>
<BR>
How will we get OWF to deal with this any better than others have been<BR>
able to do?<BR>
<BR>
Regards,<BR>
<BR>
- johnk<BR>
<BR>
><BR>
> EHL<BR>
><BR>
> -----Original Message----- From: <a href=3D"open-web-discuss@googlegro=
ups.com">open-web-discuss@googlegroups.com</a><BR>
> [<a href=3D"mailto:open-web-discuss@googlegroups.com">mailto:open-web-=
discuss@googlegroups.com</a>] On Behalf Of Daniel<BR>
> Weitzner Sent: Thursday, July 31, 2008 10:42 AM To:<BR>
> <a href=3D"open-web-discuss@googlegroups.com">open-web-discuss@googleg=
roups.com</a> Subject: Re: IPR Draft Guidelines<BR>
><BR>
><BR>
><BR>
> On Jul 31, 2008, at 1:16 PM, Ben Laurie wrote:<BR>
><BR>
>> On Thu, Jul 31, 2008 at 3:50 AM, Daniel Weitzner<BR>
>> <<a href=3D"djweitz...@gmail.com">djweitz...@gmail.com</a>> =
wrote:<BR>
>>> Eran,<BR>
>>><BR>
>>> One question and one comment...<BR>
>>><BR>
>>> On Jul 30, 2008, at 8:50 PM, Eran Hammer-Lahav wrote:<BR>
>>><BR>
>>>> This is a very good point.<BR>
>>>><BR>
>>>> Before any company is going to sign a license or non-asser=
t<BR>
>>>> they are going to review the exact scope and details of wh=
at<BR>
>>>> they are signing. That means you need to have a stable<BR>
>>>> document. For companies to do that early, you need a very =
well<BR>
>>>> defined scope that they can be comfortable with, which rea=
lly<BR>
>>>> means you are writing the spec before you write the spec..=
. :-)<BR>
>>>><BR>
>>> I understand this in theory but not in practice. At least two =
of<BR>
>>> the more formal standard groups (W3C and OASIS) are able to ge=
t<BR>
>>> licensing commitments from participants based on a combination=
of<BR>
>>> a a charter (which is usually just a page or so) and an early<=
BR>
>>> draft of a spec. Is there are reason that OWF would need to gi=
ve<BR>
>>> patent holders more leeway?<BR>
>> I don't know how W3C works in practice, but I've heard that OASIS<=
BR>
>> specs tend to be mostly done before they start the OASIS process.<=
BR>
>> Am I mistaken?<BR>
><BR>
> I can't speak to OASIS, but W3C is a pretty even mix across the<BR>
> spectrum from starting with a charter and a blank page, to small<BR>
> fixes on a complete spec.<BR>
><BR>
> For reference as of today, the W3C patent policy has produced:<BR>
><BR>
> * 198 specifications, including 26 W3C Recommendations * produced by<B=
R>
> 48 W3C Working Groups operating under the W3C Patent Policy * 636<BR>
> licensing commitments made by 222 different W3C Members<BR>
><BR>
> This is with a model the depends on a charter and first/second draft<B=
R>
> specs defining the scope of the RF license commitment.<BR>
><BR>
><BR>
>><BR>
>>>> I would expect specs that take years to develop to publish=
<BR>
>>>> stable drafts along the way and get them IPR clearance. So=
you<BR>
>>>> can think about that as treating a draft as final for a sh=
ort<BR>
>>>> period of time. That is, the license/non-assert is only go=
od<BR>
>>>> for the duration in which the spec is valid (for example, =
IETF<BR>
>>>> expires draft after a fixed number of days).<BR>
>>> Can you explain this further? Does this mean that you think th=
ere<BR>
>>> will be lots of incrementally changing drafts each of wh=
ich will<BR>
>>> have a non- assert from all participants?<BR>
>>><BR>
>>> thanks,<BR>
>>><BR>
>>> Danny<BR>
>>><BR>
>>>><BR>
>>>> The problem with asking for early non-asserts is that it t=
akes<BR>
>>>> away from the value of the patent. When you go to court to=
<BR>
>>>> enforce your patent, the court looks at previous licenses =
you<BR>
>>>> granted when considering how to move forward. This means t=
hat<BR>
>>>> giving temporary licenses can take away from the value of =
the<BR>
>>>> patent even after the license expires.<BR>
>>>><BR>
>>>><BR>
>>>> We are starting from the end, making sure that final specs=
are<BR>
>>>> free to implement for ever. Protecting early adopters is a=
n<BR>
>>>> issue we currently don't have good ideas on how to protect=
.<BR>
>>>> However, the reality is, this isn't really any bigger risk=
than<BR>
>>>> being sued by any other third party.<BR>
>>>><BR>
>>>> EHL<BR>
>>>><BR>
>>>><BR>
>>>> On 7/30/08 2:38 PM, "Daniel Weitzner" <<a hre=
f=3D"djweitz...@gmail.com">djweitz...@gmail.com</a>><BR>
>>>> wrote:<BR>
>>>><BR>
>>>><BR>
>>>><BR>
>>>> Nice document. I'd like to offer one suggestion. Reconside=
r the<BR>
>>>> timing of the final patent non-assert/license commit=
ment --<BR>
>>>> seek an earlier patent commitment for participants.<BR>
>>>><BR>
>>>> As described here[1], participants make an initial 'intent=
to<BR>
>>>> sign a non-assert' and then have to sign the actual non-as=
sert<BR>
>>>> when the spec is finished. While I am certainly aware that=
this<BR>
>>>> will provide greater certainty for patent holders, it puts=
the<BR>
>>>> developer community under significant pressure due to<BR>
>>>> uncertainty and seems out of sync with the stated preferen=
ce to<BR>
>>>> resolve such tensions in favor of the community[2]. As a u=
ser<BR>
>>>> and implementer of OpenID, for example, I can say that ear=
ly<BR>
>>>> uncertainty about licensing there was a real disincentive =
to<BR>
>>>> early use in my work. I see OWF as an effort to mini=
mize this<BR>
>>>> uncertainty and suggest pushing as far as possible in that=
<BR>
>>>> direction.<BR>
>>>><BR>
>>>> I'd suggest picking some earlier point in the process to s=
eek<BR>
>>>> final commitments. Perhaps a set number of weeks after the=
<BR>
>>>> group starts working, perhaps after x number of spec draft=
s<BR>
>>>> have been produced. Or, perhaps the group can decide for i=
tself<BR>
>>>> the point at which the spec is baked enough to request fin=
al<BR>
>>>> patent commitments. It's also possible to set early commit=
ment<BR>
>>>> as a goal, though not a requirements. This would be a way =
to<BR>
>>>> bring positive community pressure to bear on the process.<=
BR>
>>>><BR>
>>>> If a group's work is reasonably well scoped out, then it s=
hould<BR>
>>>> be possible even for large patent holders to make early<BR=
>
>>>> commitments.In most cases, the decision to make an open, R=
F<BR>
>>>> licensing commitment is really much about business strateg=
y,<BR>
>>>> than about the low-level technical and legal details of wh=
ich<BR>
>>>> patent claims are included and which excluded. The commitm=
ent<BR>
>>>> to license without seeking fees or restrictive conditions =
is<BR>
>>>> generally based on a decision that it is in the **business=
<BR>
>>>> interest** of the patent holder to have an open, unencumbe=
red<BR>
>>>> spec in the particular technical area. (There may be some<=
BR>
>>>> exceptions to this, but EVEN in the W3C process, character=
ized<BR>
>>>> by some here as being just about the big-guys. :-), this i=
s<BR>
>>>> what we found.)<BR>
>>>><BR>
>>>> Thanks,<BR>
>>>><BR>
>>>> Danny<BR>
>>>><BR>
>>>> [1] Section on non-assert timing<BR>
>>>>> The CLA includes two other provisions. First, it inclu=
des a<BR>
>>>>> declaration in which the signing entity states their<B=
R>
>>>>> intention to sign a non-assertion agreement (non-asser=
t) with<BR>
>>>>> regard to patents covered by the final specification. =
This<BR>
>>>>> declaration means that as long as the final specificat=
ion is<BR>
>>>>> within the general boundaries of the project charter, =
the<BR>
>>>>> entity intends to sign a non-assert on the entire<BR>
>>>>> specification. While this does not guarantee that all<=
BR>
>>>>> contributors will sign the required patent non-assert,=
it<BR>
>>>>> places community pressure to do so and raises the bar =
for<BR>
>>>>> entities withdrawing their contribution from the proje=
ct. The<BR>
>>>>> second provision is that the entity agrees to the lang=
uage of<BR>
>>>>> the non- assertion agreement which will not be open fo=
r<BR>
>>>>> negotiation at the conclusion of the project.<BR>
>>>>><BR>
>>>>> In order to graduate from incubation (again, beside ot=
her<BR>
>>>>> non-IPR requirements), the project must obtain signed =
Patent<BR>
>>>>> Non-Assert (PNA) agreements from all contributors to t=
he<BR>
>>>>> particular specification. Without going into the legal=
<BR>
>>>>> details of the agreement, it basically means that the<=
BR>
>>>>> contributors promise not to sue anyone for implementin=
g any<BR>
>>>>> part of the specification. If the project is unable to=
obtain<BR>
>>>>> such signature from a contributor, the project's commu=
nity<BR>
>>>>> must resolve it by excluding any such contribution fro=
m the<BR>
>>>>> specification and obtaining signatures again for the m=
odified<BR>
>>>>> specification. To graduate, the project's community mu=
st<BR>
>>>>> obtain such signatures from all contributors and it is=
up to<BR>
>>>>> the community as to how to reach that position. The<BR=
>
>>>>> incubation process might include provisions for handli=
ng such<BR>
>>>>> situations but the IPR process simply requires full co=
verage<BR>
>>>>> of all listed contributors. Projects are free to negot=
iate<BR>
>>>>> specification changes, remove contributions altogether=
, or<BR>
>>>>> engage in other means to reach the finish line with al=
l<BR>
>>>>> contributions non-asserted.<BR>
>>>><BR>
>>>> On Jul 28, 2008, at 10:51 PM, Eran Hammer-Lahav wrote:<BR>
>>>><BR>
>>>> [..] [2] Section on balancing needs of community and paten=
t<BR>
>>>> holders [from earlier in the document]<BR>
>>>><BR>
>>>>> The process is an attempt to find the right balance be=
tween<BR>
>>>>> two conflicting needs: enable the community to partici=
pate<BR>
>>>>> freely and develop specifications organically vs. ensu=
ring<BR>
>>>>> that the specifications emerging out of these communit=
ies are<BR>
>>>>> freely implementable from an IPR perspective. When suc=
h a<BR>
>>>>> balance is not attainable, the process goes in favor o=
f the<BR>
>>>>> community,<BR>
>>>> [..]<BR>
>>>><BR>
>>>><BR>
>>>><BR>
>>>><BR>
>>>><BR>
>>>><BR>
>>>><BR>
>>><BR>
><BR>
><BR>
><BR>
><BR>
> ><BR>
<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>
--_000_C4B7B189584Feranhueniversecom_--
|
