Introduction

The blog, “A Short Guide to Open Source Licenses,”by David Skaife, helps us understand the often confusing world of open source licenses. Let’s break down the key points to make sense of why these licenses matter in the world of computer software.

Understanding Open Source Licenses

Open-source licenses are like rules for sharing computer code. They tell us how we can use, share, and change the source code. These rules help protect the original creators and make it easier for others to use the code without asking for permission each time.

Clearing up Myths: Public Repositories and Licensing

Skaife talks about a common misunderstanding of just putting code on a public platform, like GitHub, doesn’t automatically make it open source. Without a clear set of rules (license) with the code, it’s still protected by copyright, and others can’t freely use or change it. So, it’s crucial to attach a license if you want others to use your code.

Making Sense of Licenses

Skaife acknowledges that there are many licenses, but he suggests focusing on a few popular ones. He also mentions the Open Source Initiative (OSI), which approves licenses, making it easier for us to choose from reliable options.

License Types: Strict vs. Flexible

There are two main types of licenses – strict (copyleft) and flexible. Strict licenses say that if you change the code, your new version must also follow the same rules. Flexible licenses are more relaxed, letting people use, change, and share the code more freely.

Exploring Five Common Licenses

There are five common licenses we might choose from:

1. MIT License: Simple and flexible, allowing changes with few conditions.
2. Apache License 2.0: Similar to MIT but a bit more complicated, addressing specific issues like trademark rights.
3. GNU General Public License (GPL) v2.0 and v3.0: Strict licenses, ensuring all changes follow the same rules, with v3.0 adding more details.
4. GNU Lesser General Public License (LGPL) v2.1 and v3.0: Less strict than GPL, allowing some exceptions for linking.
5. Berkeley Software Distribution (BSD) 2-clause and 3-clause variants: Flexible licenses, similar to MIT, with the 3-clause version having extra rules about using contributors’ names.

conclusion

Skaife’s guide helps us navigate open source licenses, making it easier to understand the rules for sharing and using computer code. With this knowledge, anyone working with open source software can feel more confident contributing, using, or creating, fostering a collaborative and innovative community. For those wanting more information, Skaife suggests checking out resources like the Open Source Initiative’s licenses pages and GitHub’s “choosealicence.com.”

reference

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Earlier in the semester, we discussed licenses and copyright in regards to our code and documentation. I’ve wanted to write a post on licenses, but finding a post that did more than describe the definitions and uses of licenses was difficult. Luckily, I have found a blog that describes software license management, the best practices, and some drawbacks when managing licenses. From those sections, I want to highlight the parts that felt the most important. The blog is called, “Seven Best Practices for Managing Software Licenses” by Ibrahim Ogunbiyi, a data scientist and IT support specialist.

The post starts off with defining software license management as the process of controlling, tracking, auditing, and managing the use of software in an organization. They highlight the importance of using SLM in many ways, but the one that stood out to me was to ensure the software is secure and has no malicious code. If there is no liability in the rights listed by the license or the lack of one, I can imagine how it would be important to sift through each one to ensure the code is safe to use. Another one that felt important was keeping track of software due dates. Having your team or company rely on access to software only to have it pulled from you could be expensive and time wasting. If you fail to stop after your access is revoked, you could be held liable and sued.

The potential setbacks of SLM were the cost, complexity, and compliance risk. In an organization or large company dealing with a myriad of different license types and potentially using them in combination with each other, I can see how those issues could come up.

The best practices discussed in the post that I found most important were documentation and training. Any issues that arise when dealing with license issues would be incredibly hard to fix if you cannot find relevant information. Keep track of everything, within reason. I have worked in a company that had one person in our location who was fully trained to use the company’s software. She was berated with questions about how it worked without every employee getting a full understanding of the system. She was the linchpin. After she left, so many things fell through the cracks and I can only imagine how detrimental that could be when dealing with licenses. Making sure everyone is on the same page with a full understanding of how licenses work will save companies a lot of time and money.

