In today’s world of software development, understanding copyright and licensing is crucial for ensuring compliance with intellectual property and collaborative innovation. Developers often work with software libraries, tools, and frameworks created by others. Without a solid grasp of licensing terms, there’s a risk of infringing on someone else’s rights or unintentionally exposing some proprietary code to the public.

What is Copyright in Software?

Software copyright provides legal protection for the code written by developers, categorizing it as intellectual property. It grants the original creator exclusive rights to use, modify, distribute, and license their work. In most jurisdictions, as soon as a piece of code is written, it’s automatically copyrighted, even without a explicit registration.

However, copyright doesn’t cover ideas, or methods used in the software it only protects the specific implementation of those ideas in code. This means that while you can’t copy someone’s code without permission, you can write your own implementation of a concept.

The Types of Software Licenses

In class we learned about Software licenses and how they specify the terms under which code can be used, modified, and distributed. They range from very permissive to highly restrictive. Some common types include:

1. Open Source Licenses: These allow anyone to view, use, and often modify the code. Examples include:
   • MIT License: Permissive, allowing almost any use, including commercial purposes, as long as the original copyright notice is included.
   • GNU General Public License (GPL): Requires that any modified version of the code also be released under the GPL, ensuring that derivative works remain open.
   • Apache License(s): Permits use and distribution, even for commercial purposes, but includes a clause protecting contributors from patent claims.
2. Proprietary Licenses: These are restrictive and usually prevent users from modifying or distributing the software. Examples include end-user license agreements that accompany commercial software for example like Microsoft Office.
3. Creative Commons Licenses: While more common in creative works like music or literature, some software projects use Creative Commons to specify usage rights.

How to Choose the Right License

When releasing software, selecting the appropriate license is vital. If you want maximum collaboration and sharing, permissive licenses like MIT or Apache might be ideal. However, if you want to ensure that your work remains open source in derivatives, a copyleft license like GPL is a better choice.

Key Takeaways:

1. Read the License: Always read and understand the terms before using third-party software. Misinterpreting a license can lead legal issues.
2. Attribute Properly: Many licenses, even permissive ones, require attribution to the original author.
3. Derivative Rules: If you modify software under a restrictive license like GPL, you must release your changes under the same license.
4. Protecting Your Work: If you’re releasing your own software, choose a license that aligns with your goals for sharing or monetization.

Resources

• GNU Operating System: Licenses
• Choose an Open Source License
• Refactoring Guru on Software Licensing
• https://www.10duke.com/resources/glossary/software-copyright/

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

Throughout the beginning half of my Fall 2024 semester, I’ve learned about development processes such as environments, strategies, and team policies. As the year has progressed I wanted to know more about the development process of software before beginning my blogs. After tackling AGILE and Scrum I have been interested in seeing other ways of team management, and potential connections back to AGILE. To begin in understanding these processes I first found an article designed around general team management. This article is found on desktime.com, and it is not focused particularly on computer science, but on managing a team. The article’s title is A guide to team management: Strategies and techniques to help you succeed by Viesturs Abelis

This post outlines key strategies for effective team management to boost productivity and morale. It first emphasizes the importance of creating a supportive team culture, where employees feel valued and heard, mentioning Google’s Project Aristotle which found that psychological safety and feeling heard are crucial for team success. The article states that managers should engage actively with their team, foster inclusivity, and lead confidently. It is stressed that managers must be considered part of the team. The article also mentions the need for a clear vision and direction, including both long-term goals like a mission statement and short-term objectives like Key Performance Indicators and Objectives and Key Results. It highlights that employees are more motivated when they connect personally to the organization’s values. The use of productivity software is also recommended to improve team management. Tools for time tracking, performance evaluation, and project tracking provide valuable data, helping managers optimize team performance and streamline workflow. The article continues to reaffirm that team management combines fostering a positive culture, setting a clear direction, and using the right tools to enhance productivity and success.

This was a good article to step into team and development-based blogs, as it is a very broad and applicable subject matter. This is a key step in constructing a blog based on understanding development environments and processes. Without having a baseline understanding of team management, tactics like AGILE can be confusing to grasp. I wish to refine my knowledge in this area and prepare for working in and managing teams going forward into classes like CS-448. Next in my blog I will look into articles relating to development environments, such as Docker or GitPod, or look into articles based around AGILE and Scrum principles.

