Re: bettering open source involvement

Dave Taht <dave.taht@gmail.com> Wed, 03 August 2016 08:03 UTC

Return-Path: <dave.taht@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4812D142 for <ietf@ietfa.amsl.com>; Wed, 3 Aug 2016 01:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZY06GnFI-XO for <ietf@ietfa.amsl.com>; Wed, 3 Aug 2016 01:03:53 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C12A127078 for <ietf@ietf.org>; Wed, 3 Aug 2016 01:03:53 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id u186so292185316ita.0 for <ietf@ietf.org>; Wed, 03 Aug 2016 01:03:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F6l5ttFvansRTGYvTTEs4t4jlLWZhHu2moMugBVFTBM=; b=pDshAKP+iMoEZHhMpNlfdruGQgajBdQ6KVm65weRdFzHRTP2Chm5DFx/hh84cn78W2 KFo4luT5mJsNmwlSbAdCDbzp2re9zQNIx/eAu9xABY8ei+da+AjVN8WyUqVGtfpbkLlN JH85a9jjySEg6vzKNyyxeUcaRqYGRwwj7hn5nR97Br3UTrujrxizmcq8HCmZ4x8QK+KR EtJjyuUe5P88VjDDnyuCJ4236eM1fylUHGZE61Kadk0hPfdAlwxldUp7e2xtinCwakav UnWjPDjs5weGW+MzaczHWmS7AwYAmzNt+nz2x8DlwgBcBEyhEDLuQYvntW6mh3b/NSBi KYVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F6l5ttFvansRTGYvTTEs4t4jlLWZhHu2moMugBVFTBM=; b=JNMjaU8t60jz0mFnugQZUw8JfUlgdAtlxD9Kw4iDWLjWL80PyKNGTLPliD7xeaVFvY 6MFVZRLyGOIcb2cEDtQopDq8Phr2GASslTCdl8ZLH+w+8Y3uYx312nP4tQvmDnJp3+Ha hwlSIuT3au/1DlAGR2PXm3MWmXjxMnisEztZfxleKo9+9Yx+fudm+xvwmXgNVf5XniRC qu1nr57xxIZV6fUIcGNnkjOxCPOYC7qWl/7u320fSBk9WM+RbqregMcVfQk5Chl3pCKL 4Jt9PRivG7zpHOxiH6YQexXMonejQmahb/WEcinn/GB9QxW+Kkv3upCOkJR8fF2Y9V48 cGtw==
X-Gm-Message-State: AEkoouttcDuSl42FUsVYeRsPbS5C+O1JVC9qFqfgL/GZcV7WJNoOY7MN9qnOVKXr+bEXXZbYT2XDPBtD+CZ2NQ==
X-Received: by 10.36.64.5 with SMTP id n5mr23180898ita.78.1470211432827; Wed, 03 Aug 2016 01:03:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.14.17 with HTTP; Wed, 3 Aug 2016 01:03:51 -0700 (PDT)
In-Reply-To: <0a6e3a1a-1a4b-900e-0a07-e9843f32235f@gmail.com>
References: <CAA93jw71iUPb4vuFK5sMqo_CQEE9HSkchc9988=98FKUsv_1sw@mail.gmail.com> <579A6B76.70303@alvarezp.org> <ADB1E7FD-115C-40DF-97BA-618CFBB1C0EF@cable.comcast.com> <52FD39F9-6362-4C1D-BCCE-40A4DFC65EA0@netapp.com> <701c724f-efe2-6591-0378-12db4609adab@gmail.com> <28848.1470152567@obiwan.sandelman.ca> <0a6e3a1a-1a4b-900e-0a07-e9843f32235f@gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Wed, 3 Aug 2016 10:03:51 +0200
Message-ID: <CAA93jw6XJh_0HtEe_nkKXxT1_R7kq+zkuvqx4iOssMEQxJn0SA@mail.gmail.com>
Subject: Re: bettering open source involvement
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vpVFyNsEeZDt6kB-0fe4rFk1TdM>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2016 08:03:56 -0000

On Wed, Aug 3, 2016 at 2:55 AM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> On 03/08/2016 03:42, Michael Richardson wrote:
>>
>> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>     > 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.
>>
>> 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.

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
> 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.

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.

>
>> 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.

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. "

>     Brian
>
>>
>> *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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>>
>>
>



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