We have a *tentative* slot assignment for Wednesday 1520-1720. Agenda items will follow shortly. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Steven M. Bellovin wrote:
> We have a *tentative* slot assignment for Wednesday 1520-1720. Agenda
> items will follow shortly.
Note that we expect a major agenda item to be the revision of
draft-ietf-ipr-outbound-rights, which has been submitted to the I-D
repository, but not yet published.
Harald
It would be useful to have the WG discuss whether it wish to adopt: http://www.ietf.org/internet-drafts/draft-josefsson-ipr-notices-00.txt Pending a more clear view of the IETF consensus on that issue, RFC 3548bis (RFC4648) is somewhat stuck in AUTH48. The running code seems to differ from the policy here. Thanks, Simon
At 12:11 PM +0200 10/4/06, Simon Josefsson wrote: >It would be useful to have the WG discuss whether it wish to adopt: > >http://www.ietf.org/internet-drafts/draft-josefsson-ipr-notices-00.txt > >Pending a more clear view of the IETF consensus on that issue, RFC >3548bis (RFC4648) is somewhat stuck in AUTH48. > >The running code seems to differ from the policy here. > >Thanks, >Simon I agree with Simon's request, and I'd actually like to see if we can get close to WG agreement on a way forward. If we cannot, the only way to get the full functionality of 3548bis is going to be remove the LGPL-ed code and replace it with a pointer to a non-RFC place where it is maintained. That has a list of problems we're all familiar with, and I'd rather get clear answers to the base problem. thanks, Ted
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Intellectual Property Rights Working Group of the IETF. Title : Advice to the IAOC on Rights to be Granted in IETF Documents Author(s) : J. Halpern Filename : draft-ietf-ipr-outbound-rights-01.txt Pages : 8 Date : 2006-10-4 The IASA is resposible for managing intellectual property rights on behalf of the IETF. This includes the license to copy, implement and otherwise use IETF contributions, among them Internet-Drafts and RFCs. The IASA accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF contributions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipr-outbound-rights-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipr-outbound-rights-01.txt".(Continue reading)
I doubt it fully solves the problems, but section 5.5 of the outbound draft does address this. Yours, Joel Halpern At 02:45 PM 10/4/2006, Ted Hardie wrote: >At 12:11 PM +0200 10/4/06, Simon Josefsson wrote: > >It would be useful to have the WG discuss whether it wish to adopt: > > > >http://www.ietf.org/internet-drafts/draft-josefsson-ipr-notices-00.txt > > > >Pending a more clear view of the IETF consensus on that issue, RFC > >3548bis (RFC4648) is somewhat stuck in AUTH48. > > > >The running code seems to differ from the policy here. > > > >Thanks, > >Simon > >I agree with Simon's request, and I'd actually like to see if we can get >close to WG agreement on a way forward. If we cannot, the only way >to get the full functionality of 3548bis is going to be remove the LGPL-ed >code and replace it with a pointer to a non-RFC place where it is maintained. >That has a list of problems we're all familiar with, and I'd rather get clear >answers to the base problem. > thanks, > Ted > >_______________________________________________ >Ipr-wg mailing list(Continue reading)
Section 5.5 of your document seem to discuss this topic, but it does not solve the problem. One problem is that free software licenses are poorly understood by this WG. In particular, your section 5.3 and 5.5 work against each other. To be applicable for inclusion in a free software product, which is something your section 5.3 claim is something we want to permit, the work need to have a clear license. Organizations and companies, such as Debian, review the license for works that are candidates for being included in their distributions. If the license is not clear, the work cannot be included. Most, if not all, internationally valid licenses are based on copyright. The licenses typically require that the copyright notice is present and preserved. Compare the BSD license: http://www.opensource.org/licenses/bsd-license.php Redistributions of source code must retain the above copyright --------- notice, this list of conditions and the following disclaimer. Compare the GPL: http://www.opensource.org/licenses/gpl-license.php 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you(Continue reading)
Simon Josefsson wrote: > Section 5.5 of your document seem to discuss this topic, but it does not > solve the problem. > > One problem is that free software licenses are poorly understood by this > WG. In particular, your section 5.3 and 5.5 work against each other. > > To be applicable for inclusion in a free software product, which is > something your section 5.3 claim is something we want to permit, the > work need to have a clear license. > > Organizations and companies, such as Debian, review the license for > works that are candidates for being included in their distributions. If > the license is not clear, the work cannot be included. > > Most, if not all, internationally valid licenses are based on copyright. > The licenses typically require that the copyright notice is present and > preserved. Changing the subject line, since this needs to be discussed on the list (Simon won't be in San Diego, and we need to discuss it on the list anyway). I think the thrust of -outgoing is that there needs to be legal language crafted to achieve the desired effect; I think such legal language will have at least 2 components: - The actual license from the IETF to whoever uses the documents - The way in which other rights are acknowledged or referenced The "additional difficulties" that 5.5 refers to are, I think, the difficulty of making sure in a way that is acceptable to IETF(Continue reading)
> The GPL is a good example, because I think the IETF will have problems > claiming that software licensed *only* under the GPL conforms to the > desire that "anyone can use them" in section 5.3; people who refuse to > use code that is under "viral" licensing terms will not be able to use it. > > So something in an RFC that is marked as > > this code sample copyright (c) Simon. All rights reserved. Available > under the GPL > > is not acceptable under 5.3 (I think - more opinions wanted), while > > this code sample copyright (c) Simon. All rights reserved. > Available under the GPL and under the IETF licensing regime defined in > RFC XXXX > > would be - once all we're talking about here is finished. Again - I > think. Not sure. > > Thoughts? I believe some code is always better than no code in an RFC. Code helps people get things done, which leads to a better Internet. Even if you can't use the code in your products, you can at least read it and use it internally for interop testing. For example, the MD5 code in RFC 1321 has a license that makes it difficult to use in many products. (Few products use that code today.) Not everyone wants to print "derived from the RSA Data Security, Inc.(Continue reading)
> > Finally, I think section 5.3 is wrong to imply that "everyone can use > the code" is a required goal. It is certainly a good goal, but > sometimes the only options are to either not include code at all, or > include code with a license that results in not everyone being able to > use it. In those situations, I think the choice is simple. > That seems like a good basis for updating 5.3 - after all, we're trying to document what we want to accomplish....
RSS Feed19 | |
|---|---|
3 | |
2 | |
1 | |
3 | |
2 | |
10 | |
4 | |
1 | |
68 | |
35 | |
1 | |
4 | |
1 | |
7 | |
15 | |
5 | |
8 | |
30 | |
12 | |
6 | |
3 | |
15 | |
21 | |
71 | |
43 | |
128 | |
37 | |
1 | |
21 | |
28 | |
39 | |
22 | |
101 | |
139 | |
71 | |
8 | |
27 | |
85 | |
30 | |
54 | |
73 | |
135 | |
6 | |
113 | |
85 | |
32 | |
80 | |
6 | |
43 | |
124 | |
111 | |
117 | |
115 | |
177 | |
54 | |
166 | |
72 | |
266 | |
131 | |
1 | |
28 | |
1 | |
20 | |
194 | |
86 | |
113 | |
21 | |
18 | |
10 | |
1 | |
3 | |
4 | |
31 | |
29 | |
6 | |
10 | |
4 | |
41 | |
2 | |
9 | |
157 | |
91 | |
282 | |
100 | |
230 | |
481 | |
347 | |
4 | |
19 | |
133 | |
44 | |
9 | |
3 | |
55 | |
51 |