Source:https://desktime.com/blog/team-management

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

One of the topics we covered in Software Process Management this year is Scrum. I’ve always been curious about how big companies and tech corporations manage their teams and make everything work smoothly. In the article “Achieving Team Purpose and Pride with Scrum” by Sophia Ciocca, a Web Engineer at Spotify, she shares her team’s journey to creating a more efficient and structured routine using Scrum principles.

Sophia starts by describing the struggles her team faced when they first tried applying Scrum. Meetings felt unproductive, sprints were often left unfinished, and there was little connection between their daily tasks and long-term goals. To fix these issues, Sophia’s team reached out to a Spotify Agile Coach and decided to adopt the full Scrum framework, as outlined in the Scrum Guide.

This shift involved several key changes, like holding weekly backlog refinement sessions, simplifying sprint planning, improving sprint reviews, focusing retrospectives on actionable steps, and enhancing stand-ups. These adjustments helped the team stay aligned, better understand their workload, and communicate more effectively.

The results were impressive. The team’s efficiency improved significantly, and tasks were completed faster. They even tripled their monthly active users without adding more team members. Most importantly, the team gained confidence in their work and a stronger sense of pride and purpose.

I chose this article because it directly relates to the Agile methodologies and Scrum Guide we’ve discussed in class. I also wanted to understand how big companies use these frameworks to foster teamwork and efficiency. It’s fascinating to see how systems like Scrum can make a huge difference in how teams work together.

Sophia’s story highlights an important Agile principle: “responding to change over following a plan.” Her team’s ability to adapt their process while staying true to Scrum principles was key to their success. One of my main takeaways is that asking for help, like Sophia did by reaching out to an Agile Coach, can lead to growth and positive change.

As I prepare for my career in tech, learning how to implement Agile and Scrum effectively is crucial. This article showed me how small changes, like adding confidence checks to stand-ups, can improve teamwork and productivity. I’m excited to apply these insights in my future career and work with teams that value collaboration and continuous improvement.

Sources:

Achieving Team Purpose and Pride with Scrum

Citation:
Spotify Engineering, S. C. (2022, January 27). Achieving team purpose and pride with Scrum. https://engineering.atspotify.com/2021/05/achieving-team-purpose-and-pride-with-scrum/ 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

This week, I will be talking about the differences between coding and hacking, some of the confusions associated with them, and what your skill set should look like if you are learning about being a hacker. One question that will receive lots of attention is, “Do I need to learn coding to become a hacker?”

Let’s jump right into this. First, it’s important to note that coding and hacking are closely tied, but have important distinctions. Coding is the act of writing machine instructions, or code for a computer, which can be done in many different languages. Hacking, on the other hand, is the act of identifying and exploiting weaknesses in a computer system or network, usually to gain unauthorized access to personal or organizational information (to put it simply, you are breaking in). Hacking is not always a malicious activity, and there are actually several examples where hacking is used for good, like with penetration testing. Unfortunately, the term has garnered mostly negative connotations for its association with cyber-crime. It is important to remember that hacking is a tool–where it is not the tool that matters, but rather the intention of its user (what they wish to do with the tool).

Without a doubt, coding is a prominent part of hacking that has helped shape what it looks like today. If you are trying to learn about hacking, or are interested in taking part yourself, you would likely be doing yourself a disservice by having little to no prior knowledge of coding, because of how intertwined they are–but it is not absolutely necessary. In fact, there are multiple forms of hacking that require little to no coding skill. For example, social engineering is a type of hacking that focuses on the social, human aspect of security rather than the technical aspects. These attacks rely on human nature rather than code, and aim to manipulate people into compromising their personal security, or even the security of an entire network or organization they may be a part of.

In the podcast, Chuck raises an interesting question about having basic, fundamental knowledge of coding (specifically mentioning functions and classes) and asks if it’s really necessary to go much further than that if you are trying to become a hacker. John responds, “You don’t need to go much further beyond that. When people ask [that] question, I always say no, but with a disclaimer that you should learn some programming, but you don’t need to learn absolutely everything… I am not by any means a software engineer or architect, but I can script; I can write a loop that might brute-force passwords… and you don’t need to know a lot of hardcore, complex programming concepts for that. You just need to know the basics for that.”

