Overview

In order to be able to use someone else’s software for your own software project, you must attain a software license. This license establishes the rights and limitations that you have when using the product owner’s software. Software licenses are attained by licensing agreements, where you sign a contract with the owner of the software to use the patented technology.In that contract contain the rights, responsibilities, and limitations you have as a user. I think if you develop some sort of software, it is crucial that you and your team are recognized as the owners of it, and that outside users don’t use it however they feel like. There are many types of software licenses that have different terms and conditions. An article that I read by Ben Lutkevich went more into depth of what a software license and agreement will usually look like, as well as the different types.

Attaining a License

You are about to sign the licensing agreement to officially be able to use someone else’s software. Here’s what to expect. On it will be basic information about both sides. Your name, your address, contact information, as well as the lending party’s. It will contain when the agreement officially goes into effect, and you are able to use the software. It will contain the duration of how long you are able to use the software. It will include how much you have to pay for the software, how many users are eligible. It will give a disclaimer of warranties, as well as maintenance, upgrades and support. Most importantly, it will include the permissions and limitations on distributing the software, user rights of copying and modifying the software. These licensing agreements may differ depending on the type of software license.

Types of Software Licenses

The most common software licenses you find are Proprietary and FOSS. A proprietary software license is commonly referred to as closed-source. Proprietary licenses do not allow users to freely alter the software. Whereas FOSS (Free and Open-Source Software) is the opposite, where the customer is allowed to use the source code and alter the software. FOSS is commonly referred to as open-source. This is the type of license that we will be using in class. Two other licenses that are familiar are Permissive and Copyleft. Permissive software licenses establish some requirements for distribution or modification of the software, and Copyleft notes that licensed code may be distributed or modified as part of a software application or project if all code involved is distributed under the same license. New products containing old code with a copyleft license have the same restrictions as the old code’s license.

Conclusion

If planning to create a software product, it is a smart idea to establish copyright for it, so you are credited for the work you put in. And if you are using someone else’s product for your own product or project, it is the smart decision to attain a licensing agreement, avoiding any potential lawsuits.

Article URL

https://www.techtarget.com/searchcio/definition/software-license#:~:text=A%20software%20license%20is%20a,the%20software%20without%20violating%20copyrights.

From the blog CS@Worcester – William's Blog by William Cordor and used with permission of the author. All other rights reserved by the author.

Overview

The objective of any scrum project management framework is to provide structure, fluidity, values and principles when completing a project. But all members of the project must equally pull their weight as well as know their role for the use of scrum to be efficient. A famous saying that relates to this is that “a team is only as good as its weakest link”. This phrase can be applied to basically any team, or group of people pulling for the same cause, in life. I think a scrum team is no different. This article I read by Dave West goes in detail about each role in a scrum team and how they tie in to each other for the team to collectively succeed.

Scrum Team Roles

Previously stated in class, the three roles of a scrum team are: the development team, the product owner, and the scrum master, with each role being just as important as the other. Starting with the development team, the developers are the ones responsible for working on the product. They are the ones bringing the blueprints and requirements, brought from the product owner, to fruition, essentially doing the dirty work of the team. The product owners show them what needs to be done and the deadline by which it needs to be done, and the developers take it from there. They self-organize and make their own decisions on how to complete the task. The development team could be of any occupation from writing, designing, programming, etc. The prime responsibility of a product owner is understanding business requirements and customer feedback. Based on those two things, the product owner is able to set the focus of the team based on meeting deadlines and release dates. It can sometimes be stressful and overwhelming for developers and product owners having to avoid falling behind. This is where scrum masters come in. The scrum master is the overseer, the piece holding everything together. The scrum master must have knowledge in development and product ownership. The development team and the product owner must be able to count on the scrum master for help and support. The scrum master is responsible for the scrum working as one and keeping the values strong in the team, sort of like a coach. The scrum master is usually the most active member of the scrum team.

Conclusion

As previously stated, I think for scrum to work, all members should be on the right pace. The minute that one role falls behind is the minute the framework fails. With much communication, and all members collectively on the right track, scrum is a very strong framework.

Article I Used

https://www.atlassian.com/agile/scrum/roles

From the blog CS@Worcester – William's Blog by William Cordor and used with permission of the author. All other rights reserved by the author.