After reading this post, I felt like this would be especially helpful for people starting their own company. Understanding the complexities and importance of software development can only help in the future. Although I do not feel like I will be making decisions on implementing a software management system anytime soon, I will still keep what I learned in mind when dealing with licenses.

The blog post: https://www.wrangle.io/post/seven-best-practices-for-managing-software-licenses

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

Recently our class discussed inclusive language and delved into tools that are able to root out non-inclusive language. I tried to find an article or blog that gives a set of examples to watch out for. I found a blog post that gives guidelines, examples of non-inclusive language, and provides examples of how companies are adapting to make their language more inclusive. The blog post is called, “Inclusive Language in Technology” by Barathy Rangarajan, DreamWorks Animation.

            The blog post starts with giving a definition of inclusive language. It highlights the difficulty in changing language across repositories and identifying what is seen as non-inclusive language. Before diving into those offensive terms, they give four guidelines when writing code or documentation. These guidelines were: avoid using terms that have social history, avoid using idioms and jargons, write inclusive examples, and if you’re unsure, ask. I personally liked the inclusion of idioms and jargon being something to watch out for and how important it is to ask if you are unsure. Usually, idioms and jargon are just ingrained in the language we use based on where we are. Being aware of that when writing code or documentation for people who may not understand felt important. Understanding that these terms can be tricky to identify as non-inclusive, it’s important to ask those who might know more.

The post then gives a set of terms deemed non-inclusive, organized by different categories. These categories were, socially charged, gendered, ableist, ageist, and violent language.  I won’t get into detail about each, but I recommend you take a look to familiarize yourself with the terms and alternatives. There were some terms I was not aware of.  

The final portion of the article is the how companies have made changes to be more inclusive. They described how Autodesk, DreamWorks, and Sony pictures are addressing non-inclusive language. Some involve hiring based off race and gender, promoting resource groups, and setting a baseline initiative to produce inclusive code in the future and update older code. In one of my previous posts, I talked about setting ground rules that the team can agree on when conducting ourselves during development and discussions. I feel this is also relevant when it comes to inclusive language.

The blog post shed some light on the best practices and popular terms used when addressing inclusive language. In the future I will strive to be self-aware about how I write, ask question when I don’t know, and use what I’ve learned in day-to-day interactions along with writing code.

Link to the blog: https://www.aswf.io/blog/inclusive-language/

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

What is a Dev Container?

A Dev Container, or development container, encapsulates a complete development environment accessible through Secure Shell (SSH) in your preferred Integrated Development Environment (IDE). It overcomes workflow impediments such as low performance and limited bandwidth by providing an isolated environment with standardized configuration stored in a .devcontainer.json file. This JSON file, structured with Comments (jsonc) metadata, allows customization for specific needs, such as adding tools or extensions.

Why Use it?

Addressing Setup Configuration Issues: Maintaining and managing local environments involves the use of various tools and configurations, leading to a cumbersome process. Standardizing this process with a unified approach can significantly save time and streamline setup configurations.

Standardizing Build Instructions of the Project: Documenting dependency upgrades and changes can be challenging. Utilizing code rather than extensive documentation simplifies the process, enabling anyone to ship without being hindered by the “it works on my machine” dilemma.

Ensuring Isolation of Development Environments: Developers often work on multiple projects simultaneously, each with its own complexities. Isolating environments prevents conflicts with other software on the host system, creating a clean, controlled space for development tasks.

Enabling Consistency Across Development Teams: Achieving portability across diverse teams is complicated by varying technologies and configurations. Implementing a standardized development environment ensures uniform configurations among team members, minimizing inconsistencies from individual machine differences.

Simplifying Onboarding and Training Processes: Quickly launching environments in isolation facilitates learning new languages or frameworks. This approach is particularly beneficial for onboarding and training processes, keeping machines clean and allowing for smooth presentations and workshops, where everyone can follow along without interruptions caused by missing tools or confusion mid-step.

Dev Containers in Real World Enviroment

1. Standardized Development Environments:
   • Dev Containers provide a standardized and reproducible development environment, ensuring that all team members work with the same configuration. This minimizes the “it works on my machine” issue and streamlines collaboration.
