gmane.ietf.ipr

ETSI patent licence rules

Brian E Carpenter — 2012-02-08T23:23:48

If this list is still active, people might be interested:

http://www.bbc.co.uk/news/technology-16948544

Regards
   Brian Carpenter

draft-polk-ipr-disclosure-00.txt

Thomas Narten — 2011-08-30T12:28:06

Not sure where to discuss this, so I'll try the old ipr-wg mailing
list.

I read through this document and it strikes me as not benig quite sure
what it wants to do. On the one hand, their seems to be an
undercurrent of IETF participants not really living up to their
obligations wrt IPR, which is bad. Specifically, they don't make
disclosures when they should, and something should be done about that.

On the other hand, the document appears loath to actually change
the behavior of WGs or individuals. So it makes some possible
suggestions, but they come across as weak and have no real push
behind them. My guess would be that the document as it is written now
would have little impact on anyone's behavior.

IMO, the IETF suffers a bit from a "don't ask don't tell" mentality
when it comes to IETF disclosures. We have a policy (and procedure),
but the process is not always adhered to rigourously, and folk seem
afraid to actually do much about it. That means there is widely
varying behavior amongst different individuals, even if the majority
of participants do the right thing.

IMO, what might help is bringing more uniformity to the actual
operational processes when it comes to IPR.

For example, if WGs aren't always informed about IPR when they should,
why not make it a SHOULD that WG chairs explicitely ask all the
authors for confirmation that they understand their IPR obligations
and have done so, as per the boilerplate in the IDs themselves. This
can be done the first time a -00 is presented to a WG, again when the
WG formally adopts a document, etc.

This doesn't have to be an onerous process. But having a record
of the author being asked, and responding in the archive (e.g. mailing
list), would make it much much harder for someone to make a late
disclosure and claim they didn't know the rules.

Either we need to do something like the above, or we don't. We should
probably decide. :-) Whether an ID (presumably a BCP) is needed
depends on how the community feels about this question.

Thomas

Minor bug in IPR submission template

Donald Eastlake — 2011-05-06T02:17:59

Hi,

I have a filed accepted provisional patent application(s) that bears
on an IETF draft. RFC 3979 says
"The disclosure must list the numbers of any issued patents or
   published patent applications or indicate that the claim is based on
   unpublished patent applications."

That's fine, because provisional patent applications are not
published. But the IPR submission template only provides for "an
unpublished pending patent application". There is no sense that I
understand in which my provisional patent filing(s) are "pending".
They are fully accepted and there is no further action the US Patent
office is going to take on it/them.

The word "pending" should be stricken from the template. Having no
idea how long this will take to fix, I will probably go ahead and file
adding a Note explaining what is going on and pointing out this error
in the form.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3< at >gmail.com

test, please ignore

Stephan Wenger — 2011-04-13T19:57:49

Testing


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

Inclusion of code with its own copyright in IETF documents

Russ Housley — 2010-05-10T14:33:20

RFC 5378 says:

   It is also important to note that additional copyright notices are
   not permitted in IETF Documents except in the case where such
   document is the product of a joint development effort between the
   IETF and another standards development organization or is a
   republication of the work of another standards development
   organization.

This has prevented the authors of two different documents from including
the code that they wanted in their document.

Here is the header that was part of the code that the authors wanted to
include:

/*
 * This is a copy of getopt provided for those systems that do not
 * have it. The name was changed to xgetopt to not conflict on those
 * systems that do have it. Similarly, optarg, optind and opterr
 * were renamed to xoptarg, xoptind and xopterr.
 *
 * Copyright 1990, 1991, 1992 by the Massachusetts Institute of
 * Technology and UniSoft Group Limited.
 *
 * Permission to use, copy, modify, distribute, and sell this software
 * and its documentation for any purpose is hereby granted without fee,
 * provided that the above copyright notice appear in all copies and
 * that both that copyright notice and this permission notice appear in
 * supporting documentation, and that the names of MIT and UniSoft not
 * be used in advertising or publicity pertaining to distribution of
 * the software without specific, written prior permission.  MIT and
 * UniSoft make no representations about the suitability of this
 * software for any purpose.  It is provided "as is" without express
 * or implied warranty.
 *
 * $XConsortium: getopt.c,v 1.2 92/07/01 11:59:04 rws Exp $
 * NB: Reformatted to match above style.
 */

