Return to Answer

Choose your licence

If your code has been closed source up to now, the first thing you should do is decide on which open source license (GPL <=2, GPL 3, LGPL, BSD, Eclipse etc.) you want to use.

There are pro's and cons to each, so read up on what restrictions they place on the code and decide who you want to be able to use it. Warning, whichever you choose someone will complain - this is holy war territory, and beyond the scope of this question.

• A great resource for determining which license is the right license for you is the very comprehensive, interactive license differentiator, from Oxford Universities OSS Watch.

Sanitise your repository

If the code in your repository doesn't already have your chosen license applied to it, I would go through your entire revision history so far and retroactively apply it (this may require a re-base at every point where a new source file is introduced). This will, however produce a nice clean repository which, when you release it to the public, has no revisions where your chosen licence isn't in force.

Another option is to start your public repository at the point of your first release, with minimal or no history up to that point.

This has the disadvantage that people can't go back through your history and work out how you got to where you are today, but it has the advantage that people can't go back through your history and work out how you got to where you are today. *8')

When the company I work for made the software I work on open source, we started by only producing snapshots of the working directory at release points. When we moved to using public github repositories we started each git repo at the point that a plug-in was (or set of plug-ins were) moved out of svn, rarely including any history at all.

Consider a Dual License

If you think there might be commercial interest in using your software, but have an ideological preference for a restrictive re-use license such as GPL 3, consider offering dual licensing. Offering GPL 3 licenses for public download, and commercial licenses for a fee gives you the best of both worlds.

Doing this from the outset is likely to cause less friction than starting to offer commercial licenses later on. If your community becomes popular, people may accuse you of selling out if you weren't straight about the possibility of commercial exploitation later.

Consider a Contributor Agreement

If you ever plan to dual licencse, or simply want to to keep your codebase yours, you will need to either re-implement contributed fixes yourself or get contributors to assign rights over their contributions to you. Otherwise you will find that their contributions prevent you from releasing your codebase under other licenses.

The answer by Mason Wheeler to the question Does open source licensing my code limit me later? provides some good information on this and how the libsdl project used to deal with this problem.

Do be aware though that just as your choice of license may restrict the people and organisations who will use and contribute to your project, so will your choice of whether to have a contributor agreement. Some people will not be happy to contribute to a project which requires them to sign a contributor agreement.

Dual License Contributor Agreements

The Oracle Contributor Agreement (links are hard to see on that page) is a good template for a contributor agreement. It is also licensed (CC) in a way that you can modify it and re-use it.

Choose your licence

If your code has been closed source up to now, the first thing you should do is decide on which open source license (GPL <=2, GPL 3, LGPL, BSD, Eclipse etc.) you want to use.

There are pro's and cons to each, so read up on what restrictions they place on the code and decide who you want to be able to use it. Warning, whichever you choose someone will complain - this is holy war territory, and beyond the scope of this question.

• A great resource for determining which license is the right license for you is the very comprehensive, interactive license differentiator, from Oxford Universities OSS Watch.

Sanitise your repository

If the code in your repository doesn't already have your chosen license applied to it, I would go through your entire revision history so far and retroactively apply it (this may require a re-base at every point where a new source file is introduced). This will, however produce a nice clean repository which, when you release it to the public, has no revisions where your chosen licence isn't in force.

Another option is to start your public repository at the point of your first release, with minimal or no history up to that point.

This has the disadvantage that people can't go back through your history and work out how you got to where you are today, but it has the advantage that people can't go back through your history and work out how you got to where you are today. *8')

When the company I work for made the software I work on open source, we started by only producing snapshots of the working directory at release points. When we moved to using public github repositories we started each git repo at the point that a plug-in was (or set of plug-ins were) moved out of svn, rarely including any history at all.

Consider a Dual License

If you think there might be commercial interest in using your software, but have an ideological preference for a restrictive re-use license such as GPL 3, consider offering dual licensing. Offering GPL 3 licenses for public download, and commercial licenses for a fee gives you the best of both worlds.

Doing this from the outset is likely to cause less friction than starting to offer commercial licenses later on. If your community becomes popular, people may accuse you of selling out if you weren't straight about the possibility of commercial exploitation later.

Consider a Contributor Agreement

If you ever plan to dual licencse, or simply want to to keep your codebase yours, you will need to either re-implement contributed fixes yourself or get contributors to assign rights over their contributions to you. Otherwise you will find that their contributions prevent you from releasing your codebase under other licenses.

The answer by Mason Wheeler to the question Does open source licensing my code limit me later? provides some good information on this and how the libsdl project used to deal with this problem.

Do be aware though that just as your choice of license may restrict the people and organisations who will use and contribute to your project, so will your choice of whether to have a contributor agreement. Some people will not be happy to contribute to a project which requires them to sign a contributor agreement.

