- The presentation is about choosing an open source license for a software project
- It emphasizes the importance of understanding your goals for the software release
- Factors to consider include how the software will be used, whether patent protection is desired, and who the users will be
- If the software needs to be part of a Linux system, a GPL2-compatible license is necessary
- The top 6 open source licenses are recommended for adoption to drive adoption and avoid the understanding tax
- Patents are also discussed, with the importance of consulting a patent lawyer and considering an express patent grant in the license
- A matrix categorizes the licenses based on copyleft vs permissive and patent grant vs none, narrowing down the license choices.

- Choosing a license narrows your options based on preferences along two axes
- Permissive licenses maximize adoption but provide no protection against competitors
- Copyleft licenses like GPL can prevent competitors from making software proprietary
- GPL is less effective for stalling competition due to cloud services
- AGPL is the strongest open source license for preventing competition
- Consider how people will use your software when choosing a copyleft license
- Mozilla Public License 2.0 is compatible with multiple copyleft licenses
- Consider factors like patents, adoption, competitive protection, Linux compatibility when choosing a license
- It is possible to change licenses but harder to move to a less permissive license
- License choice can be difficult, but making a reasoned choice is important
- Additional resources for learning about open source licensing include Blue Oak Council and COSS Media

- The speaker mentions a license picker on their website that helps with choosing a license
- They provide a link to a presentation on open source licensing basics
- They offer a free download of their book "Open Source for Business" on their website
- The speaker is also a venture capitalist and welcomes inquiries from open source businesses
- The speaker concludes the presentation and signs off as Heather Meeker.

- Importance of understanding goals for software release
- Factors to consider when choosing an open source license
- GPL2-compatible license required for Linux system
- Top 6 open source licenses recommended for adoption
- Consult patent lawyer and consider express patent grant
- Matrix categorizes licenses based on copyleft, permissive, and patent grant
- Permissive licenses maximize adoption but offer no protection against competitors
- Copyleft licenses like GPL prevent competitors from making software proprietary
- AGPL is strongest license for preventing competition
- Consider usage, patents, adoption, competitive protection, Linux compatibility when choosing a license
- License choice can be difficult but important
- Additional resources for learning about open source licensing
- Speaker offers license picker, presentation, and book on open source licensing
- Speaker is Heather Meeker, venture capitalist, and open to inquiries from open source businesses.

This video is about choosing an open source license for your software release. it is part of a series of narrated presentations on open source licensing by lawyer and venture capitalist Heather Meeker. This video is for anyone in business who wants to release their own open source software. It assumes you know the basics of open source software licensing, so if you need to refresh your knowledge, please see my video on the basics of open source software licensing.

Please note: This presentation does not constitute legal advice and does not create an attorney-client relationship. The principles presented here may not apply to the facts of your situation.

I'm a lawyer and venture capitalist who specializes in open source software licensing.

This presentation is about picking an open source license for your project.

Lots of business people ask me how to choose an open source license for their software.

This presentation assumes you know the difference between permissive and copyleft licenses.

If you need to learn more about that first, take a look at my presentation on the basics of open source licensing.

There is information on how to find that at the end of this presentation.

If you want to choose the right license, you need to have a solid understanding of your goals for your software release.

The purpose of this choice is to create a sustainable open source project.

If you are clear on your goals, the license will choose itself.

This presentation will walk you through how that works.

The next few slides mention some facts you should consider when determining your goals.

How do you expect people to use your software?

Will it be on-premises, software as a service, some combination of the 2, or some other use case like a hardware device?

Of course, there is not necessarily only 1 answer to that question, and the answer may change over time as your project grows, but you should answer based on your current plans.

The second important question is whether you intend to seek patent protection on the software you are going to release under the open source license?

If you are running a project for a non-profit purpose or for a hobby, you probably do not intend to seek any patent protection.

But if you are engaged in business, the answer might be different.

Although many developers start their project assuming they will never seek patent protection, they often revise this expectation as they build their business surrounding the project.