John makes some very good points as the show continues, and focuses on how a lot of the basic, rudimentary skills in programming are often the ones that require the most practice, because of their importance, and because of how frequently they are used to build more complex pieces of code. He believes that the best way to get that practice is by immersing yourself in the world of hacking and trying to solve those problems with the skills that you have.

In conclusion, coding and hacking, despite being so closely intertwined, have some very distinct differences, and as it turns out, you may not need to know as much as you think you do about coding in order to start learning about hacking or becoming a hacker yourself. Although you may not need to know everything there is about programming, having some rudimentary knowledge is really all that it takes for you to start and branch out from what you have.

This episode can be watched in full, for free here on YouTube: https://www.youtube.com/watch?v=T7AaBcNj-mA&t=0s

From the blog CS@Worcester – Owen Santos Professional Blog by Owen Santos and used with permission of the author. All other rights reserved by the author.

This week, I have selected a blog about the concept of Software Testing as this is a topic of focus in our course. Upon reading this article it became very clear to me that – although I have used unit tests and other simple strategies – software testing has many important aspects that I am not familiar with. The post titled, “Software Testing 101: Get started with software testing types” was written by The Educative Team for their blog Dev Learning Daily which can be found here.

This blog is able to highlight the many different software testing methodologies and cycles that are used by developers throughout the development life cycle. At a high level, software testing is used to evaluate/correct program functions, ensure that the build meets the customer requirements, and confirm that integration of the software is possible/compatible with other components and other systems. Most of us are familiar with the reason we must test our software prior to production, but knowing how to test completely and comprehensively is the most vital aspect.

The post touches on Black Box vs White Box testing, Automation vs. manual testing, Functional testing methodologies, Non-functional testing methodologies, and some useful general information and best practices related to the software testing lifecycle. One topic that stuck out to me was the difference between functional and non-functional testing and the processes each follows. I think that the majority of my testing experience (if not all) has been rooted in functional testing even if I did not know it at the time. From this post, I have learned that functional testing has a cycle within itself focused on testing specific program behaviors and the process starts with unit testing to test small components of a program, then to integration testing to ensure components can work together, then system testing to ensure a full build is functioning properly, and finally acceptance testing with alpha testing being completed with internal users and beta being completed with external parties to get additional feedback without bias. There are many other types of testing mentioned that I had zero experience with, but after learning about them I am looking forward to when and how I can begin to use these new tools to help me write useful code.

Our projects can benefit on many different levels by implementing testing in their development cycle like ensuring minimal user experience conflicts and meeting customer expectations of completely functional requirements. I was able to learn about the many different kinds of testing that exist, in what circumstances they should be used, and how to implement them to get results in a real situation. The writers discussed the process for testing which I think I can summarize very simply as:

1. Determine what needs to be tested
2. Create a test case
3. Check result – Success? Move on! vs. Error? Solve it!

We can acknowledge that testing can become much more advanced than these steps, but the value gained makes it worthwhile.

From the blog CS@Worcester by cameronbaron and used with permission of the author. All other rights reserved by the author.

In the world of Scrum, navigating uncertainty and complexity is a key challenge. One practice that helps teams manage this is the use of “spikes”—a technique for addressing uncertainty by dedicating time to research, exploration, or experimentation. A blog post titled “Navigating Uncertainty: Crafting Effective Spikes in Scrum” provides a detailed examination of how to create and manage spikes effectively in Scrum. The post breaks down the concept of spikes, offering clarity on when and how to implement them in a way that maximizes value while minimizing disruption to the team’s flow.

A spike is essentially a time-boxed period where a team focuses on gathering information, resolving technical debt, or experimenting with a new technology, rather than delivering functional product increments. This is essential for reducing risk and uncertainty, particularly when the team faces unknowns that could impact the project’s success.

