Hi,
Please see inline.
Stephan
On 1.12.2013 10:32 , "Stephen Farrell"
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
Hiya,
On 01/11/2013 09:02 PM, Stephan Wenger wrote:
[...]
Still, there is one reference that worries me, and that is the
reference
to GPLv3 code as an "extreme" in section 2.1. Yes, the GPL (and similar
copyleft licenses) is an extreme, at least in terms of open source
licensing models. However, it is not an extreme of openness or
accessibility of the source code for review by WG chair, AD, and
community. I would hope that we are all aware that many (most?)
commercial software developers, by company policy or common sense, avoid
looking at GPL-ed code, out of fear of contamination of their own closed
source code.
<rant>
I am aware that lawyers and others do encourage ignorance in such
ways. Its an incredibly stupid way to behave IMO even if understandable
in a horrendously short-sighted kind of way.
I understand that this is a rant. And, I'm not ranting back, even if
tempted. Well, maybe a little. That said, I would like to understand the
"ignorance" part.
It is factually true that there is a risk of contamination, and a risk of
being required to publish formerly closed source code under a very onerous
license (patent rights, whatnot) when a developer exposes himself/herself
to GPLed code. I'm not including citation showing this at this point
(call it time and space constraints, and off-topic--but it's easy enough
to do), but the logic is approximately: copyleft licenses require to grant
back derivative work in source code form, and inclusion of GPLed code
fragments into your source code can be viewed as derivative work.
Publishing source code can (and in most cases, is) not a strategy closed
source companies follow.
If a Free Software developer, probably with the help of folks like the
SFLC, sue your company over alleged creation of derivative work from GPLed
code without granting that source code back, you need to defend yourself,
or publish the code under the GPL with all its onerous conditions (again,
patent license and whatnot). Whether fair use, de minimis, or similar
theories apply for a specific case depends on the amount of included GPLed
code, legislation, the quality of your lawyer and the one on the other
side, and so on. In most cases of accidental contamination, it is IMO
likely that you get of the hook easily enough, and even more likely that
no one is suing you. Still, even the smallest legal action is costly.
For this reason, in most closed source companies I'm aware off, GPLed code
is off-limits for developers and/or for all employees, perhaps minus those
folks in the IT department which are not involved in product development
but deal with production servers and such. It's common business sense.
It's OK if you don't like that business model. It's ok if you like "Free
Software" and its business model. Form a religion about the so-called
"Free Software" model, for all I care. (Oh wait, there is already one :-)
However, I do not believe that your draft, and especially the section in
question, is the right place to do so.
[...]
</rant>
GPL-ed code is, therefore, inaccessible for verification by
a large part of the IETF community, and does not serve as a good example
for "openness", which is how I interpret the spectrum laid out in
section
2.1. A better example would be source code that is almost universally
accessible. The extreme here would be source code in the public domain.
Somewhat less convincing but perhaps a bit more realistically, source
code
under a BSD-style license like the one the IETF Trust is using.
I'm not at all sure what concrete suggestion you're making, other
than disparaging GPL. If your suggestion is s/GPLv3/BSD license/
then that could be done but would make no difference at all to
this draft, so I plan to leave this as-is.
Yes, I'm arguing in favor of replacing "GPL" with "BSD", or, even better,
with "public domain". To rephrase the reason for it: ideally, in order to
verify "matching" between software and specification, the software would
need to be accessible to as many people (in practice: IETF participants)
as possible. One extreme is correctly identified: closed source code is,
in almost all cases, accessible only to a very small group of people. The
other extreme is "public domain" source code, where no reasonable lawyer
or business guy has a reason to tell their developers to not touch it.
BSD licensed code comes close, and is more common.
The GPLed code is not at one of the extremes, but middle ground. I would
wager a guess that perhaps less than half of the IETF participants are
allowed to check GPLed code for something as business-uncritical as
fast-tracking a draft. Therefore, GPLed code should not be an example for
universally accessible and verifiable code.
Clearer? Please reconsider your position.
Second, the draft suggest that the existence of an implementation of the
specification should serve as a shortcut towards RFC, presumably because
such an implementation speak favorably to the implementability of the
specification. That, however, is not universally true.
Very few things in the IETF are universally true;-)
Specifically, if
implementer and spec writer are the same person (or part of the same
team), it is quite likely that the spec takes certain assumptions made
by
the implementers for granted, and does not document it. That would be a
bad spec, accessible implementation or not. The solution to this issue
is
IMO not, as the draft appears to be to suggest, to put burden on WG
chairs
and ADs to ensure that the spec and the implementation match. Both WG
chairs and ADs have enough to do, and the incentive for rubber-stamping
is
quite high. A more sensible solution may be to require that the
implementer is unaffiliated with the spec author; in other words, the
implementation is derived from the spec + IETF discussion context.
That's a fair point but, a) we don't consider affiliations like that
in the IETF, at least not in a written-rules kind of way,
"Affiliation" was not meant as "same employer". Clearly, same team in the
same company is a problem. Co-developer in the same (small) open source
project is a problem. US-based Office of CTO full-time standardizer (of
which the IETF has a fair share, we may like it or not) and code-grunts in
China are IMO not a problem, even if they work for the same mega-company.
There may be a better word than "affiliated" to describe this
relationship. That word escapes me, though. (Standard excuse: not an
English native speaker.)
and b) there's
nothing in principle wrong with the editor writing code.
For the purpose of short-cutting an approval mechanism (and only in this
context), I disagree, for the reasons already mentioned. Outside of that
context, I'm fully with you, and I wish there would be more of those
multi-purpose types.
While it
is better if the code is written independent of the editor and even
better if someone who hasn't been involved in the WG has done the
coding, that'd be too high a burden to require IMO, especially given
that this is an experiment.
Ack.
I'd have no problem adding text that encouraged some form of
independence though, if you'd like to provide some.
How about:
"If the source code has been developed independently of the authoring of
the draft (and ideally by non WG participants), it is likely that the
implementation and the draft match, and that pitfalls unaware developers
may find have been found and dealt with. If, on the other hand, draft
author(s) and implementation developer(s) overlap, then it is sensible to
scrutinize the draft more closely, both with respect to its match with the
implementation and for assumptions that author/developer may have taken
for granted which warrant documentation in the draft."
A third comment would be that, if you interpret the draft strictly, it
is
highly unlikely that the experiment would ever be exercised, as the
implementation needs to "match" the draft to be advanced, and that would
mean that the implementation has to follow in lockstep with the draft
development up until the final version. With respect to the core
subject
matter of a draft, that may be fine. However, many of the final edits
in
a draft come as input from IETF wide community review; things like
security, congestion control, and the like. Those are often trivial to
write down, but can have a major implementation impact. To cure this,
it
would IMO be acceptable if the implementation would be required to match
the latest or a reasonably young, i.e. a few months old version of the
draft.
Another fair point but again one where its not really possible to
describe a rule that'd be better and more precise than "match."
I don't think a rule mentioning earlier or older drafts would be
useful for this.
I'll see if I can come up with something better than "match" but
if you have text to suggest, that might help.
Trying:
"Match means that all, or substantially all, protocol mechanisms of the
draft are implemented, that no other code points are implemented that
would reasonably fall into the scope of the draft in question, that all
documented state machines are implemented and no other state machines, and
so forth. The over-the-wire behavior of the implementation and of the
draft should substantially match, including more subtle points such as
timing relationship of messages, . Minor divergences in details stemming
from unaligned development cycles of draft and implementation are
acceptable."
Cheers,
S.
Please consider this.
Thanks,
Stephan
On 1.11.2013 08:21 , "Adrian Farrel" <adrian(_at_)olddog(_dot_)co(_dot_)uk>
wrote:
Hi Alexa,
Please be aware of this document that has just entered a four-week IETF
last
call. The document describes a proposed IETF process experiment under
the
rules
of RFC 3933.
The proposed experiment calls on the IETF Secretariat to take specific
actions
under certain circumstances in corner cases of the experiment. Could
you
please
have someone in the Secretariat look at the draft and comment on the
practicalities of the actions. Note that, at this stage, no changes to
the tools
are proposed so any actions would require manual intervention (if the
experiment
were successful and resulted in permanent changes to IETF process we
might make
changes to the tools at some future time).
Thanks,
Adrian
-----Original Message-----
From: ietf-announce-bounces(_at_)ietf(_dot_)org [mailto:ietf-announce-
bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: 11 January 2013 15:15
To: IETF-Announce
Subject: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC
with
Running
Code) to Experimental RFC
The IESG has received a request from an individual submitter to
consider
the following document:
- 'A Fast-Track way to RFC with Running Code'
<draft-farrell-ft-03.txt> as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-02-08. Exceptionally,
comments may
be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This memo describes an optional, fast-track way to progress a
working
group document to IESG review. It is provided as a process
experiment as defined in RFC 3933 for use when working group chairs
believe that there is running code that implements a working group
Internet-Draft. The motivation is to have the IETF process
explicitly consider running code, consistent with the IETF's
overall
philosophy of running code and rough consensus.
In this process all of working group last call, IETF last call, and
Area Director review are carried out in the same two week period.
Only comments that meet IESG Discuss criteria need to be addressed
during this stage, and authors are required to make any changes
within two weeks.
This experiment will run for one year.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-farrell-ft/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-farrell-ft/ballot/
No IPR declarations have been submitted directly on this I-D.