Dual License Contributor Agreements

The Oracle Contributor Agreement (links are hard to see on that page) is a good template for a contributor agreement. It is also licensed (CC) in a way that you can modify it and re-use it.

Choose your licence

If your code has been closed source up to now, the first thing you should do is decide on which open source license (GPL <=2, GPL 3, LGPL, BSD, Eclipse etc.) you want to use.

There are pro's and cons to each, so read up on what restrictions they place on the code and decide who you want to be able to use it. Warning, whichever you choose someone will complain - this is holy war territory, and beyond the scope of this question.

• A great resource for determining which license is the right license for you is the very comprehensive, interactive license differentiator, from Oxford Universities OSS Watch.

Sanitise your repository

If the code in your repository doesn't already have your chosen license applied to it, I would go through your entire revision history so far and retroactively apply it (this may require a re-base at every point where a new source file is introduced). This will, however produce a nice clean repository which, when you release it to the public, has no revisions where your chosen licence isn't in force.

Another option is to start your public repository at the point of your first release, with minimal or no history up to that point.

This has the disadvantage that people can't go back through your history and work out how you got to where you are today, but it has the advantage that people can't go back through your history and work out how you got to where you are today. *8')

When the company I work for made the software I work on open source, we started by only producing snapshots of the working directory at release points. When we moved to using public github repositories we started each git repo at the point that a plug-in was (or set of plug-ins were) moved out of svn, rarely including any history at all.

Consider a Dual License

Finally, if you think there might be commercial interest in using your software, but have an ideological preference for a restrictive re-use license such as GPL 3, consider offering dual licensing. Offering GPL 3 licenses for public download, and commercial licenses for a fee gives you the best of both worlds.

Doing this from the outset is likely to cause less friction than starting to offer commercial licenses later on. If your community becomes popular, people may accuse you of selling out if you weren't straight about the possibility of commercial exploitation later.

As an aside, in order to keep your codebase yours, you may need to re-implement contributed fixes yourself or get contributors to assign rights over their contributions to you. Otherwise you will find that their contributions prevent you from releasing your codebase under other licenses.

The answer by Mason Wheeler to the question Does open source licensing my code limit me later? provides some good information on this and how the libsdl project used to deal with this problem.

Dual License Contributor Agreements

The Oracle Contributor Agreement (links are hard to see on that page) is a good template for a contributor agreement. It is also licensed (CC) in a way that you can modify it and re-use it.

Choose your licence

If your code has been closed source up to now, the first thing you should do is decide on which open source license (GPL <=2, GPL 3, LGPL, BSD, Eclipse etc.) you want to use.

There are pro's and cons to each, so read up on what restrictions they place on the code and decide who you want to be able to use it. Warning, whichever you choose someone will complain - this is holy war territory, and beyond the scope of this question.

• A great resource for determining which license is the right license for you is the very comprehensive, interactive license differentiator, from Oxford Universities OSS Watch.

Sanitise your repository

If the code in your repository doesn't already have your chosen license applied to it, I would go through your entire revision history so far and retroactively apply it (this may require a re-base at every point where a new source file is introduced). This will, however produce a nice clean repository which, when you release it to the public, has no revisions where your chosen licence isn't in force.

Another option is to start your public repository at the point of your first release, with minimal or no history up to that point.

This has the disadvantage that people can't go back through your history and work out how you got to where you are today, but it has the advantage that people can't go back through your history and work out how you got to where you are today. *8')

When the company I work for made the software I work on open source, we started by only producing snapshots of the working directory at release points. When we moved to using public github repositories we started each git repo at the point that a plug-in was (or set of plug-ins were) moved out of svn, rarely including any history at all.

Consider a Dual License

If you think there might be commercial interest in using your software, but have an ideological preference for a restrictive re-use license such as GPL 3, consider offering dual licensing. Offering GPL 3 licenses for public download, and commercial licenses for a fee gives you the best of both worlds.

Doing this from the outset is likely to cause less friction than starting to offer commercial licenses later on. If your community becomes popular, people may accuse you of selling out if you weren't straight about the possibility of commercial exploitation later.

Consider a Contributor Agreement

If you ever plan to dual licencse, or simply want to to keep your codebase yours, you will need to either re-implement contributed fixes yourself or get contributors to assign rights over their contributions to you. Otherwise you will find that their contributions prevent you from releasing your codebase under other licenses.

The answer by Mason Wheeler to the question Does open source licensing my code limit me later? provides some good information on this and how the libsdl project used to deal with this problem.

Do be aware though that just as your choice of license may restrict the people and organisations who will use and contribute to your project, so will your choice of whether to have a contributor agreement. Some people will not be happy to contribute to a project which requires them to sign a contributor agreement.