2. Setup Configuration Management:
   • Addressing setup configuration issues is simplified with Dev Containers. They help in managing dependencies, tools, and configurations uniformly, reducing the time and effort required for setting up development environments.
3. Version Control Integration:
   • Dev Container configurations are often stored in version control systems (e.g., Git), ensuring that the development environment is versioned along with the code. This enhances collaboration and makes it easier for team members to switch between branches or versions seamlessly.

Personal Experience

Dev Containers are something I have recently just learned about, and I feel like the need for them is understated. The overall idea behind such a tool is to create a simple and consistent environment for a team to work in. Anytime I work on a project, I stress the need for one as it eliminates many common problems teams face in the early stages of development. I also believe that when I start my professional journey, I will find these containers to be more standardized within the teams I work with.

Sources:

https://www.freecodecamp.org/news/standardize-development-environment-with-devcontainers/

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

What is SCRUM?

Scrum is an agile project management and product development framework that provides a flexible way to manage and deliver complex projects. It is widely used in the software development industry but has also been applied to other fields. Scrum emphasizes collaboration, adaptability, and iterative progress.

SCRUM Values:

1. Commitment:
   • Team members commit to achieving their goals and delivering value.
   • Commitment involves dedication to the team’s objectives and a willingness to do whatever it takes to achieve them.
2. Courage:
   • Team members have the courage to question the status quo and make improvements.
   • Courage also means being honest about work progress and challenges, even when it’s difficult.
3. Focus:
   • The team concentrates on delivering a small set of high-priority items at a time.
   • Focus helps prevent distractions and ensures that the team delivers incremental value consistently.
4. Openness:
   • Team members and stakeholders are open about their work, challenges, and progress.
   • Openness promotes transparency, collaboration, and the ability to adapt to changing circumstances.
5. Respect:
   • Team members respect each other’s expertise and perspectives.
   • Respect fosters a positive and collaborative team environment, where individuals feel valued and supported.

These principles guide the Scrum Team in their interactions and behaviors, contributing to the framework’s effectiveness in delivering valuable products and managing projects in a dynamic and adaptive manner.

Why Scrum?

1. Simultaneous Development: Scrum promotes concurrent rather than sequential development, allowing programmers to code dynamically without waiting for all details to be clear.
2. Adaptability: Scrum supports ongoing project adjustments, with a variable scope while maintaining constant time and cost, contrasting traditional approaches.
3. Prioritization: Tasks are prioritized by importance, releasing completed segments in sprints, leading to faster market availability compared to traditional end-of-project releases.
4. Team Collaboration: Scrum emphasizes a close-knit development team (usually 5-9 members) with a collective responsibility for completing prioritized work. Pair programming enhances coding efficiency and quality.

Thoughts on Scrum

Despite having limited time to engage with the Scrum process, it swiftly emerged as a vital tool for me. As a self-professed procrastinator, I’ve discovered that I thrive under specific conditions. Collaborative teamwork improves my productivity, planning provides structure and deadlines, and visualizing goals, such as addressing issues, implementing fixes, and managing to-do lists, keeps me consistently focused. The daily stand-ups in Scrum are particularly noteworthy; they serve as an valuable asset for connecting with my team, offering support and advice, and seeking guidance when needed.

Sources:

https://www.atlassian.com/agile/project-management/scrum-values#:~:text=Scrum%20is%20a%20set%20of,solving%20and%20reducing%20project%20timelines.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

A few weeks ago, I learned about the necessity of publishing code under a license and now that I have had the chance to implement proper licensing into assignments that I have been tasked with, I wanted to take a second and closer look at the positives and negatives associated with publishing software as “Open Source” as opposed to under commercial licensing. Before writing this blog post, I did some research and came across a blog titled, “Open Source vs. Commercial Software License: What Do You Need?” by Frank Amissah, which does a good job comparing and differentiating open-source licensing from commercial licensing. 

OPEN SOURCE:

