Hi students.
So in this part of the video lecture,
I want to talk a little bit about licensing how software licenses are used.
This is an important part of Lennox software development,
because we've already talked about some of the freedoms that you're granted.
And some of the ability that you have based on the access to the source.
So what the licensing tells you are your obligations based on being granted,
those freedoms.
And there are different types of software licensing,
will go over some of the different types.
And then we'll talk about the license that are specifically used often with
Lennox development and talk about how to contribute to the open source software.
So you may have heard the expression about free as in freedom not free, as in beer.
And so the word free is sort of overloaded in the english language.
You can be talk talking about freedom like your abilities not being
restricted your abilities to do things be you're being free to do something.
Or you can talk about things not having any cost.
And so that's the free, as in beer where if someone's giving away free beer,
what they mean is they're not going to charge you any money to get the beer.
And so what we talk about when we're talking about licensing for
Lennox, we're talking about the first definition of free.
The free as in Freedom.
So you have the freedom to obtain and you have the freedom to modify the source code
as long as you follow, follow the stipulations in the license.
There are two basic categories of licensing for open source software,
and the first is what will refer to as permissive licenses.
So in other words, these are licenses that give you the freedom to obtain and
modify the source.
But with relatively few limitations that you have based on your
modifications to that source code.
Two examples of permissive licenses that you'll see on open source software.
RBSD, which stands for Berkeley Software Distribution and MITT, which stands for
massachusetts Institute of Technology.
So these are original software licenses that came about from each one of these
academic institutions during the early days of open source software development.
And the basic premise of permissive licenses is that you can use the code,
you can modify the code.
And you don't necessarily need to share those modifications or
the source code that you incorporate them into with your customers
if you're developing an embedding mimics device.
So this is important in some scenarios because if you're working for
a company and they're developing their own proprietary intellectual property.
You wouldn't want to necessarily make restrict the company in the way that would
make them need to share all the details of their intellectual property as a part of
using some software.
So on the other side of permissive licensing is what's
called copy left licensing.
And it's kind of a play on the word copyright.
Where what it's saying is that if you incorporate the license,
this license material into your work with some limitations.
You typically need to share the content of the overall system that you're building is
based on that.
So two examples are the main example of the copy left license that's used
with Lennox is the GPL or the new public license.
So what does this mean?
It means that if you use the GPL and you use GPL licensed software,
your customers that buy your product.
And by virtue of the open nature of the Internet, essentially,
you need to plan on, everyone would get access to the source code.
If the source code that you developed is what's considered a derivative work.
So the definition of derivative work involves maybe more legal terms,
then we're going to come and be able to cover in this course.
But what it really means is if you're modifying an application that's GPL
licensed.
You're going to have to share the content of those modifications in order to comply
with license terms.
So, here's an example of a permissive license in this case, an MIT license.
So this shows some of the typical things that you'll see in a software license.
So first it goes over your rights as a user of the software.
So, some of the things to look for here, I can modify the software,
I can distribute the software, I can sell the software.
So this is telling me all the things that I can do as a user of the software.
And then this tells me what you know, if I'm going to use the software for
the terms of the license, what do I have to do?
And in this case, what it says is the above copyright notice.
And this permission notice shall be included in all copies are substantial
portions of the software.
So I need to make sure that I include the copyright information that's
associated with the license, say, who developed this software.
And I need to pass on the permission notice that
is given here in this document.
And then it also covers the limitation as a user that you need to pass on to your
users as well for the use of the software.
And, and the basic, you know,
nonlegal layman's description of this is if it doesn't work, don't sue me.
Right? So
what this is saying is that the copyright holder is letting you use it for
whatever purpose you want.
As long as you give them attribution in the form of notifying that you're using
their copyright and as long as you free them from liability.
And you pass that along to your customers to let them know that the original soft.
They can't go back and sue the original copyright holder if there's something
doesn't work in this office.
Two examples of licensing that are used in Linux software development
that are the copy left variety are L G P L and G P L.
So L GPL is typically used for software libraries.
So, for instance, GCC libraries and these allow you to link to a proprietary
application without needing to share the source code of your applications.
So, you see this used for things like gcc libraries.
This allows you to build your software with GCC calls something like Prune F.
And not have to worry about having licensing restrictions apply to
your application that you built based on that call to a library
that's included as part of GCC.
But what it does say is that if you needed to make some change to a print F function
or to something that's a part of the GCC library.
You would be legally obligated to share that change
when you distribute the ultimate application.
So for GPL based software, like what is used for the links,
Colonel GPS I mentioned before is considered a copy left license.
In other words, if you incorporate in any way the source code of that
GPL licensed software into your software.
Your software is also bound by the terms of the GPL,
meaning that you would need to distribute its source code to customers.
There are different versions of the GPL.
However, you'll see that reference in GPL, version two versus version three.
The Tebow that we mentioned earlier as being one of the first Lennox hardware
devices did some change.
Which meant that they could, meet the spirit of the GPL or
meet the requirements of the GPL.
Version two by publishing all their source code, but not allow
the customer to modify the source code and then run it on their hardware.
So they put some limited restrictions and hardware, which meant that their
hardware could only run the specific Lennox in binary that they created.
And not something else that would be created by someone else using their source
code as a reference.
And there was some consternation in the community about whether that was
an appropriate and valid use of the license.
And so part of the newest revision of GPL or
GPL V three specifically prevents that that use case.
In other words, it says that not only must you share all your source, but
you also must not restrict the ability of the user to change the source and
run it on your hardware.
However, importantly, the Lennox Colonel has not incorporated GPL version three.
So the Colonel still uses the version two of the license that
allows the type of implementation that Tebow did that shares the source code.
But does not necessarily make it possible for
customers to update with their own source code on your device.
So what do we mean when we talk about contributing to open source community?
And what are some of the things that go into contributing, open source software?
I mentioned before that there are groups that are associated with each software
application.
In terms of Lennox application development, there's groups that
are associated with each specific sub component of the Linux kernel.
And contributing to open source for
those groups typically means that you're going to be communicating with others,
probably in written fashion and most likely over open forums.
So you're going to be using things like mailing lists to interact with a bunch of
people that have some stake in the development of whatever software you're
talking about.
So this means that you're going to need to be responding to questions
about your code.
You're going to need to ask good questions when you need help from others.
And you're going to have to follow detailed and
specific submission rules about how to submit changes for
whatever project you happen to be trying to contribute to.
And I want you to think about making open source contributions as especially as
a part of your final project.
And how you could maybe leverage that in terms of advertising your,
your own skills.
So this is the kind of thing that you should be able to ultimately put on your
resume, the fact that you contributed to some open source project.
And each, as I mentioned before,
each project has their own rules about how to contribute.
And so, if you want to see the type of detail that's included in this,
here's a link to how to contribute to the Linux kernel that you can use for
more information about.