Are we really serving the community by preventing the inclusion of such
code components?  If we do want to allow them, how would we adjust the
rules?

Russ

Note Well

Marshall Eubanks — 2010-04-09T18:12:19

The Note Well says in part


Does this need to be expanded to include the other stream editors ? Or  
do the other streams need their own Note Well ?

Regards
Marshall

W3C discussing document copyrights

Harald Alvestrand — 2010-03-29T06:12:50

I feel like I've seen this discussion before....

http://www.w3.org/QA/2010/03/update_on_html_5_document_lice.html

Excerpt:

The result of discussion among the Membership is that there is strong 
support for:

    * a license that allows the reuse of excerpts in software, software
      documentation, test suites, and other scenarios;
    * a license (or licenses) that are familiar to the open source
      community;
    * processes that encourage innovation and experimentation about Web
      technology, so that work can be easily brought to W3C for
      standardization;
    * making the HTML Working Group a forum that is conducive to
      participation by the community at large;
    * ensuring that the HTML 5 specification remains valuable to the
      entire Web community (see an update from Philippe Le Hégaret on
      HTML <http://www.w3.org/2010/Talks/0323-html-plh/> that he
      presented to the Membership).

In short, there is strong support in the Membership (but not unanimity) 
for all of the use cases cited by the HTML Working Group /except/ 
forking the specification. Several W3C Members do feel strongly that the 
document license should allow forking, however.

Question - is the emailing of a content to the IETF deemed to createa legally enforceable submission?

Todd Glassey — 2010-02-15T14:02:20

The reason I bring this up is this work by John Gregory (an Attorney for

the Policy Group in the Canadian Prime Ministers office) on when eSign
is binding and when it is not.

The problem I am having is that there is no eSign process for IP based
on an emailing with no commentary for submission and well... it means
that NoteWell probably doesnt work the way we think it does.

http://www.euclid.ca/reliability_sigs.pdf

Commercial implementations and BSD and GPL

Alexandru Petrescu — 2010-02-12T16:07:12

YEs, I have been pointed out privately about the fact that commercial
interests keep some RFC code at the heart of the products, which can't
be of course given for free, otherwise commerce dies out.

Yes, I agree - I respect commercial interests and I live on commercial
interests by the way.

That said - people lived on commercial interests before too, without
"BSD" at the beginning of each RFC.

This "BSD" in the preamble looks as something very bad may have
happened, I don't know what.

Alex

Simplified BSD License for Code Components and linux GPL kernel

Alexandru Petrescu — 2010-02-10T18:46:38

Hi IPR WG,

I have interest in licensing and IPR of the technology in RFCs.

I recently stumbled on the RPL protocol WG item draft (in the RoLL WG,
Routing Over Low power and Lossy networks) and worried about "Code
Components" in the boilerplate.

Could one implement RPL in a linux kernel?

Knowing that linux kernel is mostly GPL, avoiding BSD, and that I see
the word BSD in the bolierplate.

If I may be missing something - sorry,

Alex

FORMAL NOTICE... you are not to share my email address with anyone

tglassey — 2010-02-07T16:26:10

Folks - I have had it with Dean's IETF-HONEST posts and am going to do 
something about them. What's amazing is that your brain trust wasnt able 
to get this one but hey... it is what it is eh?

So - the first step is in notifying the IETF that under personal privacy 
codes in a number of States that my email address is protected 
information. Information I share with the IETF for use inside IETF 
processes which take place on IETF sponsored lists and for no other 
reason.  Because of the sloppy work by the IPR WG which I brought up to 
Harald many times, this matter is still unhandled. So let me explain 
what is going to happen next. The first part is I put you on notice and 
through formal service to the ISOC's corporate point of service since 
the IETF was never really incorporated as far as I can tell with the 
following demand: The next step is litigation to support that cease and 
desist demand.

