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