The goal of the LSB is to develop and promote a set of open standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system even in binary form. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux Operating Systems.
The LSB compliance may be certified for a product by a certification procedure.
LSB also specifies boot facilities, such as $local_fs, $network, which are used to indicate service dependencies in System V-style initialization scripts. A machine readable comment block at the top of a script provides the information necessary to determine at which point of the initialization process the script should be invoked. It is called the LSB header.
The command lsb_release -a is available in many systems to get the LSB version details, or can be made available by installing an appropriate package, for example the redhat-lsb package in Red-Hat-flavored distributions such as Fedora,  or the lsb-release package in Debian-based distributions.
The LSB is designed to be binary-compatible and produce a stable application binary interface (ABI) for independent software vendors. To achieve backward compatibility, each subsequent version is purely additive. In other words, interfaces are only added, not removed. The LSB adopted an interface deprecation policy to give application developers enough time in case an interface is removed from the LSB.
This allows the developer to rely on every interface in the LSB for a known time and also to plan for changes, without being surprised. Interfaces are only removed after having been marked "deprecated" for at least three major versions, or roughly eleven years.
The LSB has been criticized for not taking input from projects, most notably the Debian project, outside the sphere of its member companies.
Choice of the RPM package format
The LSB specifies that software packages should either be delivered as an LSB-compliant installer, or (preferably) be delivered in a restricted form of the RPM Package Manager format.
This choice of package format precludes the use of the many other, existing package formats not compatible with RPM. To address this, the standard does not dictate what package format the system must use for its own packages, merely that RPM must be supported to allow packages from third-party distributors to be installed on a conforming system.
Limitations on Debian
Debian has included optional support for the LSB early on, at version 1.1 in "woody" (3.0; July 19, 2002), 2.0 in "sarge" (3.1; June 6, 2005), 3.1 in "etch" (4.0; April 8, 2007), 3.2 in "lenny" (5.0; February 14, 2009) and 4.1 in "wheezy" (7; May 4, 2013). To use foreign LSB-compliant RPM packages, the end-user needs to use Debian's Alien program to transform them into the native package format and then install them.
The LSB-specified RPM format has a restricted subset of RPM features—to block usage of RPM features that would be untranslatable to .deb with Alien or other package conversion programs, and vice versa, as each format has capabilities the other lacks. In practice, not all Linux binary packages are necessarily LSB-compliant, so while most can be converted between .rpm and .deb, this operation is restricted to a subset of packages.
By using Alien, Debian is LSB-compatible for all intents and purposes, but according to the description of their lsb package, the presence of the package "does not imply that we believe that Debian fully complies with the Linux Standard Base, and should not be construed as a statement that Debian is LSB-compliant."
Debian strived to comply with the LSB, but with many limitations. However, this effort ceased around July 2015 due to lack of interest and workforce inside the project. In September 2015, the Debian project confirmed that while support for Filesystem Hierarchy Standard (FHS) would continue, support for LSB had been dropped. Ubuntu followed Debian in November 2015.
Quality of compliance test suites
Additionally, the compliance test suites have been criticized for being buggy and incomplete—most notably, in 2005 Ulrich Drepper criticized the LSB for poorly written tests which can cause incompatibility between LSB-certified distributions when some implement incorrect behavior to make buggy tests work, while others apply for and receive waivers from complying with the tests. He also denounced a lack of application testing, pointing out that testing only distributions can never solve the problem of applications relying on implementation-defined behavior.
For the vendors considering LSB certifications in their portability efforts, the Linux Foundation sponsors a tool that analyzes and provides guidance on symbols and libraries that go beyond the LSB.