RE: Spec organizations and prioritization

>The argument was that you are not protected until Recommendation and that
>therefore we need to get to Recommendation.

This keeps coming up.  It seems to me irrelevant.   Suppose a spec takes say 2 years to create (assuming it is a manageably sized project, not a massive comprehensive spec that is to do everything and takes very long).  From a practical standpoint, if someone in a WG sued someone else in a WG - it takes a while for these things to play out in courts.  What would be the point of suing someone for doing something you'd be licensing them to do by the time it actually got to court?  If this draft was getting published in the TR page, whoever was suing would have had to disclose essential claims they knew about.  So there'd be a PAG, etc.  The WG could work around it.  Not to mention that it is the common expectation that developers implement the drafts they are working on.  Someone who didn't want the draft implemented would likely need to be saying something about it rather than just hiding out, not disclosing, and then suing someone.

This whole thing about not kicking in until Recommendation seems irrelevant.  What we should be doing is figuring out how to divide up problems so specs don't take 10 years to complete.

DISCLAIMER: not a lawyer, not giving legal advice.

>-----Original Message-----
>From: Anne van Kesteren [mailto:annevk@opera.com]
>Sent: Thursday, March 22, 2012 7:14 AM
>To: Jeff Jaffe
>Cc: Marcos Caceres; Dominique Hazael-Massieux; public-w3process; Daniel
>Glazman
>Subject: Re: Spec organizations and prioritization
>
>On Thu, 22 Mar 2012 15:10:27 +0100, Jeff Jaffe <jeff@w3.org> wrote:
>> Companies in the same WG can't sue each other about RF work in that WG.
>> They do sue each other all the time for non-RF protected work.
>
>The argument was that you are not protected until Recommendation and that
>therefore we need to get to Recommendation. If we have protection solely by
>being in the same WG, that argument does not seem to hold.
>
>
>--
>Anne van Kesteren
>http://annevankesteren.nl/

Received on Friday, 23 March 2012 15:36:50 UTC