Traditional investors may push you to seek patent protection to prove the value of your technology.

It is important to understand what patent rights you are giving away in an open source license so you will not be surprised later to find that patents you might seek are not valuable.

In fact, it probably usually makes relatively little sense to seek patent protection on any open source software.

But that is ultimately a question for you and your patent lawyer to decide.

Your patents may claim inventions that can be implemented outside of the open source deployment, so they might still have value even if you grant the right to practice them under your open source license.

Another thing to consider is who your users will be.

If you are developing for use by large companies, you will find more resistance to copyleft licenses.

Also, if you are selling to customers in highly regulated industries, like finance or health care, you may be more likely to have to distribute your software to those customers, even if your product is fundamentally software as a service.

Customers in these industries often require local instances of software products for security and regulatory purposes.

If you are selling to small and medium enterprises, you will find less resistance to a copyleft license.

If you want To understand more about how companies view adopting open-source software developed by others, take a look at the Blue Oak Council open-source policy.

That policy represents a modal view of industry players on the use of open-source software.

There is more information about the Blue Oak Council at the end of this presentation.

The next important question is whether your software needs to be part of a Linux system.

If it does, and it needs to be included in the kernel.

You will have no option but to pick a GPL2-compatible license.

That's the most common kind of upstream limitation there is.

For instance, if you expect your project to be used as a plug-in to an existing proprietary product, GPL would not work well.

To make your license choice, you need to understand whether you are starting from complete flexibility of choice or if your choice is narrowed by upstream licensing concerns.

If you don't know, it's time right now to talk to your licensing lawyer to find out, before you make a license decision.

The rest of this presentation assumes that you have an entirely free choice.

Now let's talk about the kinds of open source licenses you might choose.

You might have heard that there are lots of open source licenses, too many to understand.

The Open Source Initiative, or OSI, is the organization that reviews licenses to certify that they are open source licenses, which means they meet the open source definition.

The OSI has approved over 100 licenses, but most of them are rarely used.

The 6 licenses listed on this slide are the top licenses used, and almost all open source software, probably over 99%, is 1 of these licenses.

The point of this slide is that if you are going to pick an open source license for your project, it doesn't make sense to choose any but the 6 listed here.

When you pick an open source license, you are trying to drive adoption.

People will adopt software only if they understand the license terms that apply to it.

If they don't, and they have to learn about the licensing before they can adopt the software, That will limit adoption.

I like to think of that as an understanding tax.

The understanding tax is acquiring the expertise, tools, or human resources for compliance.

If the understanding tax is too high, people will tend to choose other solutions.

Therefore, choosing an obscure or unusual open-source license is counterproductive.

There is rarely a reason to choose any but the ones listed on this slide.

Now let's talk a little bit about patents.

Open-source licenses come in 2 varieties, those that contain what we call an express patent license and those that say nothing about patent licensing.

If you have patents that read on the software you are going to release, a license with an express patent grant will give certain patent rights to any recipient of the software.

That means you won't be able to prevent those users from practicing your patents in the course of using your software under that open-source license.

That in turn means those patents will be hard to enforce in court.

If the license says nothing about patents, however, you may still be effectively granting some rights.

It is an understood tenet of the law that you can grant patent rights by implication.

In other words, if you hand some software to another person and you benefit from them using the software, such as by getting a license fee, a support fee, or a subscription fee, you may not be able to sue them for patent infringement, even if you don't expressly grant them any patent rights.

That's a legal doctrine called implied licensing or estoppel, and it can be a tricky legal question.

But because of the complexity of the legal question, you should always check with your patent lawyer before making a decision about adopting an open-source license on software on which you are prosecuting patents.

However, at least in my view, if you have patents to steward, an express license is preferable because an express license is more predictable.

No matter what you choose, you may end up arguing about whether you have granted patent licensing.

But at least if the license is express, you will be able to analyze its scope more concretely.

