----- On Dec 2, 2019, at 9:48 PM, Primiano Tucci primiano@xxxxxxxxxx wrote: > On Mon, Dec 2, 2019 at 11:53 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Mon, 2 Dec 2019 18:45:14 -0500 > Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > >> >> I would love for that to happen but I don't develop Perfetto much. If I am >> writing a tool I will definitely give it a go from my side. CC'ing Perfetto's >> lead developer Primiano -- I believe you have already met Primiano at a >> conference before as he mentioned it to me that you guys met. I also believe >> this topic of using a common library was discussed before, but something >> about licensing came up. > > Oh hello again! > >> libtraceevent is under LGPL, is that an issue? > > Unfortunately yes, it is :/ > Our process for incorporating GPL or LGPL code makes Perfetto [1] (which is > Apache-2 licensed) problematic for us and recursively for other projects that > depend on us. > > For context, Perfetto is a cross-platform tracing project based on shmem and > protobuf, shipped on production devices and used by other app-developer-facing > tools (e.g. [6, 7]). It deals with both: > (1) pure userspace-to-userspace tracing (on all major OSs). > (2) kernel tracing via ftrace/tracefs (only on Linux/Android). > https://docs.perfetto.dev/ explains it a bit more. > > Today Perfetto is embedded and used both by Chrome [2] and Android platform [3]. > For both projects, pulling LGPL-licensed code is cumbersome process-wise: It > would require us to put mechanism in place to guarantee that the relevant LGPL > dependencies don't get accidentally linked in any production binary but only > used for the standalone offline tools to analyze traces. > Such process is unfortunately very expensive to setup and maintain for us and > for the projects that depend on us. > I don't want to start an ideological battle about licensing. To be clear, I > don't have any issues with LGPL, nor I think there's anything inherently > wrong with it. Just, it makes things too complicated when a smaller sub-project > like ours is embedded in larger projects. Just to clarify: my understanding is that a constraint that requires no dynamic linking of proprietary code on LGPL libraries does not seem to originate from restrictions based on the wording of the LGPL text. So it appears to be self-imposed either by your employer's (or your own) additional requirements, so not to bother dealing with the legal side of compliance, am I correct ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
