Re: SPARC Author Addendum compatibility

Larry,

> It seems reasonable to make that requirement a part of the Trust bylaws or
> articles of incorporation, with a supermajority requirement to change that.
> I haven't read those documents; perhaps the public interest is already
> sufficiently protected?

The Trust is constructed to do what the IETF tells it to do, although
legally it has to abide by the Trust Agreement.

     Brian

References:

Administrative Procedures (equivalent of By-Laws)
http://trustee.ietf.org/docs/Trust_Procedures_12-15-2005.pdf

Specifically:
"10. The Trust shall be guided by IETF process documents, decisions of the IETF
leadership, and IETF consensus when licensing use of its intellectual property in
accordance with the Trust Agreement..."

Trust Agreement (searchable file)
http://www.ietf.org/trust/IETFtrustAgreement20051208.pdf

Ditto (signed and scanned)
http://iaoc.ietf.org/docs/IETF-Trust-Agreement-Executed-12-15-05.pdf

Re: SPARC Author Addendum compatibility

Joel,

On 2007-07-28 19:22, Joel M. Halpern wrote:
> Note for clarification, and a suggestion for resolution.
> 
> The below "requirement" would be a change from what the WG is 
> requesting.  However, given the rules as we are writing them, the trust 
> could make such a change.  (The fact that I, and even John I suspect, 
> consider that unlikely does not change the fact that it is legally 
> possible.)
> 
> Therefore, as I understand this particular issue, what is needed is a 
> statement in the inbound rights grant that the authors, as a condition 
> of the inbound rights grant, will be granted the outbound rights to copy 
> / extract from the RFC.  II believe the authors do not need the rights 
> to make changes to the RFC, just the rights to copy / extract.

I agree with this proposal.

> 
> Yes, that puts a tiny outbound constraint in inbound.  So be it.  The 
> actual point (and I think it is a useful result of separating teh two 
> documents) is that this constraint MUST be an inbound constraint in 
> order to meet the SPARC conditions.

True, but we don't need to cite SPARC specifically.

    Brian

> 

Re: SPARC Author Addendum compatibility

Brian - NOT meeting SPARC as its sits, and trying to reimplement it in an 
IETF Derivative Manner will mean that ANYONE who wants to rely on the IETF's 
ever changiung IP model will have to have theor lawyers make a determination 
as to whether their sponsoree's can actually participate.

What happend in the past where academic's allowed their students, employee's 
and contractors to freely use their Network's for publishing are now 
changing that tune to enforce a SPARC specificality. That means ANYTHING 
that is not SPARC exactly must be reviewed by their counsel's every time 
there is a change in the underlying particpation agreement.

Is that what you are trying to do?

Todd
----- Original Message ----- 
From: "Brian E Carpenter" <brian.e.carpenter <at> gmail.com>
To: "Joel M. Halpern" <joel <at> stevecrocker.com>
Cc: <ipr-wg <at> ietf.org>
Sent: Thursday, August 02, 2007 4:38 AM
Subject: Re: SPARC Author Addendum compatibility

> Joel,
>
> On 2007-07-28 19:22, Joel M. Halpern wrote:
>> Note for clarification, and a suggestion for resolution.
>>
>> The below "requirement" would be a change from what the WG is requesting. 
>> However, given the rules as we are writing them, the trust could make 
>> such a change.  (The fact that I, and even John I suspect, consider that 
>> unlikely does not change the fact that it is legally possible.)

sometimes hiding things from a standards body hurts

from today's WSJ on-line

Judge Rules Against Qualcomm
In Patent Fight With Broadcom
By KEVIN KINGSBURY
August 7, 2007 8:37 a.m.

A federal judge ruled that two Qualcomm Inc. patents related to video
transmission technology can't be enforced because the company
deliberately concealed the patents from a standards-setting group.

The judge, which charged Qualcomm engaged in "aggravated litigation
abuse," ruled Monday that Qualcomm waived its rights to enforce the
patents, related to the H.264 video compression standard used in some
high definition products, because of its conduct. 

The court also decided Qualcomm committed misconduct by failing to
produce thousands of documents related to the case until after the
January trial concluded. In addition, the firm was ordered to pay the
legal fees of Broadcom Corp., which was the defendant in the case.

Qualcomm sued in October 2005, alleging its rival violated video
transmission patents. A jury found Broadcom didn't violate the patents
and that Qualcomm misled the standard setting body, called the Joint
Video Team.

...

copyright boilerplate for independent submissions

When attempting to submit several non-WG I-Ds recently, I discovered
that xml2rfc produces copyright boilerplate that the Secretariat finds
unacceptable. The offending text seems to be:

"and at http://www.rfc-editor.org/copyright.html"

Bill Fenner suggests [1] that this construct was "accidentally outlawed"
when RFC 3978 was published, and that fixing the problem is presumably a
work item of the IPR WG. Is this indeed an active work item? (The
xml2rfc workaround -- removing submissionType='independent' in the XML
source -- seems to defeat the purpose of flagging the submission type.)

Thanks!

Peter

[1]
http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2007-August/003155.html

_______________________________________________
Ipr-wg mailing list
Ipr-wg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg

Re: copyright boilerplate for independent submissions

Making it possible to fix the boilerplate requirements without issuing a 
new RFC is indeed part of what we hope to achieve with the documents now 
in front of this WG. I hope our currently proposed text achieves that.
We're not trying to fix any specific problem with the existing procedure.

                   Harald

