Subject: RE: IEEE versus Responsible IP Management
From: John Willis (john.willis@ftlsys.com)
Date: Wed Jun 11 2003 - 15:57:36 PDT
Bill,
Unfortunately IEEE's financial problems, heavy IEEE employee turnover
and other IEEE problems have made it extraordinarily difficult to work
with the IEEE administrative staff on IP issues.
DATC is also actively fighting to bring IEEE's copyright mindset up
to the 19th century. Currently, as the DATC Chair I find that the
only professionally responsible recommendation to DATC-supported
conferences is to assign copyright to ACM / SigDA so that material
can be made freely available via the web. Discussion is ongoing to
try to modernize IEEE's process.
I believe the original issue was related to copyright, however patent
rights have been a blocking issue on several potential IEEE standards.
On specific issues:
Specifically on work that FTL Systems exposes to IEEE Standards, the
material is carefully reviewed to exclude any patent pending material
known to the company. We cannot control material submitted by any
second or third party beyond CDA, NDA and other contractual vehicles.
Some of the issues I am aware of:
One company will try to insert reference to a second party's patent-
pending material into a standard. If the second party is involved
with the standard their rights to the technology made be put at risk.
For example, the Verilog-AMS committee at one point inserted
specification of an Analogy / Avanti / Synopsys patent (can't speak
to intent, but the technology was recognized and excised).
IEEE's proposed PAR form uses the language "work-for-hire". In many
countries and states, this can imply that any patents applied for on
behalf of the IEEE member's actual employer and generally related to
the IEEE work would (in theory) be assignable to IEEE. I don't know
of any company that knowing allows signature on such documents. It
would be much easier to work with IEEE if their draft PAR form did
not require a review and rejection cycle to avoid surrending patent
rights to IEEE. I know of several companies where the company's IP
counsel has developed almost a reflex response when a document has
an IEEE logo on it; REJECT, do not sign on behalf of the company.
Companys often spend substantial sums to develop documents and text.
IEEE would happily take such contribution and refuse to even license
the material back to the company paying for its development. The
only way around this seems to involve providing IEEE with a specific
limited license rather than transfer of copyright they originally
try to demand.
I believe IEEE would see much more forthcoming support if their
procedures really followed the "reasonable-person" principals you
outline. Instead, as many people have observed, support for IEEE
standards is often a career track to repeated unemployment. No
magic or malice, just fair responsibility to share-holders.
Best regards, John
--On Wednesday, June 11, 2003 02:44:35 PM -0500 "Hanna, William A"
<william.a.hanna@boeing.com> wrote:
> Members of the DASC:
>
> Seems that we are getting into circular arguments. Here is my input:
>
> 1. Standards should not carry Patented work. It can reference patented
> work when it is absolutely necessary. Also, you need to be careful not to
> favor one vendor's product over the other. An EDA vendor should not
> surrender his patent rights to the IEEE because he is willing to support
> standards work. Members of the standards working groups should avoid
> bringing patented and/or patenable work to the standards process. We can
> reference it when it is absolutely necessary.
>
> 2. The software packages in the standard are copy right material. It is
> well understood that the fact that a volunteer did write the package, or
> a vendor donated it; the act of providing the source to the standards
> organization implies the surrender of the patent rights to IEEE. These
> sources should be very generic in nature and should not have anything
> specific in them that requires a particular vendor specific tool/utility
> to be able to use it.
>
> 3. It is not fair for the IEEE to try to own patent rights of the work of
> volunteers, or business entities supporting the development of IEEE
> standards, and for this reason, standards should include neither patented
> nor patentable software. Standards should be limited to avoid such
> conflicted situation.
>
> 4. Grandfather clock implies that all the old work should be treated as
> copy right protected only regardless of its contents. New standards shall
> not include any patetnable software. If it does then the owner of the
> patents rights has surrendered his rights by the very act of revealing it
> in a standard.
>
> I for one will not even open a standard document if there is any hint of
> patent rights of any kind. Let's be reasonable.
>
> Bill Hanna
> Tech Fellow
>
> Boeing-Phantom Works Phone: (314)
> 233-1678 MC S102-1310
> Fax: (314) 777-1171 St. Louis, MO 63166-0516 E-Mail:
> william.a.hanna@boeing.com
>
>
>
> -----Original Message-----
> From: Alex Zamfirescu [mailto:hxml@pacbell.net]
> Sent: Wednesday, June 11, 2003 1:57 PM
> To: Stephen Bailey; John Willis; Paul J. Menchini; stds-dasc@dasc.org
> Subject: Re: Electronic Standards Delivery Issue
>
>
> Steve:
>
> You did not understand the picture.
> The idea was to come up with just a general description
> (no code) of the functionality for numerics and the floating
> point types and let the community to implement
> that functionality. In the case of SIGNED, UNSIGNED
> there are today at least two implementations that
> might comply with a general description. I do
> not think that IEEE can claim copyright of both.
> As for the FP there is nothing in the IEEE yet
> so there is no issue.
>
> Bringing .3 into 1076 will not solve the problem
> to accommodate the industry using two versions
> of an implementation for SIGNED, UNSIGNED.
> While I agree that the industry have to comply to
> existing valid IEEE standards, I have to recognize
> that we (in developing the standards) might go
> too deep in implementation (probably because it
> is easier that way) and might restrict some liberties
> that (strong) vendors and (weak/naive) users may
> want to enjoy.
>
> Best regards,
>
> Alex Zamfirescu
>
>
> ----- Original Message -----
> From: "Stephen Bailey" <stephen@srbailey.com>
> To: "Alex Zamfirescu" <hxml@pacbell.net>; "John Willis"
> <john.willis@ftlsys.com>; "Paul J. Menchini" <mench@mench.com>;
> <stds-dasc@dasc.org>
> Sent: Tuesday, June 10, 2003 3:33 PM
> Subject: Re: Electronic Standards Delivery Issue
>
>
>> All,
>>
>> I want to point out that, although I'm not a lawyer, I believe copyright
>> law
> would get in the way of the 1076.3 plans. I believe
>> what Alex is proposing would work for a virgin standard. Since 1076.3
>> has
> already been published by the IEEE, the IEEE owns the
>> copyright to that work *and all derivative works*. Therefore, simply
> removing them from the revised standard would not eliminate
>> the IEEE's copyright claims to the "certified compliant implementations"
>> of
> the packages as they would clearly be derived from the
>> original. Thus, publication and distribution of them without permission
>> from
> the IEEE would be illegal.
>>
>> The real solution here is to get the IEEE to recognize that these souce
>> files
> need to be distributed to promote adoption and usage
>> of the standard. Again, I would like to point out that if 1076.2,
>> 1076.3 and
> 1164 were integrated into 1076, this would probably
>> side step the IEEE copyright issues as these packages would no longer be
> considered by the IEEE to predominantly be the (respective)
>> standard. They would only be a relatively small part of a larger
>> standard.
>>
>> -Steve Bailey
>>
>>
>> > John:
>> >
>> > The implementations I mentioned are not tools
>> > but packages implementing the semantic described
>> > in the standards. The existing IEEE 1076.3 contains
>> > a formally proved implementation (adders add
>> > and multiplier operators multiply), so there is
>> > no reason why such certified implementations are not
>> > feasible. The only diff is that they will belong into public
>> > domain and will enable the use without limits
>> > of quality standards.
>> >
>> > Regards,
>> >
>> > Alex Z
>> >
>> > P.S. Another approach would be to license the
>> > implementations from consortiums that help (meaning $)
>> > the standard development (like Accellera)
>> >
>> >
>> > ----- Original Message -----
>> > From: "John Willis" <john.willis@ftlsys.com>
>> > To: "Alex Zamfirescu" <hxml@pacbell.net>; "Paul J. Menchini"
> <mench@mench.com>;
>> > <stds-dasc@dasc.org>
>> > Sent: Tuesday, June 10, 2003 3:18 PM
>> > Subject: Re: Electronic Standards Delivery Issue
>> >
>> >
>> > > Alex,
>> > >
>> > > Your suggestion makes excellent sense until and unless IEEE
>> > > standards becomes a materially "value-added" proposition.
>> > >
>> > > The issue of "certified-compliant implementation" has its
>> > > own complications. It might be worth reviewing some of the
>> > > concerns NIST had before getting out of the tool compliance
>> > > business. Commercially the business is very marginal.
>> > >
>> > > Best regards, John
>> > >
>> > > --On Tuesday, June 10, 2003 01:01:19 PM -0700 Alex Zamfirescu
>> > > <hxml@pacbell.net> wrote:
>> > >
>> > > > Paul:
>> > > >
>> > > > As you might know IEEE 1076.3 require a soft
>> > > > distribution of the packages.
>> > > >
>> > > > The plan is to re-affirm the standard in 2003 and
>> > > > work in sync with all other affected by numerics
>> > > > to bring a viable solution that will also include
>> > > > variable precision floating point types.
>> > > >
>> > > > The fact that users have to license the packages from
>> > > > the IEEE leads us to thinking about delivering in the future
>> > > > only a mathematical description of the functionality in the
>> > > > standard, and have "certified compliant implementations" available
>> > > > for free on the web. This might be more complicated for
>> > > > the standard developers (the working groups) but we
>> > > > might need to go that long path to make sure that adoption is
>> > > > not stalled by the strong will of the Institute to make
>> > > > money at any price. This is a topic that we need to
>> > > > discuss at the "Numerics Summit" with all groups involved
>> > > > or touched by numerics (including 1076, analog, math
>> > > > logic values, Verilog, System Verilog, Synth, possibly
>> > > > System C, and why not people bringing in the "logic_arith"
>> > > > perspective).
>> > > >
>> > > > Best regards,
>> > > >
>> > > > Alex Z
>> > > >
>> > > > ----- Original Message -----
>> > > > From: "Paul J. Menchini" <mench@mench.com>
>> > > > To: <stds-dasc@dasc.org>
>> > > > Sent: Tuesday, June 10, 2003 8:31 AM
>> > > > Subject: Electronic Standards Delivery Issue
>> > > >
>> > > >
>> > > >> Ladies and Gentlemen of the DASC,
>> > > >>
>> > > >> It has come to my attention that there may be a problem with the
> IEEE's
>> > > >> delivery of certain DASC standards (and possibly other, non-DASC
>> > > >> standards) in electronic form.
>> > > >>
>> > > >> Certain standards (e.g., 1076.2 and, I believe, 1076.3) have
>> > > >> computer files included as part of the standard. When any of
>> > > >> these standards
> is
>> > > >> delivered as a physical copy, either a floppy or a CD (containing
>> > > >> the computer files) is inserted in the book containing the
>> > > >> textual portion of the standard.
>> > > >>
>> > > >> One DASC member has reported to me that he obtained 1076.2
>> > > >> electronically (specifically, as a PDF file) and the delivery did
>> > > >> not include the computer files. This report is what triggered my
>> > > >> investigation.
>> > > >>
>> > > >> Has anybody else experienced this problem? If so, I'd like to
>> > > >> know as I'm now working with the pubs people at IEEE Standards to
>> > > >> resolve this issue. They have confirmed to me that the computer
>> > > >> files should be delivered as part of the electronic distribution.
>> > > >> They've asked me to identify which standards might be affected by
>> > > >> this problem, which prompts this email. And, I've asked them
>> > > >> what to do when this
> delivery
>> > > >> doesn't take place, and hope to soon hear.
>> > > >>
>> > > >> So, I'd like to know:
>> > > >>
>> > > >> * (of anybody) If you've ordered an electronic copy of an IEEE
> standard
>> > > >> that has computer files as part of the standard and did not
>> > > >> receive those computer files. If so, please let me know the
>> > > >> standard number and, if possible, when you ordered the standard
>> > > >> and how.
>> > > >>
>> > > >> * (of WG Chairs) If your group's standard includes computer files,
>> > > >> please let me know its PAR number so that I can have the pubs
>> > > >> people double-check its complete electronic delivery.
>> > > >>
>> > > >> Also, WG and SG Chairs, please distribute this email to your
>> > > >> mailing lists so that people who are affected by this issue but
>> > > >> are not on the current DASC mailing list will be notified. I
>> > > >> apologize in advance
> for
>> > > >> all those who receive multiple copies of this email.
>> > > >>
>> > > >> Thanks and regards,
>> > > >>
>> > > >> Paul Menchini
>> > > >> DASC Chair
>> > > >>
>> > > >
>> > >
>> > >
>> > >
>> > > -----------------------------------------------------------
>> > > John Willis jwillis@ftlsys.com
>> > > FTL Systems Inc. FTL Systems UK Ltd
>> > > 1620 Greenview Drive SW 2 Venture Road
>> > > Rochester, MN 55902 Chilworth Science Park
>> > > United States United Kingdom
>> > > 1.507.288.3154 (Voice) 44.2380.767.700(Voice)
>> > > 1.507.289.1108 (FAX) 44.2380.760.543 (FAX)
>> > > http://www.ftlsystems.com http://www.ftlsystems.co.uk
>> > >
>> >
>> >
>>
>
-----------------------------------------------------------
John Willis jwillis@ftlsys.com
FTL Systems Inc. FTL Systems UK Ltd
1620 Greenview Drive SW 2 Venture Road
Rochester, MN 55902 Chilworth Science Park
United States United Kingdom
1.507.288.3154 (Voice) 44.2380.767.700(Voice)
1.507.289.1108 (FAX) 44.2380.760.543 (FAX)
http://www.ftlsystems.com http://www.ftlsystems.co.uk
This archive was generated by hypermail 2b28 : Wed Jun 11 2003 - 14:15:48 PDT