This element, whether you intend to seek patent protection, is a significant element to your license choice.

In sum, if you have patents to protect, you probably want to avoid older licenses without express grants like BSD, MIT, or GPL II.

This matrix shows you where the most common open source licenses fall on the 2 central questions of license choice, copy left versus permissive and patent grant versus none.

As you can see, for permissive licenses, there is really only 1 choice for each patent position.

You'll see that the BSD and MIT licenses are grouped together, and that's because there is no effective difference between them.

The Apache license, however, contains an Express patent grant.

Now let's look at the top of the slide where the copyleft licenses are categorized.

If you choose a copyleft license, you will have a further choice as to how strong the license should be.

Mozilla is also a choice, which usually comes up if you need additional compatibility, and we'll talk about that more in a moment.

But once you choose your preference along these 2 axes, your license choice is much narrower.

That's what I meant by the license choosing itself.

So now let's move to making a decision about copyleft versus permissive.

You can see that on this slide, I've removed the patent axis, so we're only looking at the copyleft versus permissive axis.

If you choose a permissive license, you will maximize adoption.

Most companies will adopt open source software under permissive licenses with little or no legal review.

For copyleft licenses, they may be more reluctant.

Remember what I said about the understanding tax?

Permissive licenses have virtually no understanding tax.

But those licenses provide you no protection whatsoever against competitors trading on your code, because anybody can do anything they want with permissively licensed software.

If you want to prevent your competitors from making your software proprietary in their own versions, Open source licenses can help with that to some degree, but they can't do it

The most you can do is place your software under a copyleft license like LGPL, GPL, AGPL, or Mozilla.

These licenses appear on this slide in the order of their copyleft strength.

As I mentioned, Mozilla is a file-based copyleft license.

That will do little or nothing to stop your competitors from trading on your code.

If they innovate, all they have to do is put their own changes into a separate file and they can keep that proprietary.

That's why it's called a weak copyleft license.

LGPL is pretty similar, but it is much easier to comply with when it's used with dynamically linked libraries.

So if a competitor wants to use your LGPL code, they're going to have to dynamically link it to their proprietary code.

And this might discourage them from competing with you a little bit, but not very much.

GPL is strong copyleft, which means that if your competitors used the code and distributed it, they would have to share their changes to the entire program.

This will have some use in keeping your competitors from making your code proprietary.

However, remember that open source licenses like GPL only have requirements if the recipient redistributes the code.

That means that any of your competitors can use this code in software as a service or other non on premises solutions, and they won't have to share their code at all.

Historically, GPL has been a pretty good choice for commercial open source applications.

It was very successful in driving people to get commercial licenses.

But what happened between the time MySQL was successful and today is cloud services.

So today, it's pretty easy to offer something as a cloud service and avoid distribution.

Accordingly, GPL is now much less effective for for stalling competition than it once was.

As a consequence, some companies that are doing commercial open source have turned to a Fero GPL.

A Fero GPL requires your competitors to share the changes to their code if they use the software for software as a service.

And this is the strongest open source license that you can currently choose.

If AGPL will not meet your needs, then an open source license won't work for you.

But copyleft licenses also have their costs.

Lots of companies are reluctant to adopt software under copyleft licenses and particularly AGPL.

So if you choose AGPL, you get the most effect of forestalling competition, but you may also significantly limit adoption.

Also, please make sure to consider how you expect people to use your software.

If your software is a whole program, then GPL might work pretty well for you.

But if your software is a library, GPL or AGPL might not make sense because people couldn't redistribute the software without violating your license.

So those are the copyleft licenses you have to choose from.

But I'd like to focus your attention on 1 of them, which is the Mozilla Public License

This is an interesting license because it is compatible with both GPL 2 and LGPL

and also with the Version 3 licenses, GPL-3, LGPL-3, and AferoGPL-3.

This compatibility can be helpful if you want to choose a license that maximizes copy left compatibility.

At this point you should understand the facts underlying each of these questions.