I selected this blog post because it directly relates to Scrum’s emphasis on adaptability and continuous learning. Understanding how to manage spikes effectively is crucial to achieving that adaptability. It complements key elements of the Scrum framework covered in our class, especially the Sprint Cycle and the role of the Product Owner in prioritizing work. In a Scrum environment, having a strategy for managing uncertainty aligns with the framework’s focus on iterative progress, continuous improvement, and adaptability.

Reading the blog post helped me better understand how spikes function within Scrum. One important takeaway is that spikes are not a sign of poor planning but rather a proactive strategy for tackling uncertainty. In previous projects, I often found myself overwhelmed when faced with unknowns.

The concept of spikes is a useful technique within Scrum for managing uncertainty. Reducing risk, improving decision-making, and maintaining focus on delivering valuable increments of work; ensuring that the Sprint Cycle remains productive and focused on achieving the Sprint Goal.

For more information, you can read the original blog post here.

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.

This week, I found a Reddit post from just about a year ago on clean code. The post is asking people basically how they feel about “clean code”, so I thought it’d be interesting to hear some people’s takes on clean code and what they may like or dislike about it. The post links an article, “Goodbye, Clean Code” and while I will really just be getting the Redditor’s thoughts/opinions on the article and their overall takes on clean code, I will still post this article at the end of the blog as well.

The top comment on the Reddit post tries to sum up the article by saying it’s more or less about not passing judgment on someone’s written code without knowing the tradeoffs first. Doing a quick read through of this article confirms this, which I believe is a great point to make. Code may not ALWAYS be the cleanest, but before you go ripping into the structure of it, you may want to try to understand it first. A reply to this comment, which was the most liked reply so probably the most agreed upon point, was that coders should write comments when a line or lines of code are dirty due to a tradeoff. This, I completely agree with. If the code is recognizably dirty and it’s due to something really out of your control, I find it perfectly acceptable to write a comment explaining this so there is no confusion.

Another comment I found, which was within a thread of comments, was talking about “Clean Code” written by Uncle Bob. We learned a lot about Bob’s ideas on clean code during class, which was very beneficial. I will note though, he came across as very strict and stubborn on the rules. A comment in this thread clarifies this though by explaining how Uncle Bob, very early on in chapter one, states that people may “violently disagree” with him and that’s completely okay. So while he may be stern under his own volition, he understands where some people may draw a line.

Reading through all of these comments, I came to realize that while yes, clean code certainly is important, it’s only important to a degree. There are going to be projects where you may not be able to keep the code super clean, and you should then shift focus to keeping it as clean as POSSIBLE, and perhaps commenting on areas where it just wasn’t possible. It also is not the end of the world as some people may make it out to be, if you are unable to keep it extremely clean.

https://www.reddit.com/r/programming/comments/180evou/what_is_your_take_on_clean_code/

https://overreacted.io/goodbye-clean-code/

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

Hello, this is my second blog post. Today I wanted to talk about something I learnt about in my Software Process Management class. The topic of this blog is two methodologies in software development; the waterfall method, and the Agile method.

For those who do not know, the waterfall method is a very “set-in-stone” methodology, where each part of the software development process is pre-determined with deadlines and time constraints. Something I dislike about this methodology is the lack of communication between the company and the people creating software for them. I think it is very important to have a strong connection during the whole process, not just the start and the end. The Agile method is more flexible. There are pre-determined steps, just like in the waterfall method, however, they are conducted in much shorter time intervals and repeated several times. This allows more communication between customers and developers.

In my opinion, both methodologies have their own uses, which is something we talked about during a class discussion. We were asked to speak about which methodology would be better in different situations. I think that for a large-scale community/government project (such as building a bridge), the waterfall method could be useful since a lot of communication is not needed with a certain customer. For projects where the developers are creating an app/product for a company, I think Agile outshines the waterfall methodology by far, due to the reasons listen in the above paragraph.

I also used this website to learn a bit more about both methodologies: Agile vs. waterfall project management | Atlassian

This website reinforced my ideas and outlook on both methodologies. It highlighted that in the waterfall method, you are unable to move forward without completely fulfilling the first “phase.” It also went into detail on how in the Agile methodology is more flexible than the waterfall methodology. The waterfall methodology is much less able to be changed in any way, and it is a very linear methodology. There are also some helpful images on this website which I would recommend checking out to visualize both methods!

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.