|
List Info
Thread: The Law... Definition of Derivative Claims...
|
|
| The Law... Definition of Derivative
Claims... |
|
2006-01-18 17:23:37 |
Joel -
-------------- Original message ----------------------
From: "Joel M. Halpern" <joel stevecrocker.com>
> Todd,
> An implementation of a protocol does not require
any copying rights
> relative to the description of that protocol.
Sure it does - the use of the pseudo-code mnemonics would
require exactly that. They are copyrighted and possibly also
trademarked (although TM'ing the Code Statements in a
programming language or TCP/IP protocol could be quite
expensive... still its totally reasonable.
> You seem to be asserting that copyright transfer
is required for an
> implementation (software or hardware) of a protocol.
I am asserting that derivative rights are needed to
republish in any excerpted form other than as the 'whole
enchiladas'... And that if a version of the protocol is
implemented using those mnemonics and notations, that it
will indeed violate the copyright against that.
> You seem to be repeating this assertion.
> The C (or other language) implementation does not
use the words of the
> RFC.
No, but if the workflow of the C language is implemented in
the second port it does indeed need the derivative rights
granted and if the protocol was to implement the model
specified in the draft or RFC it most assuredly needs those
derivative rights.
Re-publication rights are just that - the rights to
republish under some controlled set of circumstances.
> Copyright is only required if you make use of the words
of the source
> material. Using the ideas of the source material does
not require the
> right to copy the source material.
Depends on how they are documented. In most instances where
Copyright alone was used I may agree, but here where the
code is in many instances inseparble from the RFC itself, I
would disagree.
> There is an issue with regard to the use of MIBs
and such like. Which
> we have always intended to permit. We may, as per some
of Simon's remarks,
> have mangled that in the last revision. The working
group has already
> agreed to fix that.
OK - I understand that you personally and many of the IETF
management have intended to allow free use of those code
bodies, but they may be owned outside of the IETF's process,
and so it also needs a place where it can reference or
publish things it is not conveying rights to moving forward
IMHO.
> But that has absolutely nothing to do with the
copyright in the text
> of the document and the question of whether multiple
entities (or even one
> entity distinct from the copyright holders) can
implement that protocol.
Actually it does with regard to pseudo-code and all that ...
the distinction between Copyright and Patent controls on
some IP's is blurring and these are IP's like the ones that
this WG deals with continuously.
>
> If you wish to support your contention that a
software implementation
> of a protocol needs the copyright permission to the
description of the
> protocol (apparently, according to your view, because
the protocol
> implementation is a derivative work of a protocol
description), please
> provide very specific citation so that I do not waste
the time of my legal
> expert searching for your assertion.
I think I have already but I am willing to also take the
IETF to court to settle this - not as an adversary, but to
help convince that this is fact and it needs to be dealt
with as such. Seriously - I am not threatening to sue anyone
here - what I am saying is that I am sure that the Court's
are going to look at this in a very different light than
many of th IESG and IETF have painted it to date. But that
is just my two cents.
>
> Yours,
> Joel M. Halpern
>
> At 10:29 AM 1/18/2006, todd.glasseyatt.net
wrote:
> >Harald - in your zeal to bodyslam me you missed the
point - the IETF's RFC
> >and ID documents ARE descriptions of those
technologies and while the
> >technologies themselves are not protected by the
Copyright per se, the
> >descriptions of them are, and that is what we are
talking about here. What
> >is needed in the process of republishing those
documents per the rights
> >transferred.
> >
> >-----
> >
> >Harald why not try this - take a deep breath and
realize that I am in the
> >middle of this IP mess and its going to stay that
way. So rather than
> >fight me and make me adversarial to you folks - why
not ask me to
> >demonstrate the key issues of my complaints and
figure whether the risks
> >of not addressing them are more than the cost of
your distaste for me
> >personally.
> >
> >By the way - good morning...
> >
> >Todd
> >
> > -------------- Original message
----------------------
> >From: Harald Tveit Alvestrand <haraldalvestrand.no>
> > >
> > >
> > > --On tirsdag, januar 17, 2006 14:25:06 -0800
todd glassey
> > > <todd.glasseyworldnet.att.net> wrote:
> > >
> > > > Lets look at some law links Harald ...
> > > >
> > > > this one is for the definition of
Copyright and its Claims - American Bar
> > > > Association - notice commentary on
derivative copyrights.
> > > >
http://www.abanet.org/intelprop/comm106/106copy.html
Read through the
> > > > Derivative Licenses setion if you would.
> > >
> > > It does not seem to suport your argument
about the second implementation:
> > >
> > > WHAT IS NOT PROTECTED BY COPYRIGHT
> > >
> > > Ideas, procedures, methods, systems,
processes, concepts, principles,
> > > discoveries, or devices, as distinguished
from a description, explanation,
> > > or illustration.
> > >
> > >
_______________________________________________
> > > Ipr-wg mailing list
> > > Ipr-wgietf.org
> > > https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
> >
> >
> >
> >_______________________________________________
> >Ipr-wg mailing list
> >Ipr-wgietf.org
> >https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>
_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|
|
| The Law... Definition of Derivative
Claims... |
|
2006-01-19 00:36:35 |
> I am asserting that derivative rights are needed to
republish
> in any excerpted form other than as the 'whole
enchiladas'...
> And that if a version of the protocol is implemented
using
> those mnemonics and notations, that it will indeed
violate
> the copyright against that.
To the extent that copying an expressive piece of code is
necessary for an
implementation of a functional protocol in a published
standard that we
*intend* to be implemented, copyright can't prevent the
copying. This is
based on the "merger doctrine," as expressed in
the section of the Copyright
Act that Harald previously referenced. And when a change to
that code is
required in order to achieve a functional result, that
change can't be
prevented based on an exclusive right to create derivative
works.
That would give long-term copyright way too much power to
control
technology. The law doesn't countenance that. If you want
your software
ideas not to be copied and evolved, either keep them secret
or patent them;
don't expect copyright law to help you.
IETF's current procedures for in-bound and out-bound IP are
not clear about
this. That's why I'm delighted that this working group is
trying to clean up
those procedures.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, technology law offices
(www.rosenlaw.com)
Stanford University School of Law, Lecturer in Law
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and
Intellectual Property Law" (Prentice Hall 2004)
[Available also at www.rosenlaw.com/oslbook.htm]
> -----Original Message-----
> From: ipr-wg-bouncesietf.org
> [mailto:ipr-wg-bouncesietf.org] On Behalf Of
todd.glasseyatt.net
> Sent: Wednesday, January 18, 2006 9:24 AM
> To: Joel M. Halpern; Harald Tveit Alvestrand;
ipr-wgietf.org
> Subject: Re: The Law... Definition of Derivative
Claims...
>
> Joel -
> -------------- Original message ----------------------
> From: "Joel M. Halpern" <joelstevecrocker.com>
> > Todd,
> > An implementation of a protocol does not
require any copying
> > rights relative to the description of that
protocol.
>
> Sure it does - the use of the pseudo-code mnemonics
would
> require exactly that. They are copyrighted and possibly
also
> trademarked (although TM'ing the Code Statements in a
> programming language or TCP/IP protocol could be quite
> expensive... still its totally reasonable.
>
> > You seem to be asserting that copyright
transfer is
> required for
> > an implementation (software or hardware) of a
protocol.
>
> I am asserting that derivative rights are needed to
republish
> in any excerpted form other than as the 'whole
enchiladas'...
> And that if a version of the protocol is implemented
using
> those mnemonics and notations, that it will indeed
violate
> the copyright against that.
>
> > You seem to be repeating this assertion.
> > The C (or other language) implementation does
not use
> the words
> > of the RFC.
>
> No, but if the workflow of the C language is
implemented in
> the second port it does indeed need the derivative
rights
> granted and if the protocol was to implement the model
> specified in the draft or RFC it most assuredly needs
those
> derivative rights.
>
> Re-publication rights are just that - the rights to
republish
> under some controlled set of circumstances.
>
>
> > Copyright is only required if you make use of the
words of
> the source
> > material. Using the ideas of the source material
does not
> require the
> > right to copy the source material.
>
> Depends on how they are documented. In most instances
where
> Copyright alone was used I may agree, but here where
the code
> is in many instances inseparble from the RFC itself, I
would disagree.
>
> > There is an issue with regard to the use of
MIBs and
> such like.
> > Which we have always intended to permit. We may,
as per some of
> > Simon's remarks, have mangled that in the last
revision.
> The working
> > group has already agreed to fix that.
>
> OK - I understand that you personally and many of the
IETF
> management have intended to allow free use of those
code
> bodies, but they may be owned outside of the IETF's
process,
> and so it also needs a place where it can reference or
> publish things it is not conveying rights to moving
forward IMHO.
>
> > But that has absolutely nothing to do with
the
> copyright in the
> > text of the document and the question of whether
multiple
> entities (or
> > even one entity distinct from the copyright
holders) can
> implement that protocol.
>
> Actually it does with regard to pseudo-code and all
that ...
> the distinction between Copyright and Patent controls
on some
> IP's is blurring and these are IP's like the ones that
this
> WG deals with continuously.
>
> >
> > If you wish to support your contention that a
software
> > implementation of a protocol needs the copyright
permission to the
> > description of the protocol (apparently, according
to your view,
> > because the protocol implementation is a
derivative work of
> a protocol
> > description), please provide very specific
citation so that
> I do not
> > waste the time of my legal expert searching for
your assertion.
>
> I think I have already but I am willing to also take
the IETF
> to court to settle this - not as an adversary, but to
help
> convince that this is fact and it needs to be dealt
with as
> such. Seriously - I am not threatening to sue anyone
here -
> what I am saying is that I am sure that the Court's are
going
> to look at this in a very different light than many of
th
> IESG and IETF have painted it to date. But that is just
my two cents.
>
>
> >
> > Yours,
> > Joel M. Halpern
> >
> > At 10:29 AM 1/18/2006, todd.glasseyatt.net
wrote:
> > >Harald - in your zeal to bodyslam me you
missed the point - the
> > >IETF's RFC and ID documents ARE descriptions
of those technologies
> > >and while the technologies themselves are not
protected by the
> > >Copyright per se, the descriptions of them
are, and that
> is what we
> > >are talking about here. What is needed in the
process of
> republishing
> > >those documents per the rights transferred.
> > >
> > >-----
> > >
> > >Harald why not try this - take a deep breath
and realize
> that I am
> > >in the middle of this IP mess and its going to
stay that way. So
> > >rather than fight me and make me adversarial
to you folks
> - why not
> > >ask me to demonstrate the key issues of my
complaints and figure
> > >whether the risks of not addressing them are
more than the cost of
> > >your distaste for me personally.
> > >
> > >By the way - good morning...
> > >
> > >Todd
> > >
> > > -------------- Original message
----------------------
> > >From: Harald Tveit Alvestrand <haraldalvestrand.no>
> > > >
> > > >
> > > > --On tirsdag, januar 17, 2006 14:25:06
-0800 todd glassey
> > > > <todd.glasseyworldnet.att.net> wrote:
> > > >
> > > > > Lets look at some law links Harald
...
> > > > >
> > > > > this one is for the definition of
Copyright and its Claims -
> > > > > American Bar Association - notice
commentary on
> derivative copyrights.
> > > > >
http://www.abanet.org/intelprop/comm106/106copy.html
Read
> > > > > through the Derivative Licenses
setion if you would.
> > > >
> > > > It does not seem to suport your argument
about the
> second implementation:
> > > >
> > > > WHAT IS NOT PROTECTED BY COPYRIGHT
> > > >
> > > > Ideas, procedures, methods, systems,
processes, concepts,
> > > > principles, discoveries, or devices, as
distinguished from a
> > > > description, explanation, or
illustration.
> > > >
> > > >
_______________________________________________
> > > > Ipr-wg mailing list
> > > > Ipr-wgietf.org
> > > > https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
> > >
> > >
> > >
> >
>_______________________________________________
> > >Ipr-wg mailing list
> > >Ipr-wgietf.org
> > >https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
> >
>
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|
|
| The Law... Definition of Derivative
Claims... |
|
2006-01-19 08:52:09 |
"Lawrence Rosen" <lrosenrosenlaw.com> writes:
> To the extent that copying an expressive piece of code
is necessary for an
> implementation of a functional protocol in a published
standard that we
> *intend* to be implemented, copyright can't prevent the
copying. This is
> based on the "merger doctrine," as expressed
in the section of the Copyright
> Act that Harald previously referenced. And when a
change to that code is
> required in order to achieve a functional result, that
change can't be
> prevented based on an exclusive right to create
derivative works.
Interesting. How much modifications are permitted? If what
you say
is true, it seems third parties already have some leeway to
argue that
they have the right to incorporate ASN.1 schemas and make
modifications to them, regardless of the IETF outbound
copying
conditions.
Making those rights clear is still useful, of course,
because it will
educate IETF participants how their documents will likely be
used.
Regards,
Simon
_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|
|
| The Law... Definition of Derivative
Claims... |
|
2006-01-19 19:49:11 |
> > To the extent that copying an expressive piece of
code is necessary
> > for an implementation of a functional protocol in
a
> published standard
> > that we
> > *intend* to be implemented, copyright can't
prevent the
> copying. This
> > is based on the "merger doctrine," as
expressed in the
> section of the
> > Copyright Act that Harald previously referenced.
And when a
> change to
> > that code is required in order to achieve a
functional result, that
> > change can't be prevented based on an exclusive
right to
> create derivative works.
>
> Interesting. How much modifications are permitted? If
what
> you say is true, it seems third parties already have
some
> leeway to argue that they have the right to incorporate
ASN.1
> schemas and make modifications to them, regardless of
the
> IETF outbound copying conditions.
I do not suggest that we live with implied rights based on
the merger
doctrine. We should make our rules explicit. That way your
question ["How
much modifications are permitted?"] won't have to be
analyzed by everyone
who wants to implement our specifications.
My note was merely intended to suggest that Todd is quite
wrong when he
asserts that the exclusive right of authors to create
derivative works
automatically makes IETF specifications unavailable for
implementation and
modification.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, technology law offices
(www.rosenlaw.com)
Stanford University School of Law, Lecturer in Law
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and
Intellectual Property Law" (Prentice Hall 2004)
[Available also at www.rosenlaw.com/oslbook.htm]
> -----Original Message-----
> From: Simon Josefsson [mailto:jasextundo.com]
> Sent: Thursday, January 19, 2006 12:52 AM
> To: lrosenrosenlaw.com
> Cc: ipr-wgietf.org
> Subject: Re: The Law... Definition of Derivative
Claims...
>
> "Lawrence Rosen" <lrosenrosenlaw.com> writes:
>
> > To the extent that copying an expressive piece of
code is necessary
> > for an implementation of a functional protocol in
a
> published standard
> > that we
> > *intend* to be implemented, copyright can't
prevent the
> copying. This
> > is based on the "merger doctrine," as
expressed in the
> section of the
> > Copyright Act that Harald previously referenced.
And when a
> change to
> > that code is required in order to achieve a
functional result, that
> > change can't be prevented based on an exclusive
right to
> create derivative works.
>
> Interesting. How much modifications are permitted? If
what
> you say is true, it seems third parties already have
some
> leeway to argue that they have the right to incorporate
ASN.1
> schemas and make modifications to them, regardless of
the
> IETF outbound copying conditions.
>
> Making those rights clear is still useful, of course,
because
> it will educate IETF participants how their documents
will
> likely be used.
>
> Regards,
> Simon
_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|
|
[1-4]
|
|