If so, you should probably pick a license with an express patent grant.

If so, you might want to consider a permissive license.

If you're seeking to maximize competitive protection, you're going to want to pick a copyleft license, but you should think about what your program is and how people will use it as a program or as a library.

If you need Linux compatibility, you need to pick a GPL2 compatible license.

And if you need both Linux compatibility and patent grants, well, MPL2 is the only choice that will do that for you.

As you can see, it's possible you might not get everything you need in 1 license, but these are the licenses that are available to you.

You may have noticed the version numbers that are attached to these licenses.

They bear on compatibility issues, which will likely be important to you only if you pick a copyleft license.

The issues there are a bit too detailed for this presentation, but if you have questions, don't hesitate to ask me.

My contact information appears at the end of this slide presentation.

Which license do you have in mind so far?

If you want to test your choice, you might take a look at my license picker.

This is a script that walks you through many of the same questions presented in this presentation, and you can check whether you think you picked the right license or not.

Now you might ask yourself, what if I get this choice wrong?

Well, obviously the consequences to your business could be significant.

It is possible to move from a less permissive license, like say, GPL, to a more permissive license like BSD.

So, if you get the decision wrong, you can change that later on.

But it's much harder to move from a permissive license to a less permissive license.

And the reason is that once you grant the rights, you can't take them back.

So when people want to change from a permissive license to a less permissive license, they will usually only do so if they're releasing a major revision of their software.

What that means for you is that if you get this decision wrong, you can iterate, but if you want to go to a less permissive license from a more permissive 1, you might not be able to iterate very quickly.

Now, there's 1 more point I want to make about your license decision before we wrap this up.

I have worked with scores of clients to pick an open source license, and it's usually a hard choice for them.

The more important the software is to you, the harder the choice will be.

So it's normal to feel anxious about the choice and even to have arguments with your co-developers about it.

But the best antidote for license choice anxiety is to make a reasoned choice, and I hope this presentation makes you more able to do that and be comfortable about your choice.

If you want to learn more about open source licensing, you might like to look at some additional resources.

The first item on this slide is the Blue Oak Council.

The Blue Oak Council is a group of open source lawyers that publishes materials about open source licensing that are free for you to use.

I'm 1 of the people who helps develop those materials.

Another thing you can take a look at is COSS Media, or commercial open source software media.

This is a site that has lots of useful materials, particularly

for people who are doing open source businesses.

And then you might recall that I mentioned the license picker on my site.

This license picker is an easy script that operationalizes some of the principles that we've talked about in this presentation so that you can go through a script to pick your license if you like.

And finally, if you need a refresher on how open source licenses work generally, particularly how to distinguish permissive and copyleft licenses, the last item on this slide is a link to a presentation about the basics of open source licensing.

If you want to know more about open source licensing in general, you can take a look at my book, Open Source for Business.

You can Download a free copy of the book if you go to my website, click on the Links tab, and follow the instructions there.

Also, as I mentioned, I'm a venture capitalist as well.

If you're looking for a venture investor that really understands the open source business, give us a call.

Well, I hope you've enjoyed this presentation on picking an open source license.


Speaker 0: Hello, this is Heather Meeker. I'm a lawyer and venture capitalist who specializes in open source software licensing. This presentation is about picking an open source license for your project. Lots of business people ask me how to choose an open source license for their software. But is that the right question?

Let's find out together. This presentation assumes you know the difference between permissive and copyleft licenses. If you need to learn more about that first, take a look at my presentation on the basics of open source licensing. There is information on how to find that at the end of this presentation. Are you ready?

So let's get started. If you want to choose the right license, you need to have a solid understanding of your goals for your software release. The purpose of this choice is to create a sustainable open source project. If you are clear on your goals, the license will choose itself. This presentation will walk you through how that works.

The next few slides mention some facts you should consider when determining your goals. How do you expect people to use your software? Will it be on-premises, software as a service, some combination of the 2, or some other use case like a hardware device? Of course, there is not necessarily only 1 answer to that question, and the answer may change over time as your project grows, but you should answer based on your current plans. The second important question is whether you intend to seek patent protection on the software you are going to release under the open source license?

