Subject: Re: bettering open source involvement

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 1 Aug 2016 13:42:23 +0000

On 7/28/16, 10:31 PM, "ietf on behalf of Melinda Shore" <[email-masked] on behalf of [email-masked]> wrote:
>  For one thing, we already have too much work.  

In which case, maybe the IETF or certain WGs or Areas are focused on the wrong work / wrong priorities?

> This is completely subjective but my own sense is that the #1 problem we have related to open source projects we take years
    to produce specifications.

I certainly agree with that; the pacing of work seems greatly out of step with what happens elsewhere in our tech community. I think this tends to seriously scare off people who would otherwise be interested in or benefit from participating at the IETF.

- Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 1 Aug 2016 13:44:15 +0000

It is an interesting question on how the IETF will evolve. For example, at Bits & Bites, my team demonstrated a measurement system called XMAP that is based on the emerging IETF LMAP standards. We intend to open source that software, and use some hackathons to improve it in the next year or so. As it stands now, we’ll either use our own public code repository or partner with another organization (that may also have things like an ability to accept funds to continue support of the effort). What if, in some future state, a given working group had a code repository and the working group was chartered not just with developing the standards but maintaining implementations of the code? 

Jason 

On 7/28/16, 4:30 PM, "ietf on behalf of Octavio Alvarez" <[email-masked] on behalf of [email-masked]> wrote:

    On 07/28/2016 01:56 AM, Dave Taht wrote:
    > At both ietf and BBF this past week a frequent topic of conversation
    > was how to get more open source involvement in standards orgs...
    
    Hi.
    
    Do you mean "how to get open source implementations of IETF standards"
    or "open source people gathered at IETF conferences" or something else?
    
    Thanks.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 1 Aug 2016 13:52:17 +0000

>  For one thing, we already have too much work.  
   
[JL] In which case, maybe the IETF or certain WGs or Areas are focused on the wrong work / wrong priorities?

[JL] I certainly agree with that; the pacing of work seems greatly out of step with what happens elsewhere in our tech community. I think this tends to seriously scare off people who would otherwise be interested in or benefit from participating at the IETF.
    
    - Jason

---

From: Alia Atlas <[email-masked]>
Date: Mon, 1 Aug 2016 10:04:18 -0400

On Mon, Aug 1, 2016 at 9:44 AM, Livingood, Jason <
[email-masked]> wrote:

> It is an interesting question on how the IETF will evolve. For example, at
> Bits & Bites, my team demonstrated a measurement system called XMAP that is
> based on the emerging IETF LMAP standards. We intend to open source that
> software, and use some hackathons to improve it in the next year or so. As
> it stands now, we’ll either use our own public code repository or partner
> with another organization (that may also have things like an ability to
> accept funds to continue support of the effort). What if, in some future
> state, a given working group had a code repository and the working group
> was chartered not just with developing the standards but maintaining
> implementations of the code?

Some WGs do already have github repositories that they use - and not just
for managing drafts.

I do think that there is a balance between what is ready for
standardization and what is still more experimental - but getting back to
having more experimental work that is backed by code could be helpful.

One concern would be keeping multiple implementations really happening and
also being clear on what are implementation choices versus interoperable
issues.

I think it is worth exploring more in this direction, while also
acknowledging that there is still and will continue to be a lot of
proprietary code that depends on IETF standards.

Regards,
Alia

> Jason
>
> On 7/28/16, 4:30 PM, "ietf on behalf of Octavio Alvarez" <
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 1 Aug 2016 10:06:25 -0400

While standards frequently take longer than we like, I would like to 
point out several other aspects.

One thing I have observed is that the rush to code often produces work 
that needs to be completely reworked.  As an example, in ODL the core 
adaptation layer had to be rewritten from scratch.
Rushing to produce a wrong standard can be rather more expensive.

On another angle, it often takes significant time to find all the issues 
and complications that affect the standard.  It takes thought and 
discussion.

And finally, the fact that we are trying to reach agreeement across 
people who often have very diverse implementations for very good reasons 
can create serious obstacle that take time and work to overcome.  This 
is actually particularly apparent in what should be easy to standardize, 
because those are cases where folks have pre-standard implementations 
and have often taken very different approaches.

One way of paraphrasing all of the above is that IETF standards take 
time because they matter.  It is easy to throw something out there, see 
if it works, and see if people want to use it.  It is not easy to get 
something put together that will work well when it is widely adopted.

Yours,
Joel

On 8/1/16 9:42 AM, Livingood, Jason wrote:
> On 7/28/16, 10:31 PM, "ietf on behalf of Melinda Shore"
> <[email-masked] on behalf of [email-masked]> wrote:
>> This is completely subjective but my own sense is that the #1
>> problem we have related to open source projects we take years
> I certainly agree with that; the pacing of work seems greatly out of
> step with what happens elsewhere in our tech community. I think this
> tends to seriously scare off people who would otherwise be interested
> in or benefit from participating at the IETF.
>
> - Jason
>
>
>
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Aug 2016 10:23:47 -0400

