From what I understood here, if I compile with the flag --enable-gpl, ffmpeg can be added in a commercial product.
In the recipe, there is: PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl"
Thus, I created a ffmpeg_%.bbappend containing:
PACKAGECONFIG_append ="gpl"
But it seems I still have to put a value in LICENSE_FLAGS_WHITELIST, most likely commercial. Is it a mistake from me or is it not handled properly by the main recipe?
Thanks
No, it's not a mistake.
The PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl" just adds a way to enable/disable building GPL-licensed parts of ffmpeg. It has nothing to do with whether you can use the result in a commercial product.
By setting LICENSE_FLAGS_WHITELIST_append = " commercial_ffmpeg", you're telling the buildsystem that you're allowed to build and use ffmpeg. That can be due to you having acquired a commercial license (or licenses), that you'r in a jurisdiction where you don't need commercial license(s), etc...
Note that in this case, these two PACKAGECONFIG[gpl] and LICENSE_FLAGS_WHITELIST are orthogonal, they have nothing with each other to do.
The LICENSE_FLAGS_WHITELIST is there to protect you, from adding things that might require commercial licenses by mistake / unknowingly.
Related
Consider two software projects, proj_a and proj_b, with the latter depending on the former; and with both using CMake.
When reading about modern CMake, one gets the message that the "appropriate" way to express dependencies is via target dependencies; and one should arrange it so that dependent projects are represented as (imported) targets you can depend on. More specifically, in our example, proj_b will idiomatically have:
find_package(proj_a)
# etc etc.
target_link_library(bar proj_a::foo)
and proj_a will need to have been installed, utilizing the CMake installation-and-export-related commands, someplace where proj_b's CMake invocation will search for proj_a-config.cmake.
I like this approach and encourage others to adapt to it. It offers flexibility in the choice of your own version of proj_a vs the system version; and also allows for non-CMake proj_a's via a Findproj_a.cmake script (which again, can be system-level or part of proj_b).
So far so good, right? However, there are people who want to "take matters into their own hands" in terms of dependencies - and CMake officially condones this, with commands such as ExternalProject and more recently, FetchContent: This allows proj_b's configuration stage to actually download a (built, or in our case source-form) version of proj_a.
The puzzling part to me is that, after proj_a is downloaded, say to an external/proj_a directory, CMake's default behavior will be to
add_subdirectory(external/proj_a)
that is, to use proj_a as a subproject of proj_b and build them together. This, while the idiomatic use above allows the maintainer of proj_a to "do their own thing" in my CMakeFile, and only keep things neat and tidy for others via what I export/install.
My questions:
Why does it make sense to add_subdirectory(), rather than to build, install, and perform the equivalent of find_package() to meet the dependency? Or rather, why should the former, rather than the latter, be the default?
Should I really have to write my project-level CMakeLists.txt to be compatible with being add_subdirectory()'ed?
Note: Just to give some concrete examples of how this use constrains proj_a:
Must use unique option names which can't possibly clash with super-project names. So no more WITH_TESTS, BUILD_STATIC_LIB - it has to be: WITH_PROJ_A_TESTS and BUILD_PROJ_A_STATIC_LIB.
You have to account for the parent project having searched for other dependencies already, and perhaps differently than how you would like to search for them.
Following the discussion in comments, I decided to post a bug report about this:
#22904: Support FetchContent_MakeAvailable performing build+install+find_package rather than add_subdirectory
So maybe this will change and the question becomes moot.
Why does it make sense to add_subdirectory(), rather than to build, install, and perform the equivalent of find_package() to meet the dependency? Or rather, why should the former, rather than the latter, be the default?
FetchContent doesn't just have to be for project() dependencies. It can be used for fetching utility scripts too. I'm guessing it was designed with that kind of consideration in mind. If your utility script is just one file, you can just file(DOWNLOAD) and add_subdirectory() directly, but the utilities could be multiple files, such as is the case with aminaya/project_options. FetchContent() uses a lot of the same machinery as ExternalProject, so it can do a lot of the useful things that ExternalProject does. For example, you can use FetchContent to fetch aminaya/project_options as a remote git repo, or as its archive artifacts- ex. v0.20.0.zip
Should I really have to write my project-level CMakeLists.txt to be compatible with being add_subdirectory()'ed?
It's your choice! The reasoning here can be highly objective, or subjective. It's up to you. Some people just like to put in a lot of effort to support whatever their users might want. Some people have a lot of historical configuration baggage and are still catching up to newer CMake. And as you mentioned at the end of your question post, there are certain adjustments that need to be made to accomodate for cleanly allowing people to add_subdirectory() you as a dependency. One example of a project which chose "no" is glew (see issue #314 for explanation).
Just to give another reference to some related work mentioned in responses to the KitWare/CMake ticket your raised, here's the ticket which tracked work on "FetchContent and find_package() integration".
We have a C++-based application that runs on Windows, Mac, and Linux. I now need to add h.264 and h.265 decoding within this application. It seems ffmpeg will do the trick.
As ours is a commercial application, we cannot disclose the source code to public. However, as I understand, FFMpeg is based on LGPL licensing requirements. Going through various articles on LGPL requirements, it seems I can use ffmpeg without disclosing our source code as long as:
I build ffmpeg as a shared libraries and make sure that I don't use "--enable-gpl" flag during configuration.
I acknowledge in our About dialog box that we are using ffmpeg shared libraries.
Can someone please verify if this more or less meets the requirements? Regards.
Note that I need ffmpeg only to decode and not to encode. Therefore, I don't have to use "--enable-libx264" and "--enable-libx265" flags.
As a FFmpeg developer, I would expect you to follow the considerations mentioned on our website:
Compile FFmpeg without "--enable-gpl" and without
"--enable-nonfree".
Use dynamic linking (on windows, this means
linking to dlls) for linking with FFmpeg libraries.
Distribute the
source code of FFmpeg, no matter if you modified it or not.
Make
sure the source code corresponds exactly to the library binaries you
are distributing.
Run the command "git diff > changes.diff" in the
root directory of the FFmpeg source code to create a file with only
the changes.
Explain how you compiled FFmpeg, for example the
configure line, in a text file added to the root directory of the
source code.
Use tarball or a zip file for distributing the source
code.
Host the FFmpeg source code on the same webserver as the
binary you are distributing.
Add "This software uses code of FFmpeg licensed under the LGPLv2.1 and its source can be downloaded here [where here is a link to the source code]" to every page in your website
where there is a download link to your application.
Mention "This
software uses libraries from the FFmpeg project under the LGPLv2.1"
in your program "about box".
Mention in your EULA that your program
uses FFmpeg under the LGPLv2.1.
If your EULA claims ownership over
the code, you have to explicitly mention that you do not own FFmpeg,
and where the relevant owners can be found.
Remove any prohibition
of reverse engineering from your EULA.
Apply the same changes to all
translations of your EULA.
Do not misspell FFmpeg (two capitals F
and lowercase "mpeg").
Do not rename FFmpeg dlls to some obfuscated
name, but adding a suffix or prefix is fine (renaming "avcodec.dll"
to "MyProgDec.dll" is not fine, but to "avcodec-MyProg.dll" is).
Go
through all the items again for any LGPL external library you
compiled into FFmpeg (for example LAME).
Make sure your program is
not using any GPL libraries (notably libx264).
From what you've said so far, I think you're doing only point 1-2, 9-11, 15-18. You need to make the source code (of FFmpeg) including modifications (3-5, 7-8) available along with your application, mention build instructions (6), remove ownership claims on FFmpeg, remove reverse engineering prohibitions (if any), and check your EULA (12-14).
Yes, with lgpl you can use it as a dll/shared lib and you won't need to make your source code available.
But you should be aware that it's not the licensing of the code is the issue for commercial use, but the patents around h.264/h.265 and you need license for that. AFAIK, even if you simply want to decode you'll still need to have license.
MPEGLA is the licensing body for h264 codec patent pool.
When I use clearmake -C gnu on makefiles that use the MAKEFILE_LIST variable, MAKEFILE_LIST is empty. But when I use regular GNU make on the same makefiles, MAKEFILE_LIST is a list of file paths and names (as it should be).
To see what MAKEFILE_LIST is equal to, I'm using $(info $$MAKEFILE_LIST is [${MAKEFILE_LIST}]). There are no spaces in any of the file names, so I know that's not causing any problems, and the ClearCase manual lists some features of GNU make that clearmake does not support, but MAKEFILE_LIST is not among those features.
Has anyone else experienced a similar problem with clearmake and MAKEFILE_LIST? If so, were you able to fix it and how?
Had to look up the MAKEFILE_LIST macro to see what it did. And yes, this isn't something that clearmake currently supports. It's also not something listed as explicitly not supported.
I used the sample make snippet at https://www.gnu.org/software/make/manual/html_node/Special-Variables.html to confirm the lack.
I can't categorize this as a defect, so the best bet would be to avoid the middleman and enter the RFE in the Developerworks RFE community at https://www.ibm.com/developerworks/rfe/
If at all possible, can you please provide a "business justification" in Manager-Speak (Dollars lost/Man hours needed to work around not having the capability)? Like every other non-startup development shop, developer time is at a premium, so it's important to put the impact in.
I can't say that you'll get the answer you want, but you should get a response.
From what you've written looks pretty clear that it's not supported; just because it's not listed in the manual doesn't mean that they support it. That manual might have just not been updated. However, MAKEFILE_LIST was added in GNU make 3.80 which was released in 2002. Pretty lame if they don't indeed support it.
For the amount of $$ you're paying for ClearCase, I would recommend you contact their support and ask them directly rather than trying to get answers from StackOverflow :).
In any event if you want answers from people who use ClearCase I suggest you add that, or at the very least clearmake, to your list of tags.
As illustrated in "Rational ClearCase: clearmake -C gnu and GNUmake diferences.", clearmake is not gmake.
And this thread makes it clear that "base ClearCase" isn't exactly actively developed (though it is still very much maintained with ClearCase 9.x, as shown in this recent clearmake output format).
MAKEFILE_LIST is not mentioned in "env_ccase" (which includes standard UNIX and Linux EVs that are particularly important for ClearCase and MultiSite), and I never had the occasion of using it.
What are the things I need in my install and uninstall targets in a Makefile for an OCaml library in order to make it play nicely with the rest of the installation, work seamlessly with ocamlfind and so on? Basically to be a "good citizen". I am not interested in GODI at the present time. Thanks!
META files for ocamlfind are easy to write (basically, look for a META in another ocaml project you know¹, copy it and make the corresponding changes), and they will give you ocamlfind integration, with in particular easy support for post-build installation and desinstallation (using ocamlfind install and ocamlfind remove). You should begin with that.
¹: for example I take inspiration from batteries's META.
The building part of the Makefile is more tricky, their are numerous solutions (OCamlMakefile, OMake, ocamlbuild, plain Makefile, etc.) with varying strenghts and weaknesses. If you project is simple enough I would recommend ocamlbuild that takes care of a lot of the dependency tracking by itself.
You may also use Oasis, which is a relatively new tools that builds on ocamlbuild and ocamlfind and seeks to provide a unified configuration file for pre-build configuration and various building and deployment (of your program, your software libraries if any, accompanying data or documentation...). It's not yet a mature project (and its little brother Oasis-DB isn't released yet), but I encourage you to give it a try if you have time. It's a bit more complex than META, as it does more in the end, so building the META first is still a good step.
Finally, you said you weren't interested in Godi (Godi is a very good system, and in some cases (eg. BSD etc.) it's a premium choice to have a good OCaml installation), but in case you may still be interested in Godiva, a tool to help the building of GODI packages. I have never used it myself, though.
I don't use makefiles but ocamlbuild and a shell script to install the software I distribute. Debian people did packages for my software with these scripts without problems. So you may want to check them out since they correspond to some of their requirements (e.g. separate targets for byte and native code).
You may also want to have a look
to their packaging policy, though I don't know if this document is still up to date.
Don't forget to add a META file for ocamlfind. And you may also want to include an _oasis file for the upcoming oasis-db project (not yet done in the software I distribute).
Can any one of you help me in converting an windows dll file in a .so file.
You might try re-compiling the source code to the dll to a shared object. This may help you get started, after ensuring the code is indeed portable.
Edit:
Here is yet another link that can help guide you through the process of creating a shared library using GCC and other parts of the GNU tool chain. This link will help you to discover pitfalls that other people had when undertaking a project similar to this.
There is only so much help that can be provided for such a specific task, especially with so many unknowns. If you elect to provide more information in your question, please leave a comment.
NB: I'm pulling these links right out of Google.
If you don't have the source, or can't recompile, you may be able to run the code under Wine.
You need to recompile again into an .so file.