This is a strategic legal question. If you are running a project for a non-profit purpose or for a hobby, you probably do not intend to seek any patent protection. But if you are engaged in business, the answer might be different. Although many developers start their project assuming they will never seek patent protection, they often revise this expectation as they build their business surrounding the project. Traditional investors may push you to seek patent protection to prove the value of your technology.

It is important to understand what patent rights you are giving away in an open source license so you will not be surprised later to find that patents you might seek are not valuable. In fact, it probably usually makes relatively little sense to seek patent protection on any open source software. But that is ultimately a question for you and your patent lawyer to decide. Your patents may claim inventions that can be implemented outside of the open source deployment, so they might still have value even if you grant the right to practice them under your open source license. Another thing to consider is who your users will be.

If you are developing for use by large companies, you will find more resistance to copyleft licenses. Also, if you are selling to customers in highly regulated industries, like finance or health care, you may be more likely to have to distribute your software to those customers, even if your product is fundamentally software as a service. Customers in these industries often require local instances of software products for security and regulatory purposes. If you are selling to small and medium enterprises, you will find less resistance to a copyleft license. If you want To understand more about how companies view adopting open-source software developed by others, take a look at the Blue Oak Council open-source policy.

That policy represents a modal view of industry players on the use of open-source software. There is more information about the Blue Oak Council at the end of this presentation. The next important question is whether your software needs to be part of a Linux system. If it does, and it needs to be included in the kernel. You will have no option but to pick a GPL2-compatible license.

That's the most common kind of upstream limitation there is. However, there can be others as well. For instance, if you expect your project to be used as a plug-in to an existing proprietary product, GPL would not work well. To make your license choice, you need to understand whether you are starting from complete flexibility of choice or if your choice is narrowed by upstream licensing concerns. If you don't know, it's time right now to talk to your licensing lawyer to find out, before you make a license decision.

The rest of this presentation assumes that you have an entirely free choice. Now let's talk about the kinds of open source licenses you might choose. You might have heard that there are lots of open source licenses, too many to understand. That's not exactly right. The Open Source Initiative, or OSI, is the organization that reviews licenses to certify that they are open source licenses, which means they meet the open source definition.

The OSI has approved over 100 licenses, but most of them are rarely used. The 6 licenses listed on this slide are the top licenses used, and almost all open source software, probably over 99%, is 1 of these licenses. The ones in red are copyleft licenses. The point of this slide is that if you are going to pick an open source license for your project, it doesn't make sense to choose any but the 6 listed here. When you pick an open source license, you are trying to drive adoption.

People will adopt software only if they understand the license terms that apply to it. If they don't, and they have to learn about the licensing before they can adopt the software, That will limit adoption. I like to think of that as an understanding tax. The understanding tax is acquiring the expertise, tools, or human resources for compliance. If the understanding tax is too high, people will tend to choose other solutions.

Therefore, choosing an obscure or unusual open-source license is counterproductive. There is rarely a reason to choose any but the ones listed on this slide.

Speaker 1: Now let's talk a little bit about patents. Open-source licenses come in 2 varieties, those that contain what we call an express patent license and those that say nothing about patent licensing. If you have patents that read on the software you are going to release, a license with an express patent grant will give certain patent rights to any recipient of the software. That means you won't be able to prevent those users from practicing your patents in the course of using your software under that open-source license. That in turn means those patents will be hard to enforce in court.

If the license says nothing about patents, however, you may still be effectively granting some rights. It is an understood tenet of the law that you can grant patent rights by implication. In other words, if you hand some software to another person and you benefit from them using the software, such as by getting a license fee, a support fee, or a subscription fee, you may not be able to sue them for patent infringement, even if you don't expressly grant them any patent rights. That's a legal doctrine called implied licensing or estoppel, and it can be a tricky legal question. But because of the complexity of the legal question, you should always check with your patent lawyer before making a decision about adopting an open-source license on software on which you are prosecuting patents.

