We have a lot of Open Source code. For engineers without considerable experience in the open source realm, understanding some of the copyright issues around code ownership can be tricky. I’ve been working with our CTO dB., and our senior counsel Yayoi Shionoiri on creating an open-source FAQ for engineers.

What is Open Source?

Open Source code is code that can be freely examined, used, adapted, and shared by all through a license that sets forth these principles. The only potential limitation that an Open Source license is likely to impose is that future copies of the code (whether in adapted or un-adapted form) be themselves licensed in a manner consistent with the original license. At Artsy, we are committed to making our engineering work Open Source by default. A list of our Open Source projects can be found here.

What is Open Source “by default”?

Open Source “by default” means that new projects are started or eventually become Open Source, unless keeping them proprietary represents a significant competitive advantage.

What are the advantages to Open Source code?

Keeping our engineering work Open Source by default allows us to be a thought leader, attracts and retains the best talent, and also is a great way to produce high quality work – in other words, it helps to drive and sustain our Quality Worthy of Art, Openness, and People are Paramount values. However, not everything is or should be Open Source. There are many great reasons to be open, but it’s not a catch all.

How does Open Source interact with Copyright?

Very generally speaking, copyright is the body of law that governs how Artsy upholds its ownership rights over code that an Artsy engineer creates as part of their duties as an Artsy employee, and Open Source describes the way in which Artsy shares this code with the rest of the world. Put in another way, Artsy engineers develop code as “work for hire” to Artsy, and Artsy shares this code with specific usage and distribution terms through a license attached to it.

What’s Inbound Open Source code vs. Outbound Open Source code?

Inbound Open Source code refers to the use of third party code under an Open Source license for Artsy’s products. Outbound Open Source code refers to the publication of Artsy code.

When we publish Outbound Open Source code, as mentioned before, Artsy has a right to do so because we have the copyright to this code. We give third parties the right to use the code usually through this type of broad license (MIT). (For more on code licenses, see Orta’s talk on code licenses.

What is the credit on Artsy’s Open Source code?

For Inbound Open Source code, we usually credit the work of external engineers by conforming to their license, and providing attribution inside each source base. This tends to be generated automatically by project tools, and rarely needs specific attention.

For Outbound Open Source code, we usually credit the work of our Artsy engineers by using attribution changelogs, and by assigning an engineer as a point person for a project.

How can I use Open Source code at Artsy?

When we use Inbound Open Source code, we should always check to ensure that there are no third parties who may have an exclusive right over this code before we include it in our own work. We should also use standard tools for handling Open Source code to ensure that we comply with the licenses attached to such code. We do not use code with viral licenses (for e.g., GPL License) or non-OSI approved licenses (for e.g., WTFPL license).

How do I Open Source a new project at Artsy?

When creating a new project at Artsy, you must include a license. We use the canonical copy of the MIT license with the copyright holder as shown below. Ideally, you should ensure that it starts off with a README, continuous integration set up, linters, tests and documentation.

How can I Open Source an existing project at Artsy?

When Open Sourcing existing projects, it’s best practice to announce it to the development (and related product teams) and ensure that there is ample time for discussion before moving it. For example see how we migrated the artsy.net website.

How does Artsy think about Artsy Projects versus Personal Projects?

Engineers have the ability to determine whether work they do is uniquely for Artsy during Artsy work hours (an “Artsy Project”) or is a project created on their own time but can be applied and shared with Artsy (a “Personal Project”). If you have questions about whether a particular project should be an Artsy Project or a Personal Project, please discuss with your manager.

From an external consumer’s perspective, the end result is generally the same as the license by which these code is released should not change.

Examples are found below:

I’d like to personally thank Gil Yehuda of Yahoo! for answering a lot of our questions, you really helped. For Artsy staff, you can get the living document at the Engineering page on Artsy Atlas.