PROTECTED]
Subject: Re: FW: IETF copying conditions
Lawrence Rosen wrote:
Ted Hardie wrote:
Just to forestall Jorge spending some of his valuable time on this,
I note that I'm not confused about this point--I was talking about
cases
where SDOs wished to re-publish (modified) IETF text
To: 'Harald Alvestrand'; ietf@ietf.org
Cc: [EMAIL PROTECTED]
Subject: RE: FW: IETF copying conditions
Harald Alvestrand wrote;
- The discussion of permitting change to text was extensive
and repeated.
- The consensus of the working group was the compromise
position now
documented
At 10:13 AM -0700 9/25/08, Lawrence Rosen wrote:
snip
The proposed IETF IPR policy allows the public to modify the code present in
IETF specifications but not to use that same specification to create
modified text to document that modified code! Does anyone here honestly
believe this is
Ted Hardie wrote:
At 10:13 AM -0700 9/25/08, Lawrence Rosen wrote:
The proposed IETF IPR policy allows the public to modify the code present in
IETF specifications but not to use that same specification to create
modified text to document that modified code! Does anyone here honestly
Paul Hoffman writes (RE: FW: IETF copying conditions):
Which SDOs that you participate in want to see other SDOs publishing
*incompatible* versions of their protocols?
The Debian project has published a small (by IETF standards) but
significant body of work specifying the interoperation
Larry,
Paul Hoffman wrote:
Which SDOs that you participate in want to see other SDOs publishing
*incompatible* versions of their protocols?
Hi Paul,
Of course none of the SDOs that I work with want to see incompatible
versions. But this turns the issue on its head. Open source and
Actually, it isn't trademark protection, at least in any of the usual senses.
But it may be fraud, or at least misrepresentation of the product.
Well, actually that is almost the same thing.
A (common law) trademark is defined as a distinctive sign used by a legal entity
to uniquely identify
On Wed, Sep 17, 2008 at 10:35:20PM -0400,
Joe Abley [EMAIL PROTECTED] wrote
a message of 31 lines which said:
I think the *whole point* of a standard is to restrict how things
are done, in order to promote interoperability. Complaining about
such restrictions makes no sense to me if interop
On Thu, Sep 18, 2008 at 02:57:32PM +0100,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote
a message of 36 lines which said:
What law would prevent me from publishing the following
GW-SMTP document?
snip-
Gee-Whizz SMTP is a derivative of IETF.
In RFC 2821 replace all occurences of
On 19 Sep 2008, at 07:52, Stephane Bortzmeyer wrote:
On Wed, Sep 17, 2008 at 10:35:20PM -0400,
Joe Abley [EMAIL PROTECTED] wrote
a message of 31 lines which said:
I think the *whole point* of a standard is to restrict how things
are done, in order to promote interoperability. Complaining
At 4:52 AM -0700 9/19/08, Stephane Bortzmeyer wrote:
No, no, Lawrence was talking about the new rules that treat separately
code and text in a RFC. (Many RFC have code and, under the current
rule, you cannot, in theory, extract it and reuse it in free software.)
I think I understand what you
At 11:00 AM -0700 9/18/08, Ian Jackson wrote:
That a different system might do things differently would not be good
for Debian so we don't encourage it. We would prefer to keep Debian
and its derivatives as close as possible so that we can share
development work (particularly, so that we can all
--On Friday, 19 September, 2008 13:52 +0200 Stephane Bortzmeyer
[EMAIL PROTECTED] wrote:
It's no use to me if someone sells a product that claims to
support SMTP
That's trademark protection and it was never considered
seriously by the IPR WG. This WG, instead, tried to prevent
people
On Wed, 17 Sep 2008, Joe Abley wrote:
I think the *whole point* of a standard is to restrict how things are
done, in order to promote interoperability.
Standards are recommendations not restrictions.
Tony.
--
f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/
NORTHWEST SHANNON:
I think the *whole point* of a standard is to restrict how
things are
done, in order to promote interoperability.
Standards are recommendations not restrictions.
Let's say that the restrictions viewpoint wins out in the
IETF and all RFCs are copyrighted in such a way that I
am not free
+1
On Thu, Sep 18, 2008 at 9:10 PM, Tony Finch [EMAIL PROTECTED] wrote:
On Wed, 17 Sep 2008, Joe Abley wrote:
I think the *whole point* of a standard is to restrict how things are
done, in order to promote interoperability.
Standards are recommendations not restrictions.
Tony.
--
[EMAIL PROTECTED] writes:
I think the *whole point* of a standard is to restrict how
things are
done, in order to promote interoperability.
Standards are recommendations not restrictions.
Let's say that the restrictions viewpoint wins out in the
IETF and all RFCs are copyrighted in
of emails on this thread in the
archives of the IPR WG.
/Larry
*
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Brian E Carpenter
Sent: Wednesday, September 17, 2008 2:15 PM
To: [EMAIL PROTECTED]
Subject: Re: FW: IETF copying
At 2:43 PM -0700 9/17/08, Lawrence Rosen wrote:
I'm moving this to [EMAIL PROTECTED] There are important policy implications
here that the entire community should understand before we let the IPR WG
decide for us on a policy so opposite to open source and open standards!
Larry, I'm confused. What
. What a burden that imposes to protect people
from freedom!
/Larry
-Original Message-
From: Paul Hoffman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 17, 2008 3:19 PM
To: [EMAIL PROTECTED]; ietf@ietf.org
Cc: [EMAIL PROTECTED]
Subject: RE: FW: IETF copying conditions
At 2
On 17 Sep 2008, at 18:42, Lawrence Rosen wrote:
Of course none of the SDOs that I work with want to see incompatible
versions. But this turns the issue on its head. Open source and open
standards deal with the freedom to do things, even though we might
discourage people to take us up on that
Simon == Simon Josefsson [EMAIL PROTECTED] writes:
Simon In general, I support your goal of permitting free software
Simon to fully use IETF standards. A few specific comments
Simon below, which should be taken as encouragement to continue
Simon and refine the terms, not
1. Everyone is free to copy and distribute the official specification
for an open standard under an open source license.
Simon Josefsson wrote:
I would include modify in this clause, or clarify exactly which
license you are talking about (e.g., GNU Free Documentation License).
Simon Josefsson wrote:
1. Everyone is free to copy and distribute the official specification
for an open standard under an open source license.
I would include modify in this clause, or clarify exactly which
license you are talking about (e.g., GNU Free Documentation License).
The GFDL is
* fax: 707-485-1243
email: [EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Sam Hartman
Sent: Friday, December 10, 2004 2:07 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Copying conditions
Simon == Simon
On Mon, 2004-12-13 at 20:16, Simon Josefsson wrote:
I would include modify in this clause, or clarify exactly which
license you are talking about (e.g., GNU Free Documentation License).
IMHO, if modify is allowed, the license must require that modified
versions are clearly distinguished from
copying conditions, nor the new copying conditions in RFC
Simon 3667, would permit all of the above extractions into free
Simon software.
Simon I am working on getting them to explain their reasoning on
Simon the Free Software Foundation's web pages (presumably at
Simon [1]), which I
supports these uses
I have received preliminary feedback from IPR specialists that seem to
indicate to me that neither the old RFC copying conditions, nor the
new copying conditions in RFC 3667, would permit all of the above
extractions into free software.
I am working on getting them to explain
scott bradner wrote: 10 October 2004 21:39
small quotes are fine (under fair use) but significant excerpts are not
(under normal copyright law and under the copyright notices on IETF RFCs)
Scott
Well I've just reached to the shelf behind me for a book that some well
meaning (but possibly
* Margaret Wasserman:
The open source community definitely wants to be able to guarantee to
its users the ability to take text or code from an IETF standard and
use that text or code in derivatives of that standard. Parts of the
open source community want to be able to claim that that standard
Does this qualify as a small quote?
sigh
reprinting full RFCs has been permitted encouraged ever since RFCs
were first published - the copyright on the RFCs makes that clear
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
On 11-okt-04, at 1:26, Anthony DeRobertis wrote:
However, this is not to say that having anyone who feels like it
modify RFCs and republish them is a good idea. Treating natural
language text as source code is a spectacularly bad idea. But then,
anyone who has ever tried submitting changes to
In your previous mail you wrote:
reprinting full RFCs has been permitted encouraged ever since RFCs
were first published - the copyright on the RFCs makes that clear
= no more since RFC 3667 which has made nothing clear for third
parties.
Thanks
[EMAIL PROTECTED]
PS: only 7.1b
scott == scott bradner [EMAIL PROTECTED] writes:
If you understand the open source position and disagree with
it, then there's probably little more to say.
scott If the position is that the open source community can take
scott an IETF consensus-based standard, modify it and
]
To: [EMAIL PROTECTED] (scott bradner)
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: Copying conditions
References: [EMAIL PROTECTED]
From: Sam Hartman [EMAIL PROTECTED]
Date: Sun, 10 Oct 2004 16:02:02 -0400
In-Reply-To: [EMAIL PROTECTED] (scott
scott == scott bradner [EMAIL PROTECTED] writes:
scott seems to be a reliable way to ensure that there are
scott multiple understandings of what the standard actually is -
scott I find it hard to understand who that is good for
Do you think that trying to describe a modified version
The open source community definitely wants to be able to guarantee to
its users the ability to take text or code from an IETF standard and
use that text or code in derivatives of that standard. Parts of the
open source community want to be able to claim that that standard is
the real unmodified
small quotes are fine (under fair use) but significant excerpts are not
(under normal copyright law and under the copyright notices on IETF RFCs)
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
-BEGIN PGP SIGNED MESSAGE-
Sam == Sam Hartman [EMAIL PROTECTED] writes:
Sam Some questions I'd suggest you consider:
Sam * Have the IETF's current IPR practices actually limited any
Sam company's ability to embrace and extend Internet standards?
That's a biased question.
[EMAIL PROTECTED] (scott bradner) writes:
there seems to be an assertion of evil intent here that is not the case
What gave you that idea? IMHO, let's leave intent for some other
discussion, and focus on the license.
After having read the discussion for the past few days, I still see no
Iljitsch van Beijnum wrote:
However, this is not to say that having anyone who feels like it modify
RFCs and republish them is a good idea. Treating natural language text
as source code is a spectacularly bad idea. But then, anyone who has
ever tried submitting changes to the collected works of
Harald Tveit Alvestrand [EMAIL PROTECTED] writes:
h.
--On 7. oktober 2004 13:12 +0200 Simon Josefsson [EMAIL PROTECTED] wrote:
As far as I can tell, those rights are only granted to the ISOC and
the IETF, not third parties.
Solely for the purpose of using the term in RFC 3667, the
Simon sez:
For IDN, I want to be able to extract the tables from RFC 3454 and use
them in my implementation.
For Kerberos, I want to be able to use the ASN.1 schema in my
implementation, and copy the terminology section into my manual.
For SASL, I want to incorporate portions of the
Simon,
What is your goal, here? What is it you want to do that you can't do
because of either RFC 3667 or RFC 2026?
Eliot
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
to copy the C header file with function
prototypes into my implementation.
I believe the copying conditions in RFC 2026 give me these rights, but
I have not yet seen anything similar in RFC 3667. I am still looking,
though.
If I'm wrong, and not even RFC 2026 gave me these rights, the
situation
In your previous mail you wrote:
i.e. the rights under 3667 are the same as under 2026 its just stated
more clearly
Even if that is true, it would not change that the current copying
conditions are a problem for the free software community, and in my
opinion, consequently
correctly.
For GSS-API, I want to be able to copy the C header file with function
prototypes into my implementation.
I believe the copying conditions in RFC 2026 give me these rights, but
I have not yet seen anything similar in RFC 3667. I am still looking,
though.
= I understand
it, though.
I don't believe this issue is off topic. I agree with Eric Raymond
that IETF must make an effort to ensure that the standards can be
openly implemented without risking legal consequences. Copying
conditions is a minor tangent to those larger IPR issues, but if it
cannot be resolved, I see
If you extract, say, a C header file, or an ASN.1 schema, from an RFC
into an application, I believe that may be regard as a derivative
work.
see RFC 3667 Section 3.3 (a) (E)
(E) to extract, copy, publish, display, distribute, modify and
incorporate into other works, for any
[EMAIL PROTECTED] (scott bradner) writes:
If you extract, say, a C header file, or an ASN.1 schema, from an RFC
into an application, I believe that may be regard as a derivative
work.
see RFC 3667 Section 3.3 (a) (E)
a. To the extent that a Contribution or any portion thereof is
there seems to be an assertion of evil intent here that is not the case
1/ the IETF requests the mininum rights from an author that it can get
away with so that the author can have maximun flexability with
the author's own text - see section 7.1
The non-exclusive rights that the IETF
h.
--On 7. oktober 2004 13:12 +0200 Simon Josefsson [EMAIL PROTECTED] wrote:
As far as I can tell, those rights are only granted to the ISOC and
the IETF, not third parties.
Solely for the purpose of using the term in RFC 3667, the IETF is defined
as:
a. IETF: In the context of this
At 13:59 07/10/2004, Harald Tveit Alvestrand wrote:
a. IETF: In the context of this document, the IETF includes all
individuals who participate in meetings, working groups, mailing
lists, functions and other activities which are organized or
initiated by ISOC, the IESG or the IAB
In your previous mail you wrote:
= I can't understand why the copyright about a text is a problem
for software when the documentation is explicitely without
restriction of any kind.
Where does it say this? Note that the quote I sent earlier was the
old RFC 2026 copying
On Thu, 07 Oct 2004 07:30:24 EDT, scott bradner said:
there seems to be an assertion of evil intent here that is not the case
The problem isn't one of current evil intent, the problem is that there's
a hole in the tent that an evilly-intented camel could get far more than just
its nose through.
In your previous mail you wrote:
I am sorry to continue this, but I think it is valuable to have a
complete discussion in public on record of this. Especially since
Harald imply IETF hasn't been aware of this before.
= I support you:
- as an employee of a school who could
In your previous mail you wrote:
If you extract, say, a C header file, or an ASN.1 schema, from an RFC
into an application, I believe that may be regard as a derivative
work.
see RFC 3667 Section 3.3 (a) (E)
(E) to extract, copy, publish, display, distribute,
*
* but according to RFC 3667, the only
* organization permitted to produce such derivative works would be
* ISOC/IETF.
*
* this is the way that its been since rfc 2026
*
* note that an rfc can be copied in full with no problems
* and that an author can give permission to
[EMAIL PROTECTED] (scott bradner) writes:
but according to RFC 3667, the only
organization permitted to produce such derivative works would be
ISOC/IETF.
this is the way that its been since rfc 2026
The 2026 copyright notice include:
This document and translations of it may be copied
) it is not generally granted
Fortunately, the copyright boiler plate in old RFCs are self
contained, and does not reference RFC 2026.
i.e. the rights under 3667 are the same as under 2026 its just stated
more clearly
Even if that is true, it would not change that the current copying
conditions
--On onsdag, oktober 06, 2004 23:52:15 +0200 Simon Josefsson
[EMAIL PROTECTED] wrote:
Even if that is true, it would not change that the current copying
conditions are a problem for the free software community, and in my
opinion, consequently the IETF.
this was something I did not see clearly
61 matches
Mail list logo
