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