However, at least in my view, if you have patents to steward, an express license is preferable because an express license is more predictable. No matter what you choose, you may end up arguing about whether you have granted patent licensing. But at least if the license is express, you will be able to analyze its scope more concretely. This element, whether you intend to seek patent protection, is a significant element to your license choice. In sum, if you have patents to protect, you probably want to avoid older licenses without express grants like BSD, MIT, or GPL II.

This matrix shows you where the most common open source licenses fall on the 2 central questions of license choice, copy left versus permissive and patent grant versus none. As you can see, for permissive licenses, there is really only 1 choice for each patent position. You'll see that the BSD and MIT licenses are grouped together, and that's because there is no effective difference between them. The Apache license, however, contains an Express patent grant. Now let's look at the top of the slide where the copyleft licenses are categorized.

If you choose a copyleft license, you will have a further choice as to how strong the license should be. The variations are GPL, LGPL, and AGPL. Mozilla is also a choice, which usually comes up if you need additional compatibility, and we'll talk about that more in a moment. But once you choose your preference along these 2 axes, your license choice is much narrower. That's what I meant by the license choosing itself.

Speaker 0: So now let's move to making a decision about copyleft versus permissive. You can see that on this slide, I've removed the patent axis, so we're only looking at the copyleft versus permissive axis. If you choose a permissive license, you will maximize adoption. Most companies will adopt open source software under permissive licenses with little or no legal review. For copyleft licenses, they may be more reluctant.

Remember what I said about the understanding tax? Permissive licenses have virtually no understanding tax. But those licenses provide you no protection whatsoever against competitors trading on your code, because anybody can do anything they want with permissively licensed software. If you want to prevent your competitors from making your software proprietary in their own versions, Open source licenses can help with that to some degree, but they can't do it

Speaker 1: perfectly. The most you can do is place your software under a copyleft license like LGPL, GPL, AGPL, or Mozilla. These licenses appear on this slide in the order of their copyleft strength. As I mentioned, Mozilla is a file-based copyleft license. That will do little or nothing to stop your competitors from trading on your code.

If they innovate, all they have to do is put their own changes into a separate file and they can keep that proprietary. That's why it's called a weak copyleft license. LGPL is pretty similar, but it is much easier to comply with when it's used with dynamically linked libraries. So if a competitor wants to use your LGPL code, they're going to have to dynamically link it to their proprietary code. And this might discourage them from competing with you a little bit, but not very much.

GPL is strong copyleft, which means that if your competitors used the code and distributed it, they would have to share their changes to the entire program. This will have some use in keeping your competitors from making your code proprietary. However, remember that open source licenses like GPL only have requirements if the recipient redistributes the code. That means that any of your competitors can use this code in software as a service or other non on premises solutions, and they won't have to share their code at all. Historically, GPL has been a pretty good choice for commercial open source applications.

Remember MySQL? It was very successful in driving people to get commercial licenses. But what happened between the time MySQL was successful and today is cloud services. So today, it's pretty easy to offer something as a cloud service and avoid distribution. Accordingly, GPL is now much less effective for for stalling competition than it once was.

As a consequence, some companies that are doing commercial open source have turned to a Fero GPL. A Fero GPL requires your competitors to share the changes to their code if they use the software for software as a service. And this is the strongest open source license that you can currently choose. If AGPL will not meet your needs, then an open source license won't work for you. But copyleft licenses also have their costs.

Lots of companies are reluctant to adopt software under copyleft licenses and particularly AGPL. So if you choose AGPL, you get the most effect of forestalling competition, but you may also significantly limit adoption. Also, please make sure to consider how you expect people to use your software. If your software is a whole program, then GPL might work pretty well for you. But if your software is a library, GPL or AGPL might not make sense because people couldn't redistribute the software without violating your license.

