| Summary: | net-im/teams-1.3.00.16851 no visible source code for LGPL-licensed ffmpeg | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ulrich Müller <ulm> |
| Component: | Current packages | Assignee: | Andreas K. Hüttel <dilfridge> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | licenses, sam, sultan, sven.eden |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Ulrich Müller
2020-07-10 11:26:28 UTC
Isn't LGPL that source code does *not* need to be included unless you link statically or change something in the sources? If you just wish to make sure that you a specific version is used (MS Teams crashes with newer ffmpeg or MESA EGL), and you provide that specific version without having modified the source code, it wouldn't make any sense to distrubute the sources anyway. At least that is how I interpret the Wikipedia article about the LGPL, the explanations of the Qt folks about their LGPL components, and the explanations here: http://answers.google.com/answers/threadview/id/439136.html Quote from Wikipedia: ----- The license allows developers and companies to use and integrate a software component released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components. However, any developer who modifies an LGPL-covered component is required to make their modified version available under the same LGPL license. For proprietary software, code under the LGPL is usually used in the form of a shared library, so that there is a clear separation between the proprietary and LGPL components. ----- Or in other terms: As long as it is an unmodified shared library, you can do what you want. They distribute the object code of the library, so they're bound by section 4 of the LGPL-2.1: 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. Good to know. And according to http://ffmpeg.org/legal.html you are absolutely right. As I am maintaining my own variation in my overlay, I'd like to know what we could do about that. I mean, other than filing a bug with Microsoft Teams or telling the ffmpeg folks to talk to them. Being the biggest provider of open source software, you'd think Microsoft knew better. Well, when the next version of ms teams arrives, I will again test it with unbundled ffmpeg and mesa libraries. So if that works (it doesn't currently), unbundling might become mandatory and everything is good, isn't it? The libffmpeg.so source code is shipped with chromium tarballs. Not sure if this is enough. (In reply to Stephan Hartmann from comment #4) > The libffmpeg.so source code is shipped with chromium tarballs. Not sure if > this is enough. net-im/teams is mirror restricted. So, we don't distribute the FFmpeg library (as part of Teams), and its license isn't an issue for us. The only question is if we want to endorse (to say it bluntly) Microsoft's piracy of FFmpeg. (In reply to Ulrich Müller from comment #5) > (In reply to Stephan Hartmann from comment #4) > > The libffmpeg.so source code is shipped with chromium tarballs. Not sure if > > this is enough. > > net-im/teams is mirror restricted. So, we don't distribute the FFmpeg > library (as part of Teams), and its license isn't an issue for us. > > The only question is if we want to endorse (to say it bluntly) Microsoft's > piracy of FFmpeg. EDONTCARE 1) it doesnt affect us (we dont distribute it, mirror restriction) 2) we are not the damaged party (that would be either ffmpeg upstream or chromium devs), so we can't do anything about it (In reply to Andreas K. Hüttel from comment #6) That's right, but OTOH we've removed other packages in the past for the same reason, see for example bug 507412 and bug 608954. Are we applying double standards? (Note that I'm _not_ suggesting to remove net-im/teams from the tree, but maybe this should at least be reported upstream?) |
