Professional Documents
Culture Documents
UNIT I: INTRODUCTION
1. Introduction to Open sources
2. Need of Open Sources
3. Advantages of Open Sources
4. FOSS usage
5. Free Software Movement
6. Certification courses issues -Global and Indian
7. Application of Open Sources
8. Commercial aspects of open source movement
9. Introduction to Open Source Hardware
People use free software operating systems such as GNU/Linux for various reasons.
Many users switch for practical reasons: because the system is powerful, because it
is reliable, or for the convenience of being able to change the software to do what
you need.
Those are good reasons—but there is more at stake than just convenience. What are
at stake are your freedom, and your community.
The idea of the Free Software Movement is that computer users deserve the
freedom to form a community. You should have the freedom to help yourself, by
changing the source code to do whatever you need to do. And the freedom to help
your neighbour, by redistributing copies of programs to other people. Also the
freedom to help build your community, by publishing improved versions so that
other people can use them.
In 1998 the term “open source” was coined and associated with views considerably
different from ours. These views cite only the practical advantages of free software,
and carefully avoid the deeper issues of freedom and social solidarity that the Free
Software Movement raises. The idea of open source is good as far as it goes, but it
only scratches the surface of the issue.
Privacy and security:users of FOSS can inspect and verify the source code
themselves and can put trust on a community of volunteers and users
Companies need to manage the use of FOSS components from the following
aspects:
1. FOSS usage policy
3. License compliance
4. Security vulnerabilities
5. Auditing workflows
FOSS management systems that are designed and developed by experts can
ensure that these aspects are addressed properly. A comprehensive FOSS
management solution helps customers handle the different aspects relating to
FOSS component usage.
FOSS usage policy management: Every company that uses FOSS components
should have a FOSS usage policy. The policy should contain rules that govern
different aspects of FOSS management, including:
1. Stakeholders that have a say in terms of developing and maintaining such
policy (e.g., architects, FOSS managers, security specialists, development
managers, the legal department)
2. The internal and external usage of FOSS components
3. FOSS licenses (e.g., MIT, GPL, etc.) that are compatible with the company’s
business model
Identifying and managing these different types of usage can be a daunting and
error-prone task if done manually. This is especially true when considering the
complexity of modern software systems, and the ease of access to the vast pool of
available FOSS components. Reliable FOSS management systems should be well-
equipped with functionalities and algorithms to identify and detect FOSS components.
This can save a company valuable efforts that can be otherwise used in developing
their products
Open source license compliance
Different FOSS components are associated with different types of open source licenses.
These licenses have different legal obligations, depending on how the FOSS component is
used by the company.
For example:
Is the FOSS component in use internally only? Or, is it distributed with a product? If
so, is it being distributed in binary or source format?
Is the FOSS in use as is? Or is it being modified?
Example:
1. The GNU General Public License (GPL) mandates different obligations if the FOSS
is distributed as part of the company’s product, as opposed to its use only internally. Also,
customers using FOSS components with different open source licenses should make sure
that such licenses are compatible.
2. Distributing products that contain code licensed under Mozilla Public License
(MPL) and GPL will violate the terms of the licenses.
FOSS management systems are able to detect different open source licenses in use. They
can also help customers identify license obligations based on the way these components
are used. Additionally, they can provide input to help the legal team make decisions in
terms of whether the use of a certain FOSS component is or isn’t allowed. This is based on
the compatibility of license obligations with the company’s policies and business model.
Security vulnerabilities
Companies should make sure that their products don’t contain security vulnerabilities that
could expose customers to security breaches. Like any other piece of software (open or
closed), FOSS components are also vulnerable to security issues. Companies producing
software need to be aware of vulnerabilities associated with FOSS components in use.
Additionally, they should continuously monitor newly discovered vulnerabilities in these
components, or known vulnerabilities that are fixed.
There are multiple platforms that collect and maintain databases of known FOSS
components, such as the National Vulnerability Database. FOSS management
systems harvest such databases, continuously monitor them, and provide timely
information regarding the FOSS component vulnerabilities in their codebases.
Audit workflow
Software shops usually have multiple roles that are involved in auditing the usage of FOSS
components (i.e., reviewing and approving/disapproving usage). Examples of such roles
include:
Legal staff
Development managers
Security specialists
FOSS managers
With both, multiple roles in the company could be responsible for auditing FOSS
component usage. These roles include security specialists who check security
vulnerabilities that could be relating to the component. It could also include legal staff who
check the legal obligations of the component’s license.
FOSS management systems provide workflow engines that simplify the proactive and
reactive auditing of FOSS components. A rich and efficient workflow provides and
facilitates a smooth audit process. It allows:
Audit trail for all activities taking place during the audit of FOSS components
1. Proprietary license is a license where the owner maintains full control of the
source code and the general release is prohibited from modifying it. Windows and
Apple iOS are two examples.
2. GNU Public License is the most restrictive of the FOSS category. GNU is a
recursive acronym for Gnu’s Not Unix. It is a free software license where any
derivative work or use of any part of the source code automatically inherits the
license of the parent. In other words, any derivative work from the parent requires
that the derivative must be free and is automatically applicable under this license.
3. Permissive Software, also called Limited GPL, or LGPL, has fewer restrictions,
meaning the software may be included in proprietary work if attribution is given to
the owner of the parent. FreeBSD (Berkeley Software Distribution) is one operating
system that utilizes this license.
4. Public Domain is openly defined within the source code as freely available to the
public with no requirement to identify the owner.
5. License Free Software where there is no explicit license definition for a given
software. There is no guarantee that the software is Public Domain so it should be
treated as software under a Proprietary License.
Issues or Risks associated with FOSS
At a very top level, these issues or risks associated with FOSS may be divided into
the following categories:
1. Legal (License violation, confidentiality and data privacy)
2. Intellectual property (Copyright or patent)
3. Security
4. Operational
5. Business
The Legal Risk of Using FOSS Code
Even with the various types of FOSS licenses, there is one common risk: the legal
ramifications of incorporating all or part of FOSS code into a commercial or another
FOSS product with the intent of promoting that copied code as part of the final
product. For example, Apache is an open source web server and may be used
commercially provided that proper attribution is given to Apache.
Unless specifically permitted, developers are prohibited from copying any source or
binary code into their commercial product. Developers are permitted to review any
open source code to learn how it works, but they must create their own code from
scratch
The common misconception around illegally copying FOSS software is that the act
will never be discovered, but that belief is not always true. Here’s why:
First, software is likely to be unique from developer to developer.
Second, FOSS, like any other code, may contain security vulnerabilities
Third, there are methods of including the official license for FOSS in the source and
binaries.
Fourth, good software engineers and forensic experts know how to reverse-engineer
code
Recommendations for Using FOSS Safely
These recommendations should reduce your liability with the use of external free
open source software:
Make sure to abide by the FOSS’ licensing requirements.
Define the proper use of FOSS in company policies
If the company permits the use of certain FOSS licenses, make sure every developer
understands the types of licenses that are permitted to be included.
Leverage training
If the product needs an external FOSS package to operate, require the end user to
install that FOSS package separately
FOSS Certification:
A wide range of preparation options are supported, and training and testing centres
for LPI certification are available in many countries.
2.Red Hat Certified Engineer (RHCE)
Red Hat ( http://www.redhat.com/training ) has two certification examinations-
the Red Hat Certified Engineer (RHCE) and the Red Hat Certified Technician (RHCT).
The training and testing emphasize practical skills and the exams measure
competence with live equipment.
The RHCE is aimed at two groups of IT professionals. The first group consists of
system administrators, network engineers and other IT staff who already possess
experience and knowledge in UNIX or GNU/Linux.
The second group includes IT professionals who have little or no prior experience
with UNIX or GNU/Linux.
The RHCE and RHCT certifications are meant to assess competencies in installing
and configuring Red Hat Linux, configuring basic networking and file systems,
essential system administration and configuring basic security.
The RHCT is certification to a technician level and focuses more on client-side
services and supporting Red Hat Linux systems on an existing network.
RHCE focuses on server services and assesses competence in managing Red Hat
Linux servers
The RHCE and RHCT certifications are meant to assess competencies in installing
and configuring Red Hat Linux, configuring basic networking and file systems,
essential system administration and configuring basic security.
The RHCT is certification to a technician level and focuses more on client-side
services and supporting Red Hat Linux systems on an existing network.
RHCE focuses on server services and assesses competence in managing Red Hat
Linux servers.
3.CompTIA Linux+
Computing Technology Industry Association (CompTIA)
Linux+ ( http://www.comptia.org/certification/linux/default.asp ) certification is
another vendor-neutral programme that validates the knowledge and abilities of
technicians with at least six months of practical GNU/Linux experience.
The CompTIA Linux+ certification exam measures competencies in planning and
implementation, installation, configuration, administration, maintenance and
troubleshooting of GNU/Linux systems. This is considered to be an entry-level
certification on GNU/Linux.
Written in PHP
Drupal
Allows an individual or a community of users to easily publish, manage and organize
a wide variety of content on a website
Content
Management Free open source content-management system meant for publishing content on the
Systems Web and intranets using the MySQL database
Written in PHP
Operating Largest community maintained Linux OS – enables users to draw upon a wide
Systems (all network for support
Linux Ubuntu
distributions)
Open source Fedora is a general purpose Linux operating system, developed by the
community-supported Fedora Project and sponsored by Red Hat (a company
Fedora committed to open source software, and a major Linux distribution vendor).
Word-processing program
Office suite
PhpBB
1. Documentation
The hardware must be released with documentation including
design files, and must allow modification and distribution of the
design files.
IF not furnished with product – download via Internet
The documentation must include design files in the preferred format
for making changes.
The license may require that the design files are provided in fully-
documented, open format(s).
2. Scope
The documentation for the hardware must clearly specify what
portion of the design, if not all, is being released under the license.
3. Necessary Software
If the licensed design requires software, embedded or otherwise, to
operate properly and fulfill its essential functions, then the license
may require that one of the following conditions are met:
a) The interfaces are sufficiently documented such that it could
reasonably be considered straightforward to write open source
software that allows the device to operate properly and fulfill its
essential functions. For example, this may include the use of
detailed signal timing diagrams or pseudocode to clearly illustrate
the interface in operation.
b) The necessary software is released under an OSI-approved open
source license.
4.Derived Works
The license shall allow modifications and derived works, and shall
allow them to be distributed under the same terms as the license of
the original work. The license shall allow for the manufacture, sale,
distribution, and use of products created from the design files, the
design files themselves, and derivatives thereof.
5.Free redistribution
The license shall not restrict any party from selling or giving away
the project documentation. The license shall not require a royalty or
other fee for such sale. The license shall not require any royalty or
fee related to the sale of derived works.
6. Attribution
The license may require derived documents, and copyright notices
associated with devices, to provide attribution to the licensors when
distributing design files, manufactured products, and/or derivatives
thereof.
The license may require that this information be accessible to the
end-user using the device normally, but shall not specify a specific
format of display. The license may require derived works to carry a
different name or version number from the original design.
7. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of
persons
8.No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the work
(including manufactured hardware) in a specific field of endeavour.
For example, it must not restrict the hardware from being used in a
business, or from being used in nuclear research
9. Distribution of License
The rights granted by the license must apply to all to whom
the work is redistributed without the need for execution of an
additional license by those parties.
10 License Must Not Be Specific to a Product
The rights granted by the license must not depend on the licensed
work being part of a particular product. If a portion is extracted
from a work and used or distributed within the terms of the license,
all parties to whom that work is redistributed should have the same
rights as those that are granted for the original work.
11. License Must Not Restrict Other Hardware or Software:
The license must not place restrictions on other items that are
aggregated with the licensed work but not derivative of it. For
example, the license must not insist that all other hardware sold
with the licensed item be open source, nor that only open source
software be used external to the device.
12. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual
technology, specific part or component, material, or style of
interface or use thereof
Examples
1. Computers
a. EOMA68
b. Novena
c. GnuBee
2. Electronics
a. Sparkfun
b. Adafruit
c. Arduino
d. mass spectrometry
3. Mecha(tro)nics
a. 3D printers such as RepRap, Prusa, and Ultimaker
b. laser cutter Lasersaur
c. XYZ Space Frame Vehicles and Tabby OSVehicle
d. open-source ventilators, the echostethoscope echOpen
4. Others
construction (Wikihouse), textile (Kit Zéro Kilomètres), and firearms
(3D printed firearm, Defense Distributed