4 ms·
> Yes and no. The complaint is that some widely used extensions are proprietary. If these extensions require MS servers, then they have every reason to be. Even
by jcelerier 6y ago
> Yes and no. The complaint is that some widely used extensions are proprietary. If these extensions require MS servers, then they have every reason to be. Even if they don't, there's nothing wrong with a company holding back some stuff they consider strategic, they're not obligated to release them.
that is kinda debatable, considering that those are extensions to an LGPL-licensed core (Blink, the rendering engine used in electron) - see e.g. https://lists.gnu.org/archive/html/directory-discuss/2017-12/msg00008.html https://lists.gnu.org/archive/html/directory-discuss/2017-12...
- coldtea 6y agoBlink appears to has this license: https://chromium.googlesource.com/chromium/blink/+/109acd80bb94f76e2c140ed3bebcb304c26e9865/LICENSE https://chromium.googlesource.com/chromium/blink/+/109acd80b...
- jcelerier 6y agothis is the license of google's additions - this does not negate the license of individual source code files: https://chromium.googlesource.com/chromium/blink/+/109acd80bb94f76e2c140ed3bebcb304c26e9865/Source/core/html/HTMLBaseElement.h https://chromium.googlesource.com/chromium/blink/+/109acd80b...
- Jasper_ 6y agoThe LGPL parts here are dynamically linked, which is exactly what the LGPL was supposed to let you do.
- jcelerier 6y agothey definitely aren't. no libchromiumcontent.so to be seen anywhere. $ ls /opt/visual-studio-code/**/*.so /opt/visual-studio-code/libEGL.so /opt/visual-studio-code/libffmpeg.so /opt/visual-studio-code/libGLESv2.so /opt/visual-studio-code/swiftshader/libEGL.so /opt/visual-studio-code/swiftshader/libGLESv2.so /opt/visual-studio-code/swiftshader/libvk_swiftshader.so And running `strings` on the `code` binary obviously prints the name of classes covered by the LGPL.