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

Reply via email to