Peter Saint-Andre wrote:
> When attempting to submit several non-WG I-Ds recently, I discovered
> that xml2rfc produces copyright boilerplate that the Secretariat finds
> unacceptable. The offending text seems to be:
>
> "and at http://www.rfc-editor.org/copyright.html"
>
> Bill Fenner suggests [1] that this construct was "accidentally outlawed"
> when RFC 3978 was published, and that fixing the problem is presumably a
> work item of the IPR WG. Is this indeed an active work item? (The
> xml2rfc workaround -- removing submissionType='independent' in the XML
> source -- seems to defeat the purpose of flagging the submission type.)
>
> Thanks!
>
> Peter
>
> [1]
> http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/2007-August/003155.html
>
>
>   
> ------------------------------------------------------------------------

Re: copyright boilerplate for independent submissions

The problem there is that the Boiler Plate on previously issued documents is 
what is in force regarding their licensing, use and control, so when the 
plating is changed, it would be of value to reissue those flawed RFC's with 
the same RFC Numbers and updated boilerplate. Otherwise, it makes the 
process of separating rights/process vs. content a pain in the lower 
backside.

T.
----- Original Message ----- 
From: "Harald Alvestrand" <harald <at> alvestrand.no>
To: "Peter Saint-Andre" <stpeter <at> jabber.org>
Cc: <ipr-wg <at> ietf.org>
Sent: Thursday, August 09, 2007 11:27 AM
Subject: Re: copyright boilerplate for independent submissions

> Making it possible to fix the boilerplate requirements without issuing a 
> new RFC is indeed part of what we hope to achieve with the documents now 
> in front of this WG. I hope our currently proposed text achieves that.
> We're not trying to fix any specific problem with the existing procedure.
>
>                   Harald
>
> Peter Saint-Andre wrote:
>> When attempting to submit several non-WG I-Ds recently, I discovered
>> that xml2rfc produces copyright boilerplate that the Secretariat finds
>> unacceptable. The offending text seems to be:
>>
>> "and at http://www.rfc-editor.org/copyright.html"
>>
>> Bill Fenner suggests [1] that this construct was "accidentally outlawed"

Re: copyright boilerplate for independent submissions

On 2007-08-09 20:27, Harald Alvestrand wrote:
> Making it possible to fix the boilerplate requirements without issuing a 
> new RFC is indeed part of what we hope to achieve with the documents now 
> in front of this WG. I hope our currently proposed text achieves that.
> We're not trying to fix any specific problem with the existing procedure.

I agree with that, but...

> 
>                   Harald
> 
> Peter Saint-Andre wrote:
>> When attempting to submit several non-WG I-Ds recently, I discovered
>> that xml2rfc produces copyright boilerplate that the Secretariat finds
>> unacceptable. The offending text seems to be:
>>
>> "and at http://www.rfc-editor.org/copyright.html"
>>
>> Bill Fenner suggests [1] that this construct was "accidentally outlawed"
>> when RFC 3978 was published, 

I'm not sure it was an accident. I suspect there was concern
about creating legal ambiguity by citing two different sets of rules
without stating which one takes precedence in case of conflict.
When the Trust composes the future boilerplate, they'll need
to consider this.

     Brian

>> and that fixing the problem is presumably a

Re: SPARC Author Addendum compatibility

Counsel -
I think the problem is not the copyright on the derivative document - that 
clearly the trust would own, its the use of the core IP for any and all 
purposes that is the problem, especially when we leverage one design on 
designs or components issued under previous or external IP controls.

T.
----- Original Message ----- 
From: "Lawrence Rosen" <lrosen <at> rosenlaw.com>
To: <ipr-wg <at> ietf.org>
Sent: Saturday, July 28, 2007 11:09 AM
Subject: RE: SPARC Author Addendum compatibility

John Klensin and Simon Joseffson wrote:
> Because "the IETF Trust is the sole owner of the copyright in a
> complete RFC" is a major step --both from the original principle
> and from where I believe we stand today-- I don't want to see it
> slip through without community discussion.  That does not
> indicate that I think it is a bad idea because I don't; I just
> believe that we need to identify consequences we might not like
> and deal with them.
>
> > I have interpreted "author retains all rights" to mean that
> > the author retains the copyright of the material she
> > contributed.  The author is never given rights to other
> > material that the author did not contribute, at least not as
> > far as I can see in RFC 3978.
>
> Clearly you are not the only one who interpreted things that
> way.  It is not the original interpretation.  And, as you can

Re: SPARC Author Addendum compatibility

----- Original Message ----- 
From: "John C Klensin" <john-ietf <at> jck.com>
To: <lrosen <at> rosenlaw.com>; <ipr-wg <at> ietf.org>
Sent: Saturday, July 28, 2007 2:26 PM
Subject: RE: SPARC Author Addendum compatibility

>
>
> --On Saturday, 28 July, 2007 13:49 -0700 Lawrence Rosen
> <lrosen <at> rosenlaw.com> wrote:
>
>> John Klensin wrote:
>>> If we are to adopt this revised model at all (and I will leave
>>> that to others to debate), then what I'm looking for is a
>>> requirement (not a request to the Trust that they can ignore
>>> or a statement from the IETF that can be changed) that leaves
>>> the original authors with substantially the same rights in the
>>> output of the editing process that they have been assumed to
>>> have for years.
>>
>> And leaves *everyone* with substantially those same rights....
>> With that important change, I agree with you.
>>
>> It seems reasonable to make that requirement a part of the
>> Trust bylaws or articles of incorporation, with a
>> supermajority requirement to change that. I haven't read those
>> documents; perhaps the public interest is already sufficiently
>> protected?
>