Skip to main content

What is Open Source Software? Types of Open Source Licenses.

Open source software is software with source code that anyone can use, study, modify, and share.
Source code is the set of human-readable instructions that are used to make a program. This may be interpreted as a script, or compiled into a binary executable which the computer runs directly. All source code is copyrighted from the moment it is created. Whether it can be distributed as source or binary executables is under the control of the copyright holder. Therefore, software is provided to users under a software license.
Some software has source code that only the person, team, or organization that created it can see, or change, or distribute. This is sometimes called "proprietary" or "closed source" software. Typically the license only allows the end user to run the program, and provides no access, or tightly limited access, to the source.
Open source software is different. When the copyright holder provides software under an open source license, they grant the user the right to run the program and also to view, modify, compile, and redistribute the source royalty-free to others.
Open source promotes collaboration, sharing, transparency and rapid innovation because it encourages people beyond the original developers to make modifications and improvements to the software and to share it with others.
Just because software is open source doesn't mean it is somehow not able to be used or provided commercially. Open source is a critical part of many organizations' commercial operations. Some open source licenses allow code to be reused in closed source products. Open source code can be sold, but the terms of true open source licenses generally allow the customer to re-distribute the source code. Most commonly, vendors like Red Hat can provide commercial help with deploying, supporting, and extending solutions based on open source products.
Open source has many benefits for the user:
  • Control: See what the code does and change it to make it better.
  • Training: Learn from real-world code and develop more effective applications.
  • Security: Inspect sensitive code, fix with or without the original developers' help.
  • Stability: Code can survive the loss of the original developer or distributor.
The bottom line is that we believe open source creates better software with a higher return on investment, and that we do things better when we do them together.

Types of Open Source Licenses.

There is more than one way to be open source. The terms of the software license control how the source can be combined with other code or reused, and hundreds of different open source licenses exist. But in order to be open source, licenses must allow users to freely use, view, change, compile, and distribute the code.
There are two broad classes of open source license that are particularly important:
  • Copyleft licenses that are designed to encourage keeping code open source.
  • Permissive licenses that are designed to maximize code reusability.
Copyleft, or "share-alike" licenses, require that anyone who distributes the source code, with or without changes, must also pass along the freedom for others to also copy, change and distribute the code. The basic advantage of these licenses is that they help to keep existing code, and improvements to that code, open and add to the amount of open source code available. Common copyleft licenses include the GNU General Public License (GPL) and the Lesser GNU Public License (LGPL).
Permissive licenses are intended to maximize the reusability of source code. Users can use the source for any purpose as long as the copyright and license statements are preserved, including reusing that code under more restrictive or even proprietary licenses. This makes it very easy for this code to be reused, but at the risk of encouraging proprietary-only enhancements. Several commonly used permissive open source licenses include the MIT/X11 license, the Simplified BSD license, and the Apache Software License 2.0.

Comments

Post a Comment

thank you for visiting :)

Popular posts from this blog

Special Permissions in linux

The setuid permission on an executable file means that the command will run as the user owning the file, not as the user that ran the command. One example is the passwd command: [student@desktopX ~]$ ls -l /usr/bin/passwd -rw s r-xr-x. 1 root root 35504 Jul 16 2010 /usr/bin/passwd In a long listing, you can spot the setuid permissions by a lowercase s where you would normally expect the x (owner execute permissions) to be. If the owner does not have execute permissions, this will be replaced by an uppercase S . The special permission setgid on a directory means that files created in the directory will inherit their group ownership from the directory, rather than inheriting it from the creating user. This is commonly used on group collaborative directories to automatically change a file from the default private group to the shared group, or if files in a directory should be
Post a Comment
Read more

The Seven-Step Model of Migration

Irrespective of the migration approach adopted, the Seven-step Model of Cloud Migration creates a more rational point of view towards the migration process and offers the ability to imbibe several best practices throughout the journey Step 1: Assess Cloud migration assessments are conducted to understand the complexities in the migration process at the code, design and architectural levels. The investment and the recurring costs are also evaluated along with gauging the tools, test cases, functionalities and other features related to the configuration. Step 2: Isolate The applications to be migrated to the cloud from the internal data center are freed of dependencies pertaining to the environment and the existing system. This step cuts a clearer picture about the complexity of the migration process. Step 3: Map Most organisations hold a detailed mapping of their environment with all the systems and applications. This information can be used to distinguish between the
Post a Comment
Read more

RequestsDependencyWarning: urllib3 (1.24.1) or chardet (3.0.4) doesn't match a supported version

import tweepy /usr/lib/python2.7/dist-packages/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.24.1) or chardet (3.0.4) doesn't match a supported version!   RequestsDependencyWarning) Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/usr/local/lib/python2.7/dist-packages/tweepy/__init__.py", line 14, in <module>     from tweepy.api import API   File "/usr/local/lib/python2.7/dist-packages/tweepy/api.py", line 12, in <module>     from tweepy.binder import bind_api   File "/usr/local/lib/python2.7/dist-packages/tweepy/binder.py", line 11, in <module>     import requests   File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 97, in <module>     from . import utils   File "/usr/lib/python2.7/dist-packages/requests/utils.py", line 26, in <module>     from ._internal_utils import to_native_string   File "/usr/lib/python2.
Post a Comment
Read more

tag