Speaker 0: So those are the copyleft licenses you have to choose from.

Speaker 1: But I'd like to focus your attention on 1 of them, which is the Mozilla Public License

Speaker 0: 2.0.

Speaker 1: This is an interesting license because it is compatible with both GPL 2 and LGPL

Speaker 0: 2.1

Speaker 1: and also with the Version 3 licenses, GPL-3, LGPL-3, and AferoGPL-3. This compatibility can be helpful if you want to choose a license that maximizes copy left compatibility.

Speaker 0: Now here's a recap of all your choices. At this point you should understand the facts underlying each of these questions. Are you seeking patents? If so, you should probably pick a license with an express patent grant. Are you seeking to maximize adoption?

If so, you might want to consider a permissive license. If you're seeking to maximize competitive protection, you're going to want to pick a copyleft license, but you should think about what your program is and how people will use it as a program or as a library. If you need Linux compatibility, you need to pick a GPL2 compatible license. And if you need both Linux compatibility and patent grants, well, MPL2 is the only choice that will do that for you. As you can see, it's possible you might not get everything you need in 1 license, but these are the licenses that are available to you.

You may have noticed the version numbers that are attached to these licenses. They bear on compatibility issues, which will likely be important to you only if you pick a copyleft license. The issues there are a bit too detailed for this presentation, but if you have questions, don't hesitate to ask me. My contact information appears at the end of this slide presentation. Here's the matrix again.

Which license do you have in mind so far? If you want to test your choice, you might take a look at my license picker. This is a script that walks you through many of the same questions presented in this presentation, and you can check whether you think you picked the right license or not. Now you might ask yourself, what if I get this choice wrong? Well, obviously the consequences to your business could be significant.

But I'll mention 1 thing to think about. It is possible to move from a less permissive license, like say, GPL, to a more permissive license like BSD. So, if you get the decision wrong, you can change that later on. But it's much harder to move from a permissive license to a less permissive license. And the reason is that once you grant the rights, you can't take them back.

So when people want to change from a permissive license to a less permissive license, they will usually only do so if they're releasing a major revision of their software. What that means for you is that if you get this decision wrong, you can iterate, but if you want to go to a less permissive license from a more permissive 1, you might not be able to iterate very quickly. Now, there's 1 more point I want to make about your license decision before we wrap this up. It's a difficult choice. I have worked with scores of clients to pick an open source license, and it's usually a hard choice for them.

The more important the software is to you, the harder the choice will be. So it's normal to feel anxious about the choice and even to have arguments with your co-developers about it. But the best antidote for license choice anxiety is to make a reasoned choice, and I hope this presentation makes you more able to do that and be comfortable about your choice.

Speaker 1: If you want to learn more about open source licensing, you might like to look at some additional resources. The first item on this slide is the Blue Oak Council. The Blue Oak Council is a group of open source lawyers that publishes materials about open source licensing that are free for you to use. I'm 1 of the people who helps develop those materials. Another thing you can take a look at is COSS Media, or commercial open source software media.

This is a site that has lots of useful materials, particularly

Speaker 0: for people who are doing open source businesses. And then you might recall that I mentioned the license picker on my site. This license picker is an easy script that operationalizes some of the principles that we've talked about in this presentation so that you can go through a script to pick your license if you like. And finally, if you need a refresher on how open source licenses work generally, particularly how to distinguish permissive and copyleft licenses, the last item on this slide is a link to a presentation about the basics of open source licensing. If you want to know more about open source licensing in general, you can take a look at my book, Open Source for Business.

You can Download a free copy of the book if you go to my website, click on the Links tab, and follow the instructions there. Also, as I mentioned, I'm a venture capitalist as well. If you're looking for a venture investor that really understands the open source business, give us a call. We'd love to talk to you. Well, I hope you've enjoyed this presentation on picking an open source license.

This is Heather Meeker, signing off.

See all Heather Meeker transcripts on Youtube

How to Choose an Open Source License