Open source code is source code that has been made available to the public for free, allowing for anyone to read, share, or modify it. Open software licensing is divided into two categories, these being “Permissive” and “Copyleft”. Permissive licensing is less restrictive, allowing people to do as they please with the code, often only requiring the original author to be credited. Copyleft licensing is more restrictive, requiring future redistribution of code under a copyleft license to also abide by the terms of the originally implemented copyleft license. Open source code is easily accessible and adaptable by a community. The ease of acquiring the code also allows for a large scale of quality improvements and innovation provided by the community to be officially implemented. This, however, comes as a downside being that there is very limited funding for the future development of the code and if its users lose interest, it will ultimately be abandoned entirely.

COMMERCIAL LICENSING:

Commercial licensed software is usually proprietary and is distributed with the intent of its developer making a profit. The terms of use of the software is identified directly by the developer, but in general, licenses for their use will exist in the forms of subscription services or one-time payments, either for one user or an entire team of users. Benefits of using a commercial license include establishing direct ownership of the software for its users, as well as constant funding for improvements through the purchasing of copies of the software. On the other hand, commercial licenses often cost a lot of money to their customers, have longer development cycles for implementing changes, and suffer highly from piracy of the software. 

This blog post effectively compared the similarities and differences of both open source and commercial licensed software, even going so far as to teach me that the choice for which license to implement will come down to the goals of the project, as well as its intended audience and cost of operation. It was also formatted in a very user-friendly way, using well-organized diagrams to prove its point. Going forward, I feel that I will be more inclined to take my time weighing my choices when it comes to choosing the right license for my projects, especially now that I have been made aware of the difference one can make.

Blog Referenced: Open Source vs. Commercial Software License: What Do You Need? | Turing 

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

Recently, I have been made aware of a “Alex” linter, which is capable of analyzing the words used in a program and identifying ones that may be offensive or used in a harmful context. This got me interested in looking further into what other forms of software are being used to perform similar actions and where. 

In order to learn more on the topic, I have read a blog titled, “Microsoft claims its new tools make language models safer to use” by Kyle Wiggers. This article goes in depth about how Microsoft has been developing open-source tools to audit AI generated content and automatically test them for potential bugs, especially in a content moderation context, where “toxic speech” may be used. Microsoft has focused their efforts on two projects for this cause.

ToxiGen is a dataset that contains 274,000 examples of statements that may be considered “toxic” or “neutral”, acting as a massive hate speech dataset and functioning in a similar but much greater scale of what the “Alex” linter does. ToxiGen is being used by researchers on LLMs similar to ChatGPT to generate statements that are likely to be misidentified and aid in finding potential weaknesses in these generative tools. 

AdaTest is the second program Microsoft is focusing on developing and should help address larger issues with AI language modules. It functionally generates a large number of tests, steered by human guidance, and organizes them into similar groupings. It is run with the goal of adding diversity to test cases and enhancing the reliability of LLMs. 

From my perspective, generative AI does not possess cognitive function in a comparable manner to that of a human and until it does, AI will forever struggle at identifying speech that may be acceptable in one context or culture but viewed as very offensive in a separate culture or environment. I also believe that because these newly developed programs are being made in the same way that the “Alex” linter is (that being through someone providing a list of key words or phrases to be cross referenced) and is not able to generate its own list of potentially harmful or “toxic” terms without human oversight, the most these programs will likely be able to do is provide quality standards for LLMs through testing. 

Through my research, I became aware of programs being developed by Microsoft to help detect harmful speech in a similar way that the “Alex” linter does (that being through cross referencing with a dataset). I also became aware of the many forms of biases that exist even in generative AI as a result of information provided by biased human input. Moving forward, I plan on being more careful with the phrasings I give or artificially generated when working on projects. Given that AdaTest is an open-source software as well, I am interested in using it in the future to test for bias and offensive speech wherever I use generative AI.

Blog Referenced: Microsoft claims its new tools make language models safer to use | TechCrunch

From the blog CS@Worcester – CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

https://opensource.com/resources/what-open-source 

https://firefox-source-docs.mozilla.org/overview/gecko.html

https://opensource.com/article/19/8/everyday-tech-runs-linux

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