Dual License Contributor Agreements

The Oracle Contributor Agreement (links are hard to see on that page) is a good template for a contributor agreement. It is also licensed (CC) in a way that you can modify it and re-use it.

Choose your licence

If your code has been closed source up to now, the first thing you should do is decide on which open source license (GPL <=2, GPL 3, LGPL, BSD, Eclipse etc.) you want to use.

There are pro's and cons to each, so read up on what restrictions they place on the code and decide who you want to be able to use it. Warning, whichever you choose someone will complain - this is holy war territory, and beyond the scope of this question.

• A great resource for determining which license is the right license for you is the very comprehensive, interactive license differentiator, from Oxford Universities OSS Watch.

Sanitise your repository

If the code in your repository doesn't already have your chosen license applied to it, I would go through your entire revision history so far and retroactively apply it (this may require a re-base at every point where a new source file is introduced). This will, however produce a nice clean repository which, when you release it to the public, has no revisions where your chosen licence isn't in force.

Another option is to start your public repository at the point of your first release, with minimal or no history up to that point.

This has the disadvantage that people can't go back through your history and work out how you got to where you are today, but it has the advantage that people can't go back through your history and work out how you got to where you are today. *8')

When the company I work for made the software I work on open source, we started by only producing snapshots of the working directory at release points. When we moved to using public github repositories we started each git repo at the point that a plug-in was (or set of plug-ins were) moved out of svn, rarely including any history at all.

Consider a Dual License

Finally, if you think there might be commercial interest in using your software, but have an ideological preference for a restrictive re-use license such as GPL 3, consider offering dual licensing. Offering GPL 3 licenses for public download, and commercial licenses for a fee gives you the best of both worlds.

Doing this from the outset is likely to cause less friction than starting to offer commercial licenses later on. If your community becomes popular, people may accuse you of selling out if you weren't straight about the possibility of commercial exploitation later.

As an aside, in order to keep your codebase yours, you may need to re-implement contributed fixes yourself or get contributors to assign rights over their contributions to you. Otherwise you will find that their contributions prevent you from releasing your codebase under other licenses.

The answer by Mason Wheeler to the question Does open source licensing my code limit me later? provides some good information on this and how the libsdl project used to deal with this problem.

Dual License Contributor Agreements

The Oracle Contributor Agreement (links are hard to see on that page) is a good template for a contributor agreement. It is also licensed (CC) in a way that you can modify it and re-use it.

Choose your licence

If your code has been closed source up to now, the first thing you should do is decide on which open source license (GPL <=2, GPL 3, LGPL, BSD, Eclipse etc.) you want to use.

There are pro's and cons to each, so read up on what restrictions they place on the code and decide who you want to be able to use it. Warning, whichever you choose someone will complain - this is holy war territory, and beyond the scope of this question.

• A great resource for determining which license is the right license for you is the very comprehensive, interactive license differentiator, from Oxford Universities OSS Watch.

Sanitise your repository

If the code in your repository doesn't already have your chosen license applied to it, I would go through your entire revision history so far and retroactively apply it (this may require a re-base at every point where a new source file is introduced). This will, however produce a nice clean repository which, when you release it to the public, has no revisions where your chosen licence isn't in force.

Another option is to start your public repository at the point of your first release, with minimal or no history up to that point.

This has the disadvantage that people can't go back through your history and work out how you got to where you are today, but it has the advantage that people can't go back through your history and work out how you got to where you are today. *8')

When the company I work for made the software I work on open source, we started by only producing snapshots of the working directory at release points. When we moved to using public github repositories we started each git repo at the point that a plug-in was (or set of plug-ins were) moved out of svn, rarely including any history at all.

Consider a Dual License

Finally, if you think there might be commercial interest in using your software, but have an ideological preference for a restrictive re-use license such as GPL 3, consider offering dual licensing. Offering GPL 3 licenses for public download, and commercial licenses for a fee gives you the best of both worlds.

Doing this from the outset is likely to cause less friction than starting to offer commercial licenses later on. If your community becomes popular, people may accuse you of selling out if you weren't straight about the possibility of commercial exploitation later.

As an aside, in order to keep your codebase yours, you may need to re-implement contributed fixes yourself or get contributors to assign rights over their contributions to you. Otherwise you will find that their contributions prevent you from releasing your codebase under other licenses.

The answer by Mason Wheeler to the question Does open source licensing my code limit me later? provides some good information on this and how the libsdl project used to deal with this problem.

Dual License Contributor Agreements

The Oracle Contributor Agreement (links are hard to see on that page) is a good template for a contributor agreement. It is also licensed (CC) in a way that you can modify it and re-use it.