Re: bettering open source involvement

[Dave Taht <[e-mail]>]

On Wed, Aug 3, 2016 at 2:55 AM, Brian E Carpenter
<[e-mail]> wrote:
> On 03/08/2016 03:42, Michael Richardson wrote:
>>
>> Brian E Carpenter <[e-mail]> 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 <[e-mail]>, 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