My friend is currently in preparation of distributing his software and wants to cleanup on the licenses of software he uses. The strategy is that he collects all the files that provides the licensing text.
He finished collecting all the "obvious" licenses, such as the Qt license of the Qt libraries he uses. However he also uses some of the Windows DLLs that come with Windows, such as kernel32.dll and advapi32.dll.
Where can he find the license files so that he can publish it with his software? The first DLL file, kernel32 appears to be automatically linked to his software based on an http://en.wikipedia.org/wiki/Auto-linking directive. The second file, advapi32.dll is linked explicitly to his software, and he wants to cleanup the situation of that file by collecting the file that provides the license.
For debian linux for example, he knows that the files are below /usr/share/doc/<package of the library>/copyright.
Not an option, distributing those Windows components cannot work. Different Windows versions have very different implementations of these DLLs. Even computers with the same version may have different DLL versions, these runtime components are often updated by Windows Update. Forcibly overwriting them would be normally disastrous, but the File System Protection feature in Windows recovers the damage.
There simply is no need to distribute these DLLs. Every Windows machine already has them, along with a solid promise from Microsoft that they will be compatible with the program as long as the programmer set the _WIN32_WINNT macro correctly in his code. Which selects the minimum Windows version that he chooses to support, it prevents accidentally taking a dependency on winapi functions that are only available in later versions. Getting that wrong simply prevents the program from starting.
Since you mentioned GPL in the comments, you need to know that GPL has special language concerning system libraries.
The GPL FAQ says
Both versions of the GPL have an exception to their copyleft, commonly called the system library exception. If the GPL-incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them.
Naturally you should rely on the actual legal language of the license, not the FAQ. Hopefully any infectious non-GPL licenses take a similar approach.
The license that applies to Windows system DLLs is the end-user license for the desktop or server OS that they came with. There are many variations on these, such as volume licenses or development subscription licenses. So your friend needs to just chalk those up as "system library, non-distributable, source not distributable, governed by OS license".
Contrary to Alex's assertion in the comments, the Windows license does (or at least attempts to) govern use in addition to redistribution. Running the application in, for example WINE, where there may not be a valid license for certain required system libraries would present a problem, even if the system libraries were placed onto the hard drive during installation/patching of a licensed copy of Windows. I am not a lawyer, but I'm pretty sure that problem falls on the administrator of the WINE environment who caused those DLLs to be loaded, not the third-party application developer.
You may not redistribute Windows system DLLs. This includes kernel32, ntdll, advapi32, and a couple of others. The exact list is not fixed but basically, it includes almost anything in the system32 directory. (This list may be a good start.) These files are considered to be part of Windows and thus covered by Windows EULA.
What you may redistribute depends on your compiler and/or any third-party (non included in Windows) libraries you're using. For Microsoft Visual C++, see redist.txt in the installation directory. It usually has a text similar to following:
Visual C++ Runtime files
Subject to the license terms for the software, you may redistribute the .EXE files (unmodified) listed below.
These files can be run as prerequisites during installation.
vcredist_x86.exe
vcredist_x64.exe
vcredist_IA64.exe
Subject to the license terms for the software, you may redistribute MSM files listed below unmodified as a part of your installation package:
[...]
See here on the specifics of redistributing MS C runtime.
For other compilers/libraries you will need to consult their documentation.
Related
The usual recommendation for handling the dependencies on Linux is by using the distro's package manager.
The good part of this approach is that you can reuse the basic set of libraries configured, tested, and updated for your system.
The bad part is that there are many distros with different package managers, and you probably have to support several of them. Users of not-so-popular distros have to work on their own to set up the dependencies.
The worst part is, when talking about games, some game distribution platforms ban the developer from using package files for installation.
Quoting itch.io,
.deb and .rpm packages (Oh no tier)
These are ignored when looking for uploads - it'll appear as if your app wasn't available on Linux at all.
Do not use these.
To not use the package manager, one way is to build the app on a reasonably old system, like Debian oldstable or the Steam Runtime (based on Ubuntu 12.04), and distribute the final software by copying the shared libraries depended upon.
My question is which shared libraries should be copy-distributed in this stage.
Do I have to ship libc? If I don't, is it guaranteed that newer versions of libc has backwards compatibility with older versions of libc?
Can I just be safe and ship all the dependencies? Will it work on most systems despite being a bit heavy?
If that's not a solution, which shared libraries should I include and which not?
Do I have to ship libc?
For reasons explained here, it is nearly guaranteed that your libc.so.6 will not be compatible with the system ld-linux.so (the path to system ld-linux.so is baked into your binary).
You could however use a shell wrapper to avoid this problem. Something along the lines of:
#!/bin/bash
TOP=/path/to/your/install
exec -a "mygame" "$TOP/lib64/ld-linux-x86-64.so.2" --library-path "$TOP/lib64" "$TOP/bin/mygame"
If I don't, is it guaranteed that newer versions of libc has backwards compatibility with older versions of libc?
Yes, GLIBC backward compatibility guarantees exactly that: you could copy a binary from a system of 10 or 20 years ago, and it will run on a freshly installed latest distribution1.
which shared libraries should I include and which not?
Note that by distributing GPL software you assume certain obligations. Talk to your lawyer if you plan to do that.
1There have been a few bugs about 15 years ago where this backward compatibility was broken in some specific cases, but you are unlikely to run into them.
I've built a programme in C with Visual Studio using standard C libraries + a couple of windows libraries.
The code just acquires user input (with scanf, so through cmd window) does some calculations based on the input and outputs some text files, that's about it.
I'm wondering what would I then need to do to run my exe on another standard Windows computer without it needing to install any additional files e.g. the whole Windows SDK.?
Is it just a case of being able to build the release version (as opposed to the debug)?
Many thanks
If you pick the right CPU target (Project Configuration Properties -> C/C++: Enable Enhanced Instruction Set) such that the binary code doesn't include instructions understood by only a very narrow subset of CPUs, and the default for Visual Studio is to use instructions that are supported by the widest set of x86 or x64 CPUs, then your program will run on almost any Windows computer. You need to distribute any DLLs that aren't part of the base Windows installation though, which includes any additional dynamically linked language runtimes such as the Visual C++ runtime.
A good way to derive the list of DLLs that you have to package with your executable is to create a virtual machine with a fresh Windows installation without any development tools in it and then try to run your code there. If you get an error for a missing DLL, add it and repeat. When it comes to the Visual C++ runtime, Microsoft provides installable packages for the different versions that you are allowed to distribute as part of your installation (Visual C++ Whatever Redistributable Package).
Also, mind that programs compiled for 32-bit Windows will mostly run on 64-bit versions, but the opposite is not true.
Generally speaking, C programs are not "portable" meaning they can't be copied over to other machines and expected to run.
There are a few exceptional cases where C executables can safely be ran on other machines:
The CPUs support the same instruction set, with the same set of compatible side-effects and possibly the same bugs.
The Operating systems support the same system api points, with the same set of compatible side-effects and possibly the same bugs.
The installed non-operating system libraries support the same api points, with the same set of compatible side-effects and possibly the same bugs.
The API calling conventions are the same between the source (platform you built the code on) and destination (platform you will run the executable on).
Of course, not all of the CPU and OS need to be 100% compatible, just the parts your compiled program uses (which is not always easy to see as it is compiled, and not a 100% identical representation of the source code)
For these conditions to hold, typically you are using the same release of the operating system, or a compatibility interface designed by the operating system packagers that supports the current version of the operating system and older versions too.
The details on how this is most easily done differ between operating systems, and generally speaking, even if a compatibility layer is present, you need to do adequate testing as the side-effects and bugs tend to differ despite promises of multi-operating system compatibility.
Finally, there are some environments that can make non-same CPU executables run on an operating system (like QEmu) by simulating the foreign CPU instruction set at runtime, interperting those instructions into ones that are compatible with the current CPU. Such systems are not common across non-Linux operating systems; and, they may stumble if the loading of dynamic libraries can't locate and load foreign instruction set libraries.
With all of these caveats, you can see why most people decide to write portable source code and recompile it on each of the target platforms; or, write their code for an interpreter that already exists on multiple platforms. With the interpreter approach, the CPU is conceptually a virtual one, which is implemented to be identical across hardware, letting you write one set of source code to be interpreted across all the hardware platforms.
I've built a programme in C with Visual Studio using standard C libraries + a couple of windows libraries.
I'm wondering what would I then need to do to run my exe on another standard Windows computer without it needing to install any additional files e.g. the whole Windows SDK.?
You don't explain what your program is really doing. Does it have a graphical user interface? Is it a web server? Do you have some time to improve it or enhance it? Can it run on the command line?
Why cannot you share the C source code (e.g. using github)?
If you want some graphical interface, consider using GTK. It has been ported to Windows.
If a web interface is enough, consider using libonion in your program, or find some HTTP server library in C for your particular platform.
But what you need understand is mostly related to linking, not only to the C programming language (read the n1570 specification). Hence read about Linkers and loaders.
You should prefer static libraries. Their availability is platform specific. Read more about Operating Systems. Also, sharing some Microsoft Windows system WinAPI libraries could be illegal (even when technically possible), so consult your lawyer after showing him the EULA that you are bound to.
My opinion is that Linux distributions are very friendly when learning to program in C (e.g. using GCC or Clang as your C compiler). Both Ubuntu and Debian are freely downloadable, but practically require about a hundred gigabytes of consecutive free disk space. Be sure to backup your important data before installing one of them.
Did you consider porting, adapting and compiling your C code to WebAssembly? If you did that, your code would run inside most recent Web browsers. Look also into Bellard's JSLinux.
Related answer here. Notice that C can be transpiled to JavaScript and then run locally inside recent web browsers.
I developed a C program requiring some dynamic libraries, most notably libmysqlclient.so, which I intent to run on some remote-hosts. It seems like I have the following Options for distribution:
Compile the program static.
Install the required dependencies on the remote host
Distribute the dependencies with the program.
The first option is problematic as I need glibc-version at runtime anyway (since I use glibc and libnss for now).
I'm not sure about the second option: Is there a mechanism which checks if a installed library-version is sufficient for a program to run (beside libxyz.so.VERSION). Can I somehow check ABI-compatibility at startup?
Regarding the last Option: would I distribute ALL shared-libraries with the binary, or just the one which are presumably not installed (e.g libmysqlclient, but not libm).
Apart form this, am I likely to encounter ABI-compatibility problems if I use a different compiler for the binary then the one the dependencies were build with (e.g binary clang, libraries gcc)?
Version checking is distribution-specific. Usually, you would package your application in a .deb or .rpm file using the target distribution's packaging tools, and ship that to users. This means that you have to build your application once for each supported distribution, but there really is no way around that anyway because different distributions have slightly different versions of libmysqlclient. These distribution build tools generate some dependency version information automatically, and in other cases, some manual help is needed.
As a starting point, it's a good idea to look at the distribution packaging for something that relies on the MySQL/MariaDB client library and copy that. Maybe inspircd in Debian is a good example.
You can reduce the amount of builds you need to create and test somewhat by building on the oldest distribution versions you want to support. But some caveats apply; distributions vary in the degree of backwards compatibility they provide.
Distributing dependencies with the program is very problematic because popular libraries such as libmysqlclient are also provided by the base operating system, and if you use LD_LIBRARY_PATH to inject your own version, this could unintentionally extend to other programs as well (e.g., those you launch from your own program). The latter risk is still present even if you use DT_RUNPATH (via the -rpath linker option), although it is somewhat reduced.
A different option is to link just application-specific support libraries statically, and link base operating system libraries dynamically. (This is what some software collections do.) This does not seem to be such a great choice for libmysqlclient, though, because there might be an expectation that its feature set is identical to the distribution (regarding the TLS library and available configuration options), and with static linking, this is difficult to achieve.
I'm a bit naive when it comes to application development in C. I've been writing a lot of code for a programming language I'm working on and I want to include stuff from ICU (for internationalization and unicode support).
The problem is, I'm just not sure if there are any conventions for including a third party library. for something like readline where lots of systems are probably going to have it installed already, it's safe to just link to it (I think). But what about if I wanted to include a version of the library in my own code? Is this common or am I thinking about this all wrong?
If your code requires 3rd party libraries, you need to check for them before you build. On Linux, at least with open-source, the canonical way to do this is to use Autotools to write a configure script that looks for both the presence of libraries and how to use them. Thankfully this is pretty automated and there are tons of examples. Basically you write a configure.ac (and/or a Makefile.am) which are the source files for autoconf and automake respectively. They're transformed into configure and Makefile.in, and ./configure conditionally builds the Makefile with any configure-time options you specify.
Note that this is really only for Linux. I guess the canonical way to do it on Windows is with a project file for an IDE...
If it is a .lib and it has no runtime linked libraries it gets complied into you code. If you need to link to dynamic libraries you will have to assure they are there provide a installer or point the user to where they can obtain them.
If you are talking about shipping your software off to end users and are worried about dependencies - you have to provide them correct packages/installers that include the dependencies needed to run your software, or otherwise make sure the user can get them (subject to local laws, export laws, etc, etc, etc, but that's all about licensing).
You could build your software and statically link in ICU and whatever else you use, or you can ship your software and the ICU shared libraries.
It depends on the OS you're targeting. For Linux and Unix system, you will typically see dynamic linking, so the application will use the library that is already installed on the system. If you do this, that means it's up to the user to obtain the library if they don't already have it. Package managers in Linux will do this for you if you package your application in the distro's package format.
On Windows you typically see static linking, which means the application bundles the library and it will use that specific version. many different applications may use the same library but include their own version. So you can have many copies of the library floating around on your system.
The problem with shipping a copy of the library with your code is that you don't get the benefit of the library's maintainers' bug fixes for free. Obscure, small, and unsupported libraries are generally worth linking statically. Otherwise I'd just add the dependency and ensure that whatever packages you ship indicate it appropriately.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Using LGPL library in a commercial Java application
Hello guys!
There is a project under the GNU Lesser GPL license. I want to use this project in my application. Can I sell my application using this license?
In a nutshell, the idea of LGPL'd projects (usually libraries) is that you are free to use them as you wish in your own application, be it open or closed source, free or proprietary - as long as you publish the source code of the LGPL'd part (if you modify the LGPL'd part, you must publish the modified sources, under LGPL).
Additionally, the libraries must be linked dynamically so that they could be replaced to another version by the user if he so wishes. For libraries (.dll, .so, .jar...), this is usually self-evident. Side note: this is inherently pointless requirement, because nothing requires that your application works with any other library version than the one that you originally provided. You could even actively prevent your application from working with other versions.
You can use LPGLed libs with your proprietary software, but there are some restrictions you must observe. Better read the LGPL carefully and contact a lawyer.
General notes, You can use a LGPL library if
You link with it dynamically only allowing user to replace specific library (for example replace dll to newer compatible version).
If you make changes in LGPL code, you release the changed library sources as well.
Generally many closed source projects use LGPL code, it is common practice, but
read license carefully, especially this GPL-FAQ.
If you have doubts, contact lawyer.
If you are using the GNU app as part of the development process, then the resulting code is saleable.
If you are calling or otherwise using the public APIs of the GNU app then your app is saleable provided you package and distribute the GNU app as a separate component complete with the original app -- and make it clear in your documentation that you are using the GNU library and it still belongs to its original authors under the GNU license terms.
If on the otherhand you have modified the package, cut and pasted code from the package, inserted your code into thier programs or otherwise changed thier code to get yours to work you can only further distribute with the same gnu license. This does not actually preclude selling the software, but, there are all sorts of complications so its best not to go there.
If in doubt contact the original authors, tell them what you have done/intend and ask them what they think - it is afterall thier software your messing with.
Short answer is yes, you can sell your application under any license you like. The only thing you need to do is:
Mention somewhere that your product uses that library, anywhere, in the about box, in the splash screen, in the manual...
If your customers ever ask for the source code of that library (not necessarily your application), then you must give it to them or tell them how to obtain it. But note that only your customers/users actually have this right (and most customers don't bother right?).
That is basically it in a nutshell though I would still recommend you read the GPL FAQ posted by Artyom.