Thanks Mats. So I am listing here initial thoughts so far from me and Mats -
* Is it well documented in English.? * What problem does the 3rd party library solve? * is there any overlap with other parts of the codebase (either another external lib, or iotivity code itself). If so, why add a new player? Is there any plan to reduce such overlap over time? * is the plan to track specific versioned releases, or to follow a particular git commit, or other? [realize this may not be completely known up front] * what happens if we need changes to the new lib? Looking forward to hear more useful points to complete 1st list and add it to Wiki for upcoming new requirements. Regards Dwarka ---------------------------------------------------------------------------- ------ Software R&D Center | Software Strategy Team | Open Source Group Open Connectivity Foundation (OCF) | Iotivity | Javascript Foundation (JSF) -----Original Message----- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann Sent: Friday, August 25, 2017 11:49 PM To: iotivity-dev@lists.iotivity.org Subject: Re: [dev] Notes from the ISG meeting 2017-08-17 On 08/23/2017 11:40 PM, Dwarkaprasad Dayama wrote: > Hi IoTivity Dev Community, > > > > Few initial thoughts "We need a 3rd party library acceptance criteria" > - > > > > - Well documented in English. ? > > - Maximum permissive license. ? Needs level or specific options > that community prefer. > > - Security consideration? Needs more specific information. > > > > Additions / Modifications are most welcome. > > > > Since IoTivity is growing, this checklist getting ready earlier will > help contributors to decide right direction and avoiding any inconvenience. 3rd party libraries are essentially a "build vs buy" decision, so I'd expect to see the proposal document the decision. On the plus side, each high quality 3rd party lib is a chance to reduce the burden on the iotivity code base and maintenance - if the problem is already solved, why solve it again or spend the extra cycles? On the negative side, each 3rd party lib adds a new dependency to track, and possibly get stuck on: e.g. we are currently carrying not one, but two forks of libcoap, one of them very much out of date, the other one minor release out of date (a release which added DTLS support). It also adds complexity to certain build setups, though that's a problem we should be able to solve without penalizing people who want to choose a 3rd party lib. More separate projects also means more licenses for company legal departments to decide on, or at the very least to list on the BOMs. Also it's possible a new library may add unwanted code bulk (perhaps that's an iotivity-constrained concern) Questions, some maybe too nitpicky for the checklist: * What problem does the 3rd party library solve * is there any overlap with other parts of the codebase (either another external lib, or iotivity code itself). If so, why add a new player? Is there any plan to reduce such overlap over time? * is the plan to track specific versioned releases, or to follow a particular git commit, or other? [realize this may not be completely known up front] * what happens if we need changes to the new lib? === "Maximum permissive license"... I'm not sure we know what that is. Some people favor Apache because of the patent clause it has, and that is the choice for iotivity itself, but we don't require addon libraries to be limited to that license. I don't know if we have or need a list of licenses that are not okay. I've seen other projects have the discussion and it's always complicated... Cloud Native Computing Foundation has an easier path into the code for an Apache-2.0 licensed part than for other licenses; they're trying to negotiate with some projects to relicense (or dual-license) their code because while their chosen combination of terms might be similar in effect to Apache, they are less familiar and thus bring up legal review concerns. There are people who are far more knowledgeable about iotivity's stance on licenses I'm sure! _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
