In this case, sure, idk. I’ve had a project shut down because ffmpeg threatened law suits unless we open sourced our own custom libraries that work along side ffmpeg. And it’s not just the source code, they want full build environments. Our lawyers wouldn’t touch it, so we just shut it all down. Now I use gstreamer and avoid ffmpeg like the plague.
@CannonFodder@Neptr You were bundling LGPL source into your project. Their request was right, you were violating their license; if you had just used upstream FFmpeg by requiring systems to install it from the package i.e .deb dependency or downloading it directly from their releases and having their binary fully separate, you wouldn’t have had any pushback.
It was an embedded system. The user wouldn’t be able to download and install stuff, they just turn the thing on. The ffmpeg libraries were provided as is as separate files in the system.
If that’s their policy, ok. But it means we can’t use it in embedded systems.
It was an embedded system. The user wouldn’t be able to download and install stuff, they just turn the thing on.
As someone who likes to actually own and customise all my devices, devs like you are the bane of my existence. Read up on software licensing, and pay special attention to the history of its enforcement and what it enabled us. Then please reconsider your user hostile stance.
There’s a time and place, no? You buy a $30k video switcher with support, do you really want to fuck with the internals or just get the company to add/fix features you need. It’s impossible for the company to support you once you’ve fucked with the thing.
I understand open source - we use it and we contribute. But that doesn’t mean we can open source all our code. We have competitors who would abuse that. If no one can make a living selling code, then there will be no one to support open source.
@CannonFodder Policy? It’s the legal license you agreed to when you copied their code. It’s not like they rug pulled you; it’s open, and you should have read it before you even started. If you are commercial, look into FOSSA; you need an SCA for license compliance. Your way around this for LGPL was to make a fork and then compile the fork and use those compiled libraries if you needed airgapped. The moment anything touches that code, like if you static link all code that is touching it now needs to now be public too. If you dynamically link as long as the full code for that file is open you’re covered.
I’m actually baffled you didn’t even bother reading their license for a commercial product and chalked it up to they have some policy.
We switched to dynamic libraries, but they still wouldn’t let it go. It seemed a distinction without a difference, but we did it as we thought it would put us in the clear. And yes it should have, but little of this has actually been tested in court. So smaller companies can’t risk the huge legal cost, even if they know they’re in the right. So ffmpeg killed the project for no good reason - like I said: they’re assholes. And I don’t think forking it would have made any difference, the fork is still covered by the same license. The project was still just a prototype , but with ffmpeg’s harassment we dropped it and used something else for subsequent projects. When we actually touch open source code usefully, we always share it even if we never make a product that uses it.
Talk about blame shifting. FFmpeg didn’t kill the project. Your own negligence did.
It was an embedded system. The user wouldn’t be able to download and install stuff, they just turn the thing on. The ffmpeg libraries were provided as is as separate files in the system.
The LGPL (v2.1 and later which is relevant for FFmpeg) is very clear that when linking libraries, the recipient (user) must be able to relink after making changes to the library and recompiling it. How do you figure that this part of the license is compatible with an embedded system where the user would have no access to the software side, rendering the user unable to do said relinking? As long as the user would not be able to use a modified version of FFmpeg with your system, you are automatically not in compliance with the license. Your system couldn’t use any LGPL-licensed software, not restricted to FFmpeg, so this is completely on you.
We switched to dynamic libraries, but they still wouldn’t let it go. It seemed a distinction without a difference, but we did it as we thought it would put us in the clear. And yes it should have
No, it shouldn’t, and you would know that if you looked into the LGPL license.
Ffmpeg are kinda assholes and squelch innovation tbh.
In this case it was your own greed. When you decide you have to alter your product to be able to make a profit because you’re not allowed to ghoul on others’ free work, you can’t blame those who provide the software free of charge. They have absolutely no obligation to let you make a profit by not honoring the license of their own work.
Your reasoning is basically the same as the entire rotten-to-the-core AI industry: “if we need to honor the licenses of the works we use, we would never be able to make money!” Boo fuckin’ hoo.
Also, the irony of you claiming FFmpeg squelches innovation by making you honor the license, for a product where you would like to lock the user out from being able to make modifications is just… top notch. Innovation is only good when it suits your needs, apparently, not the end user.
The problem isn’t giving access to users, hell it’s just Linux on an sd card that they can fuck with all they like. But it’s supporting that. Getting all the stuff to work together requires a nightmare of version specifications and some ugly hacks. We can’t support that and our customers wouldn’t want it. By your description, using Linux in any embedded solution isn’t allowed.
So it was inconvenient for you, and that is somehow the FFmpeg squelching innovation? Grow up.
I only commented on you saying that switching to dynamic linking should be enough, which would not matter as long as you didn’t also make it possible for the user to relink a modified library if they wanted. That would be hard given your own description of users not being able to download or install anything on said system.
Not inconvenient, but impossible really. I get that most people don’t really understand embedded systems, but it’s a shame when innovation is blocked because of it.
@CannonFodder The switching of your linking afterward doesn’t change the requirement you violated and needed to comply with, which was to open source the code that touched it.
No, it wouldn’t and shouldn’t have just dropped all the required because you complied when caught; this is equivalent to saying you parked in a handicap spot and then, when asked, moved your car and said you expected not to get fined now and the police are harassing you for such.
I get the frustration, but I know as a business owner you wouldn’t sign a legal document without reading it or understanding what you’re setting yourself up for. Yet this seems to be exactly your process with software licenses. You need a Software Composition Analysis (SCA) if you do not have the time or the energy to read the licenses; this will prevent you from falling into the same hole.
PS: this has been heavily tried in court look at QT LPGL licensing enforcement cases this is a known license and known requirements.
In this case, sure, idk. I’ve had a project shut down because ffmpeg threatened law suits unless we open sourced our own custom libraries that work along side ffmpeg. And it’s not just the source code, they want full build environments. Our lawyers wouldn’t touch it, so we just shut it all down. Now I use gstreamer and avoid ffmpeg like the plague.
@CannonFodder @Neptr You were bundling LGPL source into your project. Their request was right, you were violating their license; if you had just used upstream FFmpeg by requiring systems to install it from the package i.e .deb dependency or downloading it directly from their releases and having their binary fully separate, you wouldn’t have had any pushback.
It was an embedded system. The user wouldn’t be able to download and install stuff, they just turn the thing on. The ffmpeg libraries were provided as is as separate files in the system.
If that’s their policy, ok. But it means we can’t use it in embedded systems.
As someone who likes to actually own and customise all my devices, devs like you are the bane of my existence. Read up on software licensing, and pay special attention to the history of its enforcement and what it enabled us. Then please reconsider your user hostile stance.
There’s a time and place, no? You buy a $30k video switcher with support, do you really want to fuck with the internals or just get the company to add/fix features you need. It’s impossible for the company to support you once you’ve fucked with the thing.
I understand open source - we use it and we contribute. But that doesn’t mean we can open source all our code. We have competitors who would abuse that. If no one can make a living selling code, then there will be no one to support open source.
@CannonFodder Policy? It’s the legal license you agreed to when you copied their code. It’s not like they rug pulled you; it’s open, and you should have read it before you even started. If you are commercial, look into FOSSA; you need an SCA for license compliance. Your way around this for LGPL was to make a fork and then compile the fork and use those compiled libraries if you needed airgapped. The moment anything touches that code, like if you static link all code that is touching it now needs to now be public too. If you dynamically link as long as the full code for that file is open you’re covered.
I’m actually baffled you didn’t even bother reading their license for a commercial product and chalked it up to they have some policy.
We switched to dynamic libraries, but they still wouldn’t let it go. It seemed a distinction without a difference, but we did it as we thought it would put us in the clear. And yes it should have, but little of this has actually been tested in court. So smaller companies can’t risk the huge legal cost, even if they know they’re in the right. So ffmpeg killed the project for no good reason - like I said: they’re assholes. And I don’t think forking it would have made any difference, the fork is still covered by the same license. The project was still just a prototype , but with ffmpeg’s harassment we dropped it and used something else for subsequent projects. When we actually touch open source code usefully, we always share it even if we never make a product that uses it.
Talk about blame shifting. FFmpeg didn’t kill the project. Your own negligence did.
The LGPL (v2.1 and later which is relevant for FFmpeg) is very clear that when linking libraries, the recipient (user) must be able to relink after making changes to the library and recompiling it. How do you figure that this part of the license is compatible with an embedded system where the user would have no access to the software side, rendering the user unable to do said relinking? As long as the user would not be able to use a modified version of FFmpeg with your system, you are automatically not in compliance with the license. Your system couldn’t use any LGPL-licensed software, not restricted to FFmpeg, so this is completely on you.
No, it shouldn’t, and you would know that if you looked into the LGPL license.
In this case it was your own greed. When you decide you have to alter your product to be able to make a profit because you’re not allowed to ghoul on others’ free work, you can’t blame those who provide the software free of charge. They have absolutely no obligation to let you make a profit by not honoring the license of their own work.
Your reasoning is basically the same as the entire rotten-to-the-core AI industry: “if we need to honor the licenses of the works we use, we would never be able to make money!” Boo fuckin’ hoo.
Also, the irony of you claiming FFmpeg squelches innovation by making you honor the license, for a product where you would like to lock the user out from being able to make modifications is just… top notch. Innovation is only good when it suits your needs, apparently, not the end user.
The problem isn’t giving access to users, hell it’s just Linux on an sd card that they can fuck with all they like. But it’s supporting that. Getting all the stuff to work together requires a nightmare of version specifications and some ugly hacks. We can’t support that and our customers wouldn’t want it. By your description, using Linux in any embedded solution isn’t allowed.
Embedded Linux is fine, just make it so if the owner wanted to they could hire any programmer to modify or update it
So it was inconvenient for you, and that is somehow the FFmpeg squelching innovation? Grow up.
I only commented on you saying that switching to dynamic linking should be enough, which would not matter as long as you didn’t also make it possible for the user to relink a modified library if they wanted. That would be hard given your own description of users not being able to download or install anything on said system.
Not inconvenient, but impossible really. I get that most people don’t really understand embedded systems, but it’s a shame when innovation is blocked because of it.
@CannonFodder The switching of your linking afterward doesn’t change the requirement you violated and needed to comply with, which was to open source the code that touched it.
No, it wouldn’t and shouldn’t have just dropped all the required because you complied when caught; this is equivalent to saying you parked in a handicap spot and then, when asked, moved your car and said you expected not to get fined now and the police are harassing you for such.
I get the frustration, but I know as a business owner you wouldn’t sign a legal document without reading it or understanding what you’re setting yourself up for. Yet this seems to be exactly your process with software licenses. You need a Software Composition Analysis (SCA) if you do not have the time or the energy to read the licenses; this will prevent you from falling into the same hole.
PS: this has been heavily tried in court look at QT LPGL licensing enforcement cases this is a known license and known requirements.
#foss #opensource #licensing