--------------------------
Be advised that as a member of an IETF WG I am not authorizing the IETF to

     1)     republish my email address with authorization to 
redistribute or republish that address for any use whatsoever.

     2)     allow the use of IETF mailing lists containing my name to be 
used by any third party outside the IETF.


As such be advised that under NoteWell and IPR Requirements herein I am 
filing an IPR Notice that My Email Address is a protected piece of 
personally owned IP and I am not authorizing the IETF to license its 
reuse under any terms.
--------------------------



Todd Glassey

IPR Notice pages are broken

tglassey — 2010-01-31T15:57:41

I tried to file a new IPR notice this AM and the form is broken - 
produces a failure message...


Todd

Proposed immediate addition to NoteWell use rules.

tglassey — 2010-01-31T16:34:09

I propose the following amendment to the NoteWell Use terms:

     "While IETF Technology Documents and their Vetting Process produces 
a large amount of communications between parties, email addresses in 
those may only be used in the furtherance of that specific initiative. 
Those addresses are the property of the IETF and represent the one part 
of IETF intellectual properties which are not made available to third 
parties for the creation of pre-built mailing lists outside of the IETF 
itself."

This will stop  anyone from harvesting the email addresses of people and 
then setting up subsidiary lists

Todd Glassey

All IETF posted email addresses MUST be real.

tglassey — 2010-01-22T03:26:01

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

Determine the stream of an RFC

Freek Dijkstra — 2010-01-16T01:24:06

The Legal Provisions Relating to IETF Documents,
http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm,
make an important distinction between documents in the IETF Stream and
documents in Alternative Streams, such as independent submissions.

Given a RFC, how can I determine its stream, and thus its license?

In most cases, I can guess based on the authors, or the category.
However, this will not be fool-proof. For example, RFC 5745 is clearly
part of the IAB stream, thus according to part 8b of the IETF TLP, part
of Alternate Stream. However, it does contain the boilerplate text of 6
b i (for the IETF stream), instead of the boilerplate text of 6 b ii
(for the alternate stream).

Would it be useful to explicitly include the stream in the boilerplate
text of the Copyright Notice section, so that the appropriate license
terms are clear for all readers?

Regards,
Freek Dijkstra

Simplified BSD License for Code Components

Russ Housley — 2010-01-07T19:52:07

The IETF Stream requires that code extracted from an RFC be put under 
the simplified BSD license.  The other RFC streams (IAB, IRTF, and 
Independent Submission) have rejected this approach.  Instead these 
streams simply require proper attribution.

Why is the IETF Stream different?  It would be much easier on everyone 
if the same approach were used across all of the RFC streams.

Russ

Fwd: Proposed Editorial Change to the Legal ProvisionsRelating to IETF Documents (TLP)

Russ Housley — 2009-12-07T22:53:38

The IRTF and Independent Submission Streams have rejected the 
Simplified BSD License for their stream.  Instead, these streams are 
simply saying that the code is provided "as is".  Since these streams 
always allow derivative works with attribution, it applies to the 
text as well as any code.

Russ

Request for comments on proposed changes to the IETF Trust LegalProvisions (TLP)

Marshall Eubanks — 2009-11-25T21:35:48

Greetings;

The Trustees are proposing additional changes to the Legal Provisions
Relating to IETF Documents effective September 12, 2009 (TLP 3.0).
This is a formal request for community review, with a 30 day review
period ending on December 27, 2009

The additional changes proposed here (TLP 4.1) are A.) at the request
of the Alternate Stream managers regarding the treatment of 'code
components' and B.) at the request of the community regarding the
addition of Alternate Stream managers to the warranty disclaimer.
These changes result from the discussion of the proposed changes
announced on 23 October, which are included in this document for
review as section C. PDF versions and differences between the existing
TLP are available at http://trustee.ietf.org/policyandprocedures.html.

