indeximage: /uploads/2023/05/we will open source it later.png
indeximage: /uploads/2023/05/we will open source it later.png
indexalt: "Write a horror story for your industry using just four words." "We'll open source it later" Text is from a Twitter screenshot at https://twitter.com/jamesvasile/status/1410241468833406986
indexalt: "Write a horror story for your industry using just four words." "We'll open source it later" Text is from a Twitter screenshot at https://twitter.com/jamesvasile/status/1410241468833406986
...
@@ -31,13 +32,22 @@ from internal stakeholders early. Secure support all the way up the org-chart
...
@@ -31,13 +32,22 @@ from internal stakeholders early. Secure support all the way up the org-chart
if you can. This is the step that at first seems doable or even easy but
if you can. This is the step that at first seems doable or even easy but
ultimately blocks so many projects from ever going open.
ultimately blocks so many projects from ever going open.
**[ ] Get legal buy-in.** Let your counsel know you're moving in this direction.
Make sure you know what their requirements are to sign off on publishing under
an open source license.
**[ ] Ensure regulatory compliance.** Check to make sure you're square with
export control regulations regarding encryption. If you're just using
commonly-used open source encryption libraries, you are probably fine.
Depending on what your software does, other regulatory rules might apply. Find
out and get in compliance.
**[ ] Check your copyrights.** Ensure you have the needed permissions to
**[ ] Check your copyrights.** Ensure you have the needed permissions to
release your project under open license. These permissions could come from
release your project under open license. These permissions could come from
licenses or copyright ownership. Do not assume you have the rights. Go look. Do
licenses or copyright ownership. Do not assume you have the rights. Go look. Do
an audit. If necessary, read up on works for hire and federal ownership of
an audit. If necessary, read up on works for hire and federal ownership of
copyright.
copyright.
**[ ] Consider your patent portfolio.** FOSS licenses sometimes include patent permissions, whether explicitly stated or implicitly granted. If you or your contributors hold patents, you should evaluate the impact of open licensing on your patent rights. You might decide your patents are best used to nurture your open source strategy. Alternatively, you might want to take steps to protect your patents.
**[ ] Consider your patent portfolio.** FOSS licenses sometimes include patent permissions, whether explicitly stated or implicitly granted. If you or your contributors hold patents, you should evaluate the impact of open licensing on your patent rights. You might decide your patents are best used to nurture your open source strategy. Alternatively, you might want to take steps to protect your patents.
**[ ] Pick an outbound license.** Usually this will be BSD, Apache, or some flavor of GPL, but there is a wide range of [FOSS licenses](https://opensource.org/licenses/) out there for you to choose from.
**[ ] Pick an outbound license.** Usually this will be BSD, Apache, or some flavor of GPL, but there is a wide range of [FOSS licenses](https://opensource.org/licenses/) out there for you to choose from.
...
@@ -87,8 +97,15 @@ quickly you will respond to issues and PRs. See
...
@@ -87,8 +97,15 @@ quickly you will respond to issues and PRs. See
**[ ] Squash history.** Does your repository contain sensitive information or secrets? Has it ever? When repositories are private, people tend to be less guarded about what they check in to the repo. Problematic content includes secrets and PII but also might include commit messages containing profanity or even defamatory content. It is not practical for most projects to examine all their history, so many delete, edit, or squash history before going public.
**[ ] Squash history.** Does your repository contain sensitive information or secrets? Has it ever? When repositories are private, people tend to be less guarded about what they check in to the repo. Problematic content includes secrets and PII but also might include commit messages containing profanity or even defamatory content. It is not practical for most projects to examine all their history, so many delete, edit, or squash history before going public.
**[ ] Remove secrets.** Ensure there are no API keys or passwords or other
sensitive information in the remaining codebase.
**[ ] Publish documentation.** Centralize it into an accessible location under open source or creative commons license. Documentation should be open to change requests. Track down the design and usage documentation that may currently reside in various internal places and make them public. Collect the implicit learnings of your team, and write them down so people without your experience can productively approach the software.
**[ ] Publish documentation.** Centralize it into an accessible location under open source or creative commons license. Documentation should be open to change requests. Track down the design and usage documentation that may currently reside in various internal places and make them public. Collect the implicit learnings of your team, and write them down so people without your experience can productively approach the software.
Remember, this checklist is a general list of tasks, some of which might not
apply to you. Adapt it to your specific needs and legal requirements. Work
with your lawyer and your open source advisor to reduce this to the list that
works for you and your product.
*Thanks to Karl Fogel, Frank Duncan, and Jesse Bickel for reading early drafts of
*Thanks to Karl Fogel, Frank Duncan, and Jesse Bickel for reading early drafts of