> On Aug 1, 2016, at 10:04 AM, Alia Atlas <[email-masked]> wrote:
> 
> One concern would be keeping multiple implementations really happening and also being clear on what are implementation choices versus interoperable issues.

Yes, let's not forget how hard it was to get alternatives for bind to break a very dangerous monoculture in DNS.

Paul

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 1 Aug 2016 14:36:35 +0000

Hi,

On 2016-08-01, at 15:44, Livingood, Jason <[email-masked]> wrote:
> What if, in some future state, a given working group had a code repository and the working group was chartered not just with developing the standards but maintaining implementations of the code?

as an addition to developing specs, that might be useful, if the spec remains the canonical standards output.

"Go read the code" is not a useful answer if the code comes under a license (such as GPL) that taints the developer. (This is a major reason what we are doing IETF specs for DCTCP and CUBIC - so that they can be implemented without needing to read Linux kernel code.)

Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Aug 2016 08:44:45 +1200

On 02/08/2016 02:36, Eggert, Lars wrote:
> "Go read the code" is not a useful answer if the code comes under a license (such as GPL) that taints the developer. 

This is a *very* important point. If an IETF WG sponsors code development, it needs to
be under an IETF-friendly licence. One way is to post it as an I-D. Another way is the
BSD 2-Clause "Simplified" or "FreeBSD" License. GPL is not a useful option.

   Brian

> (This is a major reason what we are doing IETF specs for DCTCP and CUBIC - so that they can be implemented without needing to
read Linux kernel code.)

---

From: joel jaeggli <[email-masked]>
Date: Mon, 1 Aug 2016 15:40:33 -0700

> BSD 2-Clause "Simplified" or "FreeBSD" License. GPL is not a useful option.

"IETF WG sponsors code development"

I'm not sure what this means, are you paying for a developer?

I certainly have opinions as to what terms I'm willing to accept on IPR,
patented or otherwise.

if it's a question of the inclusion of code in a working-group doc then
that's a question of consensus...

joel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Aug 2016 11:06:15 +1200

> I'm not sure what this means, are you paying for a developer?

No, "sponsor" does not automatically mean payment. One of the
Merriam-Webster meanings is "assumes responsibility for some other
person or thing."

> I certainly have opinions as to what terms I'm willing to accept on IPR,

Of course. But if you're in IETF-land, you've already accepted IETF rules.

> that's a question of consensus...

Correct. But if I include code in any old I-D, I'm automatically placing
it under the IETF Trust licence, which is simplified BSD. That's nothing
to do with consensus.

   Brian

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 2 Aug 2016 04:13:34 +0000

Coming back from vacation following IETF 96, I’m very happy to see this discussion and learn of the new [email-masked] list. I agree strongly with Melinda on the need for IETF participation in open source communities. The IETF hackathon has been pretty successful in terms of bringing open source communities to the IETF (e.g. OpenDaylight, OPNFV, ONOS, FD.io, RIOT, etc.). Its important to engage in the other direction as well. 
Regarding the concerns about time scales, I believe IETF work can keep pace such that it is relevant within open source projects. Working group drafts can and should be iterated along with open source code that implements/leverages these drafts.
I attended FOSDEM for the first time earlier this year. It would be great to see more IETFers there in 2017. There was a new “classroom” devoted to SDN and NFV in 2016 that I expect will be a part of the 2017 program as well. IETFers could provide valuable contributions there as I’m sure in many other areas as well. 

Cheers,
Charles

On 7/28/16, 10:34 AM, "ietf on behalf of Melinda Shore" <[email-masked] on behalf of [email-masked]> wrote:

>On 7/28/16 2:51 AM, Riccardo Bernardini wrote:
>> I have direct experience with FOSDEM (https://fosdem.org/2017/) that is
>> held every year end of January/beginning of February in Bruxelles.
>> Personally, I like it, I find it very active (~5000 participants/year)
>> and refreshing (after a year buzz-wording).  Joking I say that it looks
>> almost like IETF's incubator... :-) (the density of geeks per square
>> meter is similar :-)
>
>I think that if we wait for people to come to us, we'll be
>waiting for people to come to us.  I spoke a few months ago
>at PyCon US, and while it was specifically about getdns (an
>advanced DNS library) it was also an opportunity to talk about
>DNS privacy and security issues, and that mitigations are
>specified and available, along with ongoing work in the IETF.
>It was an extremely positive experience, highly recommended.
>Also, non-IETF hackathons are a good thing.
>
>Melinda
>

---