A.) Elimination of BSD licensing for Alternate Stream documents

This action requires revisions to four sections: 4.c, 8.e, 8.f, and
8.g as follows: [Note *** indictes begin and end added text)

Section 4.License to Code Components.

c.License. In addition to the licenses granted under Section 3,
unless one of the legends contained in Section 6.c.i or 6.c.ii is
included in an IETF Document containing Code Components, such Code
Components are also licensed to each person who wishes to receive such
a license on the terms of the “Simplified BSD License", as described
below. If a licensee elects to apply the BSD License to a Code
Component, then the additional licenses and restrictions set forth in
Section 3 and elsewhere in these Legal Provisions shall not apply
thereto. ***Note that this license is specifically offered for IETF
Documents and may not be available for Alternate Stream documents. See
Section 8 for licensing information for the appropriate stream.***

Section 8.Application to non-IETF Stream Documents

[Note: This language added to IAB, IRTF and Indep Submissions
paragraphs:
***Section 4 of these Legal Provisions shall not apply to documents
in the [Stream], and all references to Section 4 hereof shall be
disregarded with respect to documents in the [Stream]***]

e.IAB Document Stream. Pursuant to Section 11 of RFC 5378, the IAB
requested, as of April 4, 2008, that the IETF Trust act as licensing
administrator for the IAB Document Stream and that these Legal
Provisions be applied to documents submitted and published in the IAB
Document Stream following the Effective Date of RFC 5378. ***Section
4 of these Legal Provisions shall not apply to documents in the IAB
Document Stream, and all references to Section 4 hereof shall be
disregarded with respect to documents in the IAB Document Stream***
*** pursuant to [Refefrence] published on [DATE]***. [Note: this last
addition reflects the authority for the Elimination of BSD licensing
for the IAB]

f.Independent Submission Stream. Pursuant to RFC [xxxx] published
on [DATE], the manager of the Independent Submission Stream has
requested that the IETF Trust act as licensing administrator for the
Independent Submission Stream and that these Legal Provisions be
applied to documents submitted and published in the Independent
Submission Stream following [DATE]. *** Section 4 of these Legal
Provisions shall not apply to documents in the Independent Submission
Stream, and all references to Section 4 hereof shall be disregarded
with respect to documents in the Independent Submission Stream.***

g.IRTF Document Stream. Pursuant to RFC [xxxx] published on
[DATE], the manager of the IRTF Document Stream has requested that the
IETF Trust act as licensing administrator for the IRTF Document Stream
and that these Legal Provisions be applied to documents submitted and
published in the IRTF Document Stream following [DATE]. ***Section 4
of these Legal Provisions shall not apply to documents in the IRTF
Document Stream, and all references to Section 4 hereof shall be
disregarded with respect to documents in the IRTF Document Stream.***

B.) Addition of Alternate Stream managers to warranty disclaimer

This action requires revision to two sections, 7.a and 8.c.ii.

7.Terms Applicable to All IETF Documents

ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN
"AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, THE
INTERNET ENGINEERING TASK FORCE *** AND ANY APPLICABLE MANAGERS OF
ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW***, DISCLAIM
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.

8.Application to non-IETF Stream Documents
c.Alternate Stream License.

ii.Each occurrence of the term “IETF Contribution” and “IETF
Document” in these Legal Provisions shall be read to mean a
Contribution or document in such Alternate Stream, as the case may
be. ***The disclaimer in Section 7.a of these Legal Provisions shall
apply to the manager of such Alternate Stream as defined in RFC 4844
as though such manager were expressly listed in Section 7.a.***

C.) The 23 October announced changes

The 23 October changes are required based upon a request from the RFC
Editor on behalf of the Independent Submissions Stream, and from the
IRTF Steering Group (IRSG) on behalf of the IRTF Stream (Alternate
Streams) that the IETF Trust act as the license administrators for the
RFCs produced by their streams. The basic intent of these changes is
to both make changes necessary to accept these new streams, and to
make it possible for these new streams to operate under "Postel
Rules." Additional minor changes are sought by the Trustees to
clarify language in TLP 3.0.

