Category Archives: Week 4

Learning the Basics of Software Copyrighting and Licensing

When I first started studying how code and software is protected by law, I was lost. I’d never explored the realm of who owns what, or when one can utilize another’s code. I decided to delve further into these concepts after I was inspired to by a software development course.

I came across two fantastic pages on TechTarget, one on software licenses, and the other on copyright (1,2), that covered many topics of software law, including what licenses and copyrights are, do, and where they come from. Through reading these pages, I developed a better understanding of the these legal topics.

Licenses

Licenses are contracts between the people who developed or own the software, and the people or organizations who want to use the software. They cover how the software can be used, what the rights of the owners are, and what the users are allowed to do with the software. They can also include how the software is paid for, how many copies can be downloaded, or what level of access to the source code users can have.

This image from TechTarget gives an overview of strictness of different types of software licenses. To apply a license to software, the legal text of the license must be included with the software when shipped. This can be accomplished by including a file called “License” that contains the legal text alongside your software.

Obtaining a license from the software owner generally involves paying the owner to use the software. An example of this exchange is when someone purchases a video game. The person pays the price of the game, accepts the end-user license agreement upon loading the game up, and can then use the software forever.

This concept of payment for license is essentially the same when scaled up for business applications. One company can pay a software company for the license to utilize their software. This will likely cost more money than purchasing a video game, and can potentially involve other stipulations depending on license choice.

Copyrights

Copyright prevents others from copying or otherwise exploiting your creations, but works differently than licensing. For one, copyrighting in most countries, including the USA, is automatic. When software is written, the developer, or company the developer works for, automatically gains copyright over that work. This prevents others from stealing, reusing, or altering the work without permission. The copyright holder can also formally apply for a copyright with their country’s relevant organizations.

Interestingly, copyright can have a time limit in terms of years, with some companies, such as Disney, fighting to lengthen or alter the laws to allow them to protect their original mouse design for as many years as possible.

One huge difference with copyrighting is that someone else can use parts of your work legally without specifically asking you or your company. This is called “Fair-Use” by the non-owner, and includes uses such as for criticism and comment, parody, education, public good, and non-commercial activities.

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

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

The World of Software Licenses

 This week in class, we discussed what goes into licensing a piece of software, along with copyright law. If I am being perfectly honest, this wasn’t what I was expecting to study in this class, though it makes sense, in a way. Licensing, as I have learned, is a very important part of software development, and knowing who owns what, and defining who can do what with your code ties in pretty well to the other topics we’ve been discussing in class. As such, I’ve taken a look at an article from A List Apart, which is a blog that specializes in having many writers from the Computer Science industry comment on various issues and topics. I’ve chosen the article: “Considering Open Source Licenses”, which talks about one of the things most interesting (and confusing) to me in terms of licensing, Open Source Licenses.

One would think that making software open source would be as simple as declaring it as such. However, in the real world, it’s a little more complicated than that. What you really need to do is to attach a license to your software that describes what can be done with it, and there are several different licenses you can choose from, all with different requirements and specifications. Most of the licenses discussed in the article are, what else, open source licenses. All of them do functionally the same thing, allow people to use your software and edit it as they see fit. However, they all have slightly different specs that are important to keep in mind. The MIT license for instance, only requires you to keep the original license in tact, and attach a copyright notice to your project if it uses code that has the MIT license attached to it. GPL, on the other hand, requires you to document modifications made to the software, whether that be through traditional documentation or how-tos on how to use the software. The article also discussed in brief, some of the problems that occur if you were to violate a license, which isn’t something that was discussed in class, and was something I found interesting.

The article makes it very clear that nothing covered is concrete legal advice, and of course, I am no lawyer either. That being said, licensing isn’t nearly as difficult as I once thought, I was under the impression it was similar  to filing a patent, or some other legal document. I am happy to be wrong, in this case, and for any software I develop in the future, I will be sure to put some more though into licensing in the future!



(Side note: It has occurred to me that I am absolutely TERRIBLE at spelling the word license. I’ve spelled it so many different ways in the writing of this post it is almost comical. I also appreciate the fact that copyleft is a genuine term, since I was only familiar with copyright)


ARTICLE LINK: https://alistapart.com/article/considering-open-source-licenses/



From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.