From: Dave Taht <[email-masked]>
Date: Tue, 2 Aug 2016 09:10:33 +0200

> "Go read the code" is not a useful answer if the code comes under a license (such as GPL) that taints the developer. (This is a major reason what we are doing IETF specs for DCTCP and CUBIC - so th…

Only 10 (?) years after full support for cubic entered the linux
kernel, and 3 after dctcp.

If you define the efforts of this standards body as one to produce BSD
licensed code (which is basically the case), it will continue to lag
behind the bleeding edge and continue to become more and more
irrelevant.

It's not just the deployed code in kernels that is a problem, it is
also that the best of the tools available to prototype new network
code are GPL'd. NS3, for example, is gpl.  The routing protocols
incorporated in bird and quagga are GPL. Bind is BSD, but nominum is
proprietary and dnsmasq, GPLd.

There is increasingly no place to design, develop, and test new stuff
without starting from a gpl base.

Worse, what happens here at ietf without use of these tools, is that
we end up with non-open-source code's experiments and results being
presented, without any means for an independent experimenter to
verify, reproduce, or extend.

I think it would do a lot of semantic good if the ietf would stop
referring to "open source"[1] and always refer directly to the
licenses under which the code it works on that are allowed. There are
certainly new areas of interest like npv, etc, that are proceeding
with more vendor-friendly code licensing schemes, although I am
dubious about the performance benefits of moving all this stuff into
userspace, particularly when a seeming, primary, goal is to avoid
making free software, rather than engineering a good, clean, correct
engineering solution.

It has been my hope that since the alice decision re patents (80% of
disputed software patents being invalidated), the rise of
organizations offering patent pool protections like the open
inventions network, and I think (IANAL), that apis cannot be
copyrighted in google vs oracle - ends up meaning that a developer can
not longer be polluted merely by looking at GPL'd code once in a
while. Because we do.

The actual implementations of anything for anything else will tend to
vary so much due to API differences, and the expressible logic in the
algorithms themselves generally simple, that, particularly when the
authors of the code have presented it for standardization, under any
license, that the exposure to further risk is minimized.

There are powerful advantages to the GPL (and LGPL[2]) over
"standardization". Notably there is an implicit patent grant, and
ongoing maintenance is enforced by an equal spirit of co-operation.
It's a better starting point than to hang with a sword of Damocles
over your head wondering if someone will patent something out from
under you.

I wish we could just get on with making the internet a better place.

> Lars

[1] The GPL is a considered an acceptable license under the terms of
the open source inititatives:

https://opensource.org/licenses/alphabetical

[2] Of all the open source licenses out there, I happen to like the
LGPLv2 the best. It is only viral if you make changes to the library.

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

---

From: Dave Taht <[email-masked]>
Date: Tue, 2 Aug 2016 09:37:54 +0200

On Thu, Jul 28, 2016 at 12:51 PM, Riccardo Bernardini
<[email-masked]> wrote:
>
>
> On Thu, Jul 28, 2016 at 10:56 AM, Dave Taht <[email-masked]> wrote:
>>
>> ... and one counter-thrust of mine has always been to get more
>> standards org members involved in open source, because that dialog has
>> to go both ways.
>>
>> I thought I would point at several useful upcoming conferences in the
>> hope that perhaps there would be some members of ietf/isoc "out there"
>> planning some outreach in this regard.
>>
>> https://www.linuxplumbersconf.org/2016/ proposals closed I think
>>
>> https://linux.conf.au/proposals/ CFP due aug 5
>>
>>
>> http://finance.yahoo.com/news/program-announced-embedded-linux-conference-130000509.html
>>
>> http://netdevconf.org/1.2/
>>
>> That is just the first 4 that came to mind, and they are respectively,
>> in america, australia, berlin, and japan. There are approximately 1
>> zillion other conferences in that world that an ietf/isoc/bbf/etc
>> member might find interesting, or have something of their org they'd
>> like to get in front of a wider audience.
>
>
> Just my 2.0e-2...
>
> I have direct experience with FOSDEM (https://fosdem.org/2017/) that is held
> every year end of January/beginning of February in Bruxelles.
> Personally, I like it, I find it very active (~5000 participants/year) and
> refreshing (after a year buzz-wording).  Joking I say that it looks almost
> like IETF's incubator... :-) (the density of geeks per square meter is
> similar :-)

The ratio of ietf participants to users and devices on the internet is
at an all-time low. The problems are swamping us all.

A joint meeting of many of the organizations concerned with the future
of the internet could fit into that room.

> The call for contribution has been opened just one week ago.
>
>
>>
>>
>> The best list I know of, is here:
>>
>> http://lwn.net/Calendar/
>>
>>
>> --
>> Dave Täht

---

From: Dave Taht <[email-masked]>
Date: Tue, 2 Aug 2016 09:51:18 +0200

> proprietary and dnsmasq, GPLd.

RIOT-OS, which is a leading contender for IoT stuff, is LGPL v2.1.

https://github.com/RIOT-OS/RIOT

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 2 Aug 2016 08:12:22 +0000

Hi,

> kernel, and 3 after dctcp.

The Linux community had chosen to actively ignore the IETF for about ten years. This only changed relatively recently.

And, FWIW, Hagen & friends' DCTCP implementation for Linux is based on the initial versions of our DCTCP I-D, and arguably wouldn't have happened without it.

CUBIC has of course existed in independent implementations before, but it is unclear if the BSD licensed ones were actually only done based on Injong's paper.

> behind the bleeding edge and continue to become more and more

I guess we're getting on our soap boxes at this point? :-)

But I don't define "the efforts of this standard body" in this way. I remain convinced that textual specs are required. Code is a nice addition, but really  only useful if it can be rather freely used - which GPL code can't.

> without starting from a gpl base.

I agree that this is a problem. But we can't all start to use GPL for everything.

> verify, reproduce, or extend.

That's a stretch. The alternative to GPL is not closed source. There are other, friendlier OSS licenses around.

> not longer be polluted merely by looking at GPL'd code once in a

As much as I want to agree, if you work for a commercial entity, the risk is just too great (cf. the GPL clause regarding implicit licenses to patents).

> license, that the exposure to further risk is minimized.

Sure. But the risk is incorporating code that may be GPL-tainted into non GPL'ed code bases. In other words, it's not the code itself that is a risk, it is a risk for the codebase it is used from.

> over your head wondering if someone will patent something out from

That's certainly one viewpoint.

Lars

> I wish we could just get on with making the internet a better place.

Sorry, but I really don't understand how this discussion is not trying to help with just that?

Lars

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 2 Aug 2016 09:56:10 +0100

Hi Lars,

While I agree that GPL clearly has issues for some IETF participants,
I think you overlstated a bit in one place...

On 02/08/16 09:12, Eggert, Lars wrote:
> Code is a nice addition, but really  only useful if it can be rather
> freely used - which GPL code can't.

GPL code can indeed be useful, even if it is problematic for some IETF
participants. For example, I put out some GPL'd code for a spec I was
developing. Much time passed (the RFC issued) but someone did pick up
on my code and improved upon it (hey, it was my code, so they probably
couldn't help but improve it:-). While working on the I-D the GPL code
was useful to me as an author, and I think also to folks for whom taking
a look at GPL'd code is not a problem, which was a non-zero set of
folks involved in the WG.

So yes, BSD is better in the IETF context, but GPL, while problematic
for some, is far from useless.

I would be supportive of efforts for us to try to ack other OSS licences
in IETF processes if we can figure a way to usefully do that. It may be
that code snippets in RFCs still need to be BSD, but that doesn't mean
we can't be happy to leverage code with any recognised OSS license.

Cheers,
S.

---

From: Riccardo Bernardini <[email-masked]>
Date: Tue, 2 Aug 2016 11:03:18 +0200

> for some, is far from useless.

+1
I would also add that GPL'ed code could provide  a second independent
implementation, useful to check for interoperability issues.

---

From: Dave Taht <[email-masked]>
Date: Tue, 2 Aug 2016 02:09:08 -0700

> The Linux community had chosen to actively ignore the IETF for about ten years. This only changed relatively recently.

As one of the people that have "led" that invasion, I did it in part
because I felt that over the past 16 years many standards processes
had become equivalent to GIGO, and I still believed in running code
and rough consensus, and had nowhere else to go. Finding more ways for
all to work together to bring spaceship earth in for a safe landing
has always been a goal of mine.

> CUBIC has of course existed in independent implementations before, but it is unclear if the BSD licensed ones were actually only done based on Injong's paper.

And cubic as it exists today in linux has continually evolved. I am
very grateful to google in particular for working within the ietf
standards process to make sure that many improvements to TCP in
general have been made public.

> I guess we're getting on our soap boxes at this point? :-)

Believe it or not I am deeply ambivalent about all the "open source"
license schemes. For code critical to public safety and privacy in
particular I have called for "public source", and standards for well
maintained code,  available for inspection by as many as need to look,
under any license, including "kill yourself after reading".

We'd discussed this point in a public videoconference (against the
backdrop of the vw emissions scandal and the fight with the fcc over
the wifi router lockdown) at length, here:

https://plus.google.com/107942175615993706558/posts/9may7aHjnqF

We can always keep doing stuff like that, engaging more sides in the
debates, in the hope that more light than heat emerges. Increasingly
governments and regulators want a say.

>
> But I don't define "the efforts of this standard body" in this way. I remain convinced that textual specs are required.

Given the complexity collapse and explosion in text size in
translating code to spec, and the slow progress by which an rfc can be
evolved, updated, or discarded, I am less and less convinced.

>Code is a nice addition, but really  only useful if it can be rather freely used - which GPL code can't.

The LGPL is also out? (I am not being sarcastic, I would merely like
the ietf to list their approved licensing schemes)

The effort to develop code that fits certain vendors' IP regime is
significant. I would support changes to the wg formation process that
were less vague than polling the room for "is there enough interest in
the room to do this". I would also like that all experiments' code at
least, that lead up to a standard's acceptance, be published. I have
lost endless months to dissecting papers and bad experiments - or
experiments where I merely wanted to change a few control variables
and re-run with my own data and tools.

For the record, flent is a GPLv3 *wrapper* around a multiple other
tools. It's GPLv3'd, in part, because we'd hoped to make sure that
experiments published with it, did not game the results in any way.
Using it does not "taint" anyone. Modifying the tests, does.

> I agree that this is a problem. But we can't all start to use GPL for everything.

Just as Apple found it necessary to invest in a BSD licensed compiler,
orgs that wish to have BSD licensed "open source" code that can
compete with GPL'd versions, need to invest in tools, tests, and
developers.

> That's a stretch. The alternative to GPL is not closed source. There are other, friendlier OSS licenses around.

And insufficient developers.

> As much as I want to agree, if you work for a commercial entity, the risk is just too great (cf. the GPL clause regarding implicit licenses to patents).

What can be done to reduce that risk? I already pointed to oin (both
google and cisco are part of it - there is now quite a large number of
members, actually:

http://www.openinventionnetwork.com/community-of-licensees/

> Sure. But the risk is incorporating code that may be GPL-tainted into non GPL'ed code bases. In other words, it's not the code itself that is a risk, it is a risk for the codebase it is used from.

You gotta rewrite it, so what? Copy/paste is a problem for all licenses.

> That's certainly one viewpoint.

Yep.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 02 Aug 2016 02:41:29 -0700

Hello,

For information about the facilitators experiment, please see
http://www.ietf.org/mail-archive/web/ietf/current/msg97290.html  This 
message contains a rough summary of the thread at 
https://www.ietf.org/mail-archive/web/ietf/current/msg99087.html

According to Mr Taht, a frequent topic of conversation during the 
last meeting was about how to get more open source involvement in 
standards orgs.  He mentioned several non-IETF conferences in the 
hope that some IETF participants would be interested in them.  There 
was a comment from Ms Woolf about DNS and open source.  Ms Shore 
commented that the IETF does not do APIs [1].  Mr Carpenter's 
response was that protocols without APIs are pretty much useless 
these days.  Mr Hammer commented about the speed at which IETF 
working groups move and the speed at which many open source projects 
move.  Mr Alvarez asked whether the discussion was about open source 
implementations of IETF standards or open source people gathered at 
IETF conferences.  Mr Livingood responded using what his team did at 
Bits & Bites as an example [2].  Ms Atlas commented that coming to an 
understanding of the perspectives of all those interested in the work 
can take time and discussion [3].  Mr
Zeeb commented about a RFC used by Mr Carpenter as an example and 
mentioned that it is a sad story [4].  He also started a different 
discussion about an open source model for publishing and obsoleting RFCs.

Mr Taht considers that standardizing something takes a lot of 
resources, a lot of different kinds of people, a lot of time, and a 
lot of things that should happen in parallel that end up happening in 
sequence and shared his thought about the concept of a "funded 
working group" [5].  There were a few comments about how long it 
takes to get a document published as a RFC in response to a comment 
from Mr Hammer about politics and religious wars stretching the 
time-to-publish to several years.  Mr Hammer also commented that, to 
some extent, IETF is driven by people who are paid by their 
organizations to be full time IETFers [6].  Ms Atlas does not think 
that there are that many people who are full time IETFers.  Mr Eggert 
mentioned an issue with code which comes with a license such as 
GPL.  Mr Carpenter commented about an IETF-friendly license if an 
IETF WG sponsors code development.  Mr Ewell commented that a spec 
must be expressed in prose, tables, formulas, pseudocode, flowcharts, 
ABNF, what have you, not in actual code in an actual programming 
language.  Mr Taht commented about the advantages to the GPL (and 
LGPL) over "standardization".  Mr Farrell agreed with Mr Eggert about 
GPL clearly having issues for some IETF participants, and argued that 
GPL is far from useless.  Mr Bernardini commented that  GPL'ed code 
could, as a second implementation, provide a useful check for interoperability.

Regards,
S. Moonesamy

1. https://www.ietf.org/mail-archive/web/ietf/current/msg99093.html
2. https://www.ietf.org/mail-archive/web/ietf/current/msg99134.html
3. https://www.ietf.org/mail-archive/web/ietf/current/msg99099.html
4. https://www.ietf.org/mail-archive/web/ietf/current/msg99101.html
5. https://www.ietf.org/mail-archive/web/ietf/current/msg99106.html
6. https://www.ietf.org/mail-archive/web/ietf/current/msg99109.html

---

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Aug 2016 12:50:47 +0300

On 2 Aug 2016, at 11:12 AM, Eggert, Lars <[email-masked]> wrote:

> But I don't define "the efforts of this standard body" in this way. I remain convinced that textual specs are required. Code is a nice addition, but really  only useful if it can be rather freely used - which GPL code can’t.

I’m going to join a few others in pushing back against this statement. FWIW I work for a closed-source vendor, so while I can copy BSD license code into my code-base, GPL (any flavor) is problematic. 

Still, I think any source code I can see is useful to me as an implementer. If I need to incorporate something into my code then either it’s really small (like a hash function) or I need to rewrite it anyway to fit. Either way I am likely to end up re-implementing quite a bit. Having a reference implementation is incredibly useful in getting my code to work correctly. 

Yoav

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 2 Aug 2016 14:37:25 +0000

>the ietf to list their approved licensing schemes)

Given the breadth of work done in the IETF, there is not going to be one license that is appropriate in all cases. Code to add support for a new RFC in the Linux Kernel would typically need to be GPL. Code to create a completely new implementation of some experimental draft might be best licensed with a BSD license. Code to add support for STIR to an existing open source SIP implementation would likely need to adopt the license of that open source project. Open source code could implement a protocol stack, mystack, or it could add support for a given protocol to something, perhaps using mystack. Perhaps the IETF can create some guidelines or have some folks who help with license education and selection, but the ultimately the choice of license will depend on the code contributors and what it is they are contributing, or contributing to. My feeling is that the IETF has the most impact when code is added to existing open source projects to support evolving IETF standards. Creating open source code in a vacuum to help people understand a draft and jumpstart their implementations involving that draft are of course great too.

Cheers,
Charles

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Aug 2016 10:46:53 -0400

The licensing discussion is really a distraction.   The GPL specifically
talks about fair use, and reading GPL code is not going to make you subject
to a lawsuit unless you copy it wholesale and claim ownership of the copy.

That you have seen a piece of GPL'd code that implements an IETF standard
does not mean you can never work on non-GPL software implementing that
standard again, any more than it would be the case that you'd be violating
a textbook author's copyright if you wrote some code based on an
understanding that you'd reached by reading the textbook.   That would make
going to college kind of a waste of time!

The utility of GPL code if you need non-GPL code is obviously an issue;
from that perspective, if somebody in the hackathon is working on GPL code,
and you want non-GPL code, then it would make sense for you to hack on a
different code base.   But this brain taint idea is nonsense, and there's a
lot of case law to back that up.

On Tue, Aug 2, 2016 at 10:37 AM, Charles Eckel (eckelcu) <[email-masked]>
wrote:

> >>>>> What if, in some future state, a given working group had a code
> repository and the working group was chartered not just with developing the
> standards but maintaining implementations of the code?
> >>>>
> >>>> "Go read the code" is not a useful answer if the code comes under a
> license (such as GPL) that taints the developer. (This is a major reason
> what we are doing IETF specs for DCTCP and CUBIC - so that they can be
> implemented without needing to read Linux kernel code.)
> >>>
> >> The Linux community had chosen to actively ignore the IETF for about
> ten years. This only changed relatively recently.
> >
> >> And, FWIW, Hagen & friends' DCTCP implementation for Linux is based on
> the initial versions of our DCTCP I-D, and arguably wouldn't have happened
> without it.
> >>
> >> CUBIC has of course existed in independent implementations before, but
> it is unclear if the BSD licensed ones were actually only done based on
> Injong's paper.
> >
> >> But I don't define "the efforts of this standard body" in this way. I
> remain convinced that textual specs are required.
> >
> Given the breadth of work done in the IETF, there is not going to be one
> license that is appropriate in all cases. Code to add support for a new RFC
> in the Linux Kernel would typically need to be GPL. Code to create a
> completely new implementation of some experimental draft might be best
> licensed with a BSD license. Code to add support for STIR to an existing
> open source SIP implementation would likely need to adopt the license of
> that open source project. Open source code could implement a protocol
> stack, mystack, or it could add support for a given protocol to something,
> perhaps using mystack. Perhaps the IETF can create some guidelines or have
> some folks who help with license education and selection, but the
> ultimately the choice of license will depend on the code contributors and
> what it is they are contributing, or contributing to. My feeling is that
> the IETF has the most impact when code is added to existing open source
> projects to support evolving IETF standards. Creating open source code in a
> vacuum to help people understand a draft and jumpstart their
> implementations involving that draft are of course great too.
>
> Cheers,
> Charles
>
> >
> >> That's a stretch. The alternative to GPL is not closed source. There
> are other, friendlier OSS licenses around.
> >
> >> As much as I want to agree, if you work for a commercial entity, the
> risk is just too great (cf. the GPL clause regarding implicit licenses to
> patents).
> >
> >> Sure. But the risk is incorporating code that may be GPL-tainted into
> non GPL'ed code bases. In other words, it's not the code itself that is a
> risk, it is a risk for the codebase it is used from.
> >

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Aug 2016 11:42:47 -0400

> BSD 2-Clause "Simplified" or "FreeBSD" License. GPL is not a useful

GPL is not useful for **some** companies that want to exploit the code directly.
There are a number of advantages otherwise to GPL.

*One* of them is that it becomes very clear to the IETF when patent claims on
the protocol are incompatible with the GPL.

The other major advantage has to do with how and when patches get contributed
back to the system over time if the code turns out to be more than an
existence proof.

    >> (This is a major reason what we are doing IETF specs for DCTCP and
    >> CUBIC - so that they can be implemented without needing to
    >> read Linux kernel code.)

Aside from the white-room issue of reading source code, the code doesn't
explain to how deal with corner cases that the coders didn't consider.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Aug 2016 12:55:08 +1200

> GPL is not useful for **some** companies that want to exploit the code directly.

It's significantly worse than that. Companies that have already been sued over
such matters will *not* allow employees who have studied GPL code to discuss
details with employees who are not "contaminated" in that way. The boundary
between fair use and plagiarism is not clear cut. If code that closely resembles
GPL code shows up under sub poena in a non-GPLed product, anything can happen
in court. So the company lawyers makes sure that never happens.

> There are a number of advantages otherwise to GPL.

There are. But if the IETF wants to encourage code that anybody can study
and/or borrow, GPL is not the way to go.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Wed, 03 Aug 2016 11:05:02 +0900

> There are. But if the IETF wants to encourage code that anybody can
> study and/or borrow, GPL is not the way to go.

gpl would be good for adding a poison pill to an implementation a la
ipr on a draft.

randy

---

From: Dave Taht <[email-masked]>
Date: Wed, 3 Aug 2016 10:03:51 +0200

On Wed, Aug 3, 2016 at 2:55 AM, Brian E Carpenter
<[email-masked]> wrote:
> details with employees who are not "contaminated" in that way.

Companies have been sued for making too hot coffee. companies that
make software (:cough: vw) that intentionally violates regulations are
slapped with heavy fines. I don't know how many people the business
software alliance sues over license violations but I suspect it's one
hell of a lot more that have GPL issues.

The usual negotiated end to a GPL compliance lawsuit (not that there
are many, anymore) is a gpl compliance program. Companies such as
black duck make tools to help companies evaluate their exposures.

> The boundary

Which company's lawyers? What percentage of the members of the ietf
still have such policies?

This would be a useful poll to have more details than just percentages
on, as the landscape has shifted, just as it has over software
patents. Identifying how multiple companies are *now* dealing
internally with open source issues, in terms of employee contracts and
policies,  would be nice.

(I had a friend from AT&T tell me last week, proudly! about how the
release of their gigantic new open source codebase - had also led to a
clearcut all-company employee open source contribution policy. I said!
"Great!" Could I read it?" - and the answer was, "no". Irony.)

Every company I've been (self biased sample) in the last decade have a
clear policy. Google's is particularly straightforward.

> and/or borrow, GPL is not the way to go.

I don't think the "study" argument flies anymore. It's akin to banning
a doctor from reading "one flew over the cookoos nest".

The "borrow", may.. Who is "the ietf" in this case? Certainly anyone
willing to start a codebase and complete it in the process of
producing a standard can roll whatever license they want most
compatible with the standard's intent.

Still the process of getting to running code and rough consensus is
hampered by the BSD requirement, particularly when we have to stand on
the shoulders of giants to do something new. I think conflating the
license under which a piece of code is written with the intent of the
owner/authors of that code towards standardization, is a key problem
here.

Perhaps the IPR disclosure process (currently for patents only), could
have something like: "The *authors* of this draft hereby give
permission to copy the referenced GPL licensed code files, of which we
are the *authors*, also, to any and all comers, under the terms of the
IETF approved licenses".

Or a disclaimer at the head of the draft: "This draft contains
references to GPL'd codebases as an implementation aid. "

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 3 Aug 2016 09:06:34 +0100

Hi Brian,

> study and/or borrow, GPL is not the way to go.

I agree that BSD better suits the IETF, and hence is worth encouraging.

However, recognising the reality of GPL, and that it is not problematic
for all IETF participants is also well worth doing. (The same goes for
other recognised OSS licenses.)

That said, I'm not sure we have a concrete proposal for a thing to do.
If someone has one, I'd be happy to try help see if that can be moved
forward. (Probably best done initially offlist)

Cheers,
S.

---

From: Randy Bush <[email-masked]>
Date: Wed, 03 Aug 2016 17:15:13 +0900

> That said, I'm not sure we have a concrete proposal for a thing to do.

if you write a draft and have running example code, you are accused to
be just coming to the ietf for a rubber stamp (cf. sidr).  if you have a
draft and no code, idiots such as i comment that the rubber meets the
sky.  if you have code but no draft, you're a undisciplined hacker,
unless we're in an even numbered year where we're trying to snuggle up
to code.

imiho, we would benefit from making it easier to come in with a draft
and code, the first above.

randy

---

From: Philip Homburg <[email-masked]>
Date: Wed, 03 Aug 2016 11:10:45 +0200

>a doctor from reading "one flew over the cookoos nest".

With all the discussion about code, I'm much more interested in good APIs.

I think the advanced socket API for IPv6 is one that works really well.

More recently, getdns defines for the first time a sensible API for DNS.
(A bit verbose if you write C, but certainly at the right level of
abstraction).

For APIs, you'd like to have at least two compatible implementations of a
single API. So if one of those is GPL and the other BSD, there is no
licensing issue.

There may be other uses for code, for example to illustrate a complex
algorithm. But the one thing I miss most are well defined APIs.

---

From: Dave Taht <[email-masked]>
Date: Wed, 3 Aug 2016 11:33:08 +0200

>>a doctor from reading "one flew over the cookoos nest".

Or a barber from watching "sweeny todd".

> I think the advanced socket API for IPv6 is one that works really well.

I am still in search of common, simple means, to access and change the
ecn related bits in the IP header, particularly for udp packets. The
"standard" for doing such is varied, actually getting at the bits per
packet (for OSes that can do it) requires the cmsg facility.

> (A bit verbose if you write C, but certainly at the right level of

That is awesome!

https://getdnsapi.net/spec.html

Thank you for bringing it to my attention. Their proposed standard has
a few problems - no mdns support for one - and a codebase issue
(openssl dependency primarily), but it is otherwise looking like a
vast improvement on older dns apis.

> algorithm. But the one thing I miss most are well defined APIs.

+10

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Aug 2016 12:43:05 -0400

> gpl would be good for adding a poison pill to an implementation a la

And yet, we get poison pill IPR all the time, and we don't seem to care.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Aug 2016 12:46:07 -0400

> and code, the first above.

+5.

And make it easier to do:
    1) Informational on running code.
    2) Spin to 2.0 for Standards Track.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Aug 2016 14:55:35 -0400

> On Aug 3, 2016, at 4:15 AM, Randy Bush <[email-masked]> wrote:
> 
> be just coming to the ietf for a rubber stamp (cf. sidr).

The Postfix code for DANE in SMTP was developed in parallel with the early
drafts of RFC767[12].  I don't recall any "rubber stamp" objections.  Perhaps
that was an exception, but at least that objection is not universal.

Work on the Postfix code began in Mar/2013 and on the new drafts in May/2013.
Stable code in Postfix 2.11 was released in Jan/2014, and the RFCs were finally
published in Oct/2015.

-- 
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Aug 2016 15:21:40 -0400

Rubber stamp objections generally come when there are two competing
implementations of different standards that do roughly the same thing, or
when someone brings a standard to the IETF that has issues, but they're
hoping to get the IETF to publish it as an RFC without having change
control.   Neither is a particularly sympathetic situation.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Aug 2016 10:56:27 +1200

>     1) Informational on running code.

That is IMHO one of the main attractions of the Independent Submission RFC Stream.

(Full disclosure: I'm a member of the Independent Submission Editorial Board.)

   Brian

---

From: [email-masked]
Date: Sat, 06 Aug 2016 12:29:39 -0700 (PDT)

> Stable code in Postfix 2.11 was released in Jan/2014, and the RFCs were finally

Going way back, there were at least three implementations, two by two of the
specification coauthors, developed in parallel with the MIME specification. 

Since then I've always tried to code in parallel with the specifications I'm
involved with.

None of this was in any way secret - in fact I've often stated that my position
on such-and-such was the result of implementation experience - and I don't
recall ever getting any flak for it.

Hopefully this experience isn't unique to email protocols.

				Ned

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 8 Aug 2016 07:43:13 +0200

I've heard people objecting to clear *improvements* in a protocol on the
basis that their less capable variant is already deployed in the field,
and it's too much work to update.

Sometimes that's just a fact; at other times, it elicits the
"rubberstamp" argument.