The Trustees believe the following changes are necessitated by the
request of the RFC Editor and IRSG,

a. Section 1. -- eliminated reference to "IETF Standards Process" to
broaden scope for Alternate Streams. Also added a sentence
acknowledging the addition of Alternate Streams.

b. Section 6.a -- deleted "to IETF" so that this legend can be used in
Alternate Stream documents in a less confusing way.

c. Section 7.f -- removed references to IETF Standards Process to
accommodate Alternate Stream usage.

d. Section 8.a -- this paragraph provides some background/context for
readers who have not been following the Alternate Stream discussion.
It references RFC 4844 (which defines the Alternate Streams).

e. Section 8.b -- this paragraph says that Alternate Stream managers
(as defined in 4844) can request that the IETF Trust act as the
licensing administrator for their Alternate Stream documents, and that
the Trust will do this, acting in accordance with their request and
the Trust's legal obligations.

f. Section 8.c -- this paragraph contains the basic license grants for
the Alternate Streams. Essentially, Alternate Stream contributions
are licensed TO the Trust on the terms of 5378, and are licensed BY
the Trust on the terms of the TLP (subject to any exceptions noted in
later paragraphs).

g. Section 8.d -- IMPORTANT: clarifies that Alternate Stream
contributors must ensure that they have all necessary rights to make
their contributions, including the right to contribute previously-
published material. There is no pre-5378 legend/carve-out for
Alternate Stream documents, and authors of contributions in these
streams take full responsibility for the entire contents of their
contributions, whether or not they re-use older material. This is a
different approach than for IETF Contributions, which have the
pre-5378 legend escape-valve for older material.

h. Section 8.e - g -- there is a separate paragraph for each of the
IAB, Independent and IRTF streams. Each of their "requests" to the
Trust is made in a separate document and may have a different
effective date, so it seemed cleaner to treat them separately. In
each of these paragraphs there is a clause stating that there are no
limits on making derivative works of these documents unless specific
no-derivatives legends are included.

The changes requested by the Trustees are as follows:

i. Section 2.c -- bug fix: first reference was to contributions and
documents, second was only to documents. "Contributions" was added
for parallel construction.

j. Sections 4.e, 6.b and 6.d -- added "Simplified" before "BSD
License" for consistent usage.

The proposed revisions as TLP 4.0 are in rtf, pdf and doc formats and
located at: http://trustee.ietf.org/policyandprocedures.html under
Draft Policies and Procedures for IETF Documents. There is also a 3.0
diff file in doc and pdf formats at the same location.

The discussion of these proposed changes is taking place on the TLP-
interest mailing list. One may subscribe to the TLP mailing list at: https://www.ietf.org/mailman/listinfo/tlp-interest

If during the 30 day community review period the proposal is revised,
the Trust may withdraw or modify the proposal, publish it and reset
the counter to begin a new 30 day review period before the comment
period is over.

If textual changes are needed after the 30 day community review
period, the Trust may modify the proposal, publish it and announce a
14 day review period.

Please accept this message as a formal request by the IETF Trustees
for your review and feedback on the proposed revision to the TLP
document. The comment period will end on December 27, 2009.

Regards, and thanks in advance,

Marshall Eubanks
IETF Trust Chair

Request for comments on proposed changes to the IETF Trust LegalProvisions (TLP)

Marshall Eubanks — 2009-11-25T21:35:26

Greetings;

A.) Elimination of BSD licensing for Alternate Stream documents

This action requires revisions to four sections: 4.c, 8.e, 8.f, and
8.g as follows: [Note *** indictes begin and end added text)

Section 4.License to Code Components.

Section 8.Application to non-IETF Stream Documents

B.) Addition of Alternate Stream managers to warranty disclaimer

This action requires revision to two sections, 7.a and 8.c.ii.

7.Terms Applicable to All IETF Documents

8.Application to non-IETF Stream Documents
c.Alternate Stream License.

C.) The 23 October announced changes

The Trustees believe the following changes are necessitated by the
request of the RFC Editor and IRSG,

a. Section 1. -- eliminated reference to "IETF Standards Process" to
broaden scope for Alternate Streams. Also added a sentence
acknowledging the addition of Alternate Streams.

b. Section 6.a -- deleted "to IETF" so that this legend can be used in
Alternate Stream documents in a less confusing way.

c. Section 7.f -- removed references to IETF Standards Process to
accommodate Alternate Stream usage.

The changes requested by the Trustees are as follows:

i. Section 2.c -- bug fix: first reference was to contributions and
documents, second was only to documents. "Contributions" was added
for parallel construction.

j. Sections 4.e, 6.b and 6.d -- added "Simplified" before "BSD
License" for consistent usage.

The discussion of these proposed changes is taking place on the TLP-
interest mailing list. One may subscribe to the TLP mailing list at: https://www.ietf.org/mailman/listinfo/tlp-interest

If textual changes are needed after the 30 day community review
period, the Trust may modify the proposal, publish it and announce a
14 day review period.

Please accept this message as a formal request by the IETF Trustees
for your review and feedback on the proposed revision to the TLP
document. The comment period will end on December 27, 2009.

Regards, and thanks in advance,

Marshall Eubanks
IETF Trust Chair

Request for comments on proposed changes to the IETF Trust LegalProvisions (TLP)

Marshall Eubanks — 2009-10-23T18:41:34

Greetings;

The Trustees are proposing changes to the Legal Provisions Relating to
IETF Documents effective September 12, 2009 (TLP 3.0). This is a
formal request for community review. The review period will be for
thirty days and end on November 24, 2009

The changes are required based upon a request from the RFC Editor on
behalf of the Independent Submissions Stream, and from the IRTF
Steering Group (IRSG) on behalf of the IRTF Stream (Alternate Streams)
that the IETF Trust act as the license administrators for the RFCs
produced by their streams. The basic intent of these changes is to
both make changes necessary to accept these new streams, and to make
it possible for these new streams to operate under "Postel Rules."
Additional minor changes are sought by the Trustees to clarify
language in TLP 3.0.

The Trustees believe the following changes are necessitated by the
request of the RFC Editor and IRSG,

a. Section 1. -- eliminated reference to "IETF Standards Process" to
broaden scope for Alternate Streams. Also added a sentence
acknowledging the addition of Alternate Streams.

b. Section 6.a -- deleted "to IETF" so that this legend can be used in
Alternate Stream documents in a less confusing way.

c. Section 7.f -- removed references to IETF Standards Process to
accommodate Alternate Stream usage.

The changes requested by the Trustees are as follows:

i. Section 2.c -- bug fix: first reference was to contributions and
documents, second was only to documents. "Contributions" was added
for parallel construction.

j. Sections 4.e, 6.b and 6.d -- added "Simplified" before "BSD
License" for consistent usage.

The discussion of these proposed changes is taking place on the TLP-
interest mailing list. One may subscribe to the TLP mailing list at: https://www.ietf.org/mailman/listinfo/tlp-interest

If textual changes are needed after the 30 day community review
period, the Trust may modify the proposal, publish it and announce a
14 day review period.

Please accept this message as a formal request by the IETF Trustees
for your review and feedback on the proposed revision to the TLP
document. The comment period will end on November 24, 2009.

Regards, and thanks in advance,

Marshall Eubanks
IETF Trust Chair

Why is a I-D obsolting a RFC?

Todd Glassey — 2009-09-20T22:28:13

Chair - why is a RFC being obsoleted by an Internet-Draft?

Seems to me like an impossibility. No I-D can in and of itself strip any 
RFC document without issuing a new RFC to replace the old one. Since an 
I-D is NOT a RFC this is an issue.

This is a problem per se like this one... 
http://tools.ietf.org/html/draft-ietf-ntp-autokey-06

Todd Glassey