Blog

Part 2: The GPL Cooperation Commitment – Coincidentally, Great for Lawyers

This post is Part 2 of a two part blog post, Part 1 of which was titled “The Dark Practice of Free & Open Source Software Law.”

In April, I attended Free Software Foundation Europe’s Legal and Licensing Workshop in Barcelona, the world’s largest and probably most important gathering of open source attorneys. One of the presentations at the conference was about the GPL Cooperation Commitment and was presented by a number of companies who had entered into the Commitment. More can be read about the Commitment here, but in summary, the Commitment is as follows: a number of companies promised that if they enforce compliance with the GPL 2, they will give the non-compliant entity a 30 day cure period to come into compliance before terminating the license. In other words, they’re promising to treat GPL 2 enforcement just like the GPL 3, which has an explicit 30 day cure provision that the GPL 2 lacks.

On the face of it, this is a good step forward because it allows people to use the GPL 2 without fear of instantly and possibly irrevocably losing their license. This, the theory goes, encourages more companies to use the GPL 2, and perhaps to participate in and contribute to the open source ecosystem. It also underscores the view that enforcement should be about obtaining compliance, rather than using enforcement as a way to attack competitors or eke out monetary damages.

At first glance, I was on board with this seemingly benign and frankly, somewhat boring, “innovation.” I say that because 30 days is really not enough time for anyone to get GPL compliant given the product release cycle (a point the presenters openly conceded) and many of the companies signing on to the commitment either don’t produce much GPL’ed code (I’m looking at you, Etsy) or have no incentive to enforce the GPL. So, to the extent the Commitment has any impact at all, that impact is fairly marginal. But, then the presenters started to discuss future projects where they hoped to “document existing norms and establish new ones.” An audience member suggested that maybe there should also be a “commitment” around the idea that source code doesn’t actually have to be delivered with the GPL’ed software; it would be acceptable to simply post a link to it and point requesters to the same. Other suggestions came rolling in for other “commitments” that would essentially update or upgrade the GPL 2 to more closely match industry practice and modern technologies.

But the problem with the GPL Cooperation Commitment and other suggested “commitments” is that it makes the practice of open source law even more opaque than it already is. As I wrote in Part 1 of this blog series, understanding how an open source license should be applied in any particular situation requires a multilayer analysis that goes well beyond the text of the license itself.

With respect to the GPL in particular, one would have to understand the open source movement, one would have to understand the tome which we call the GPL 2, one would have to know what parts of software package were GPL 2 (and which parts are “GPL 2 only” v. “GPL 2 or later”) and if any exceptions applied, one would have to know what programming languages were involved and what the software architecture looked like, one would have to know whether they’re dealing in user space or kernel space and/or what connection there was between the two, one would have to read the GPL FAQ, one would have to know who the relevant copyright holder(s) are and what their intentions might be, and a number of other disparate sources on the GPL and its application, depending on the exact scenario they’re trying to analyze. In some cases, companies even post additional terms on their websites intended to convey their own, idiosyncratic interpretation of the GPL. Many GPL-related analyses that are widely accepted across the open source community, are based on nothing more formal or authoritative than an email from Linus Torvalds.

With the GPL Cooperation Agreement, one must not only know all of the above to do a complete analysis of GPL compliance, but now they also have to look at a list of Commitment participants on a random Github page to understand the applicable termination provision for the package they’re analyzing. A list that, by the way, isn’t acknowledged anywhere in the package itself. You just have to know it’s out there.

And it gets worse, because a project can have multiple copyright owners capable of enforcing the GPL, some of whom have signed onto the Commitment and some of whom haven’t. So now, if the Commitment actually matters to you and might be a consideration in your decision-making (the goal of the Commitment, right?) you actually need to know all the contributors to a particular project before you really know what the applicable termination provision to the project is. This is notoriously hard since contributors don’t necessarily mark their code with their copyright notices, not all projects track their contributors, and even when they do, it may not be clear if the contribution was really by the individual listed or their employer or whether the copyright in that contribution has been assigned to someone else (e.g. one company bought anothersince the contribution was memorialized. Now imagine there are multiple “commitments” like this and companies who signed onto one of them may or may not sign onto the others.

This yields a dream scenario for open source compliance attorneys who will now bill more hours completing their work and open source compliance software vendors, but a nightmare for companies just trying to do their best to comply with their open source license obligations. It also makes it that much harder for new attorneys to master this field of law. It’s a move that cements incumbent advantage for existing open source attorneys and existing tech companies, profitable and sophisticated enough to deal with an additional layer of compliance complexity that can only really be dealt with by investing money and time into automated compliance systems. It reeks to me of an anticompetitive move under the guise of open source altruism.

As a community, we should be trying to make open source compliance easier, not harder. Our goal should be to make open source licenses easily understandable to the people using them. We should be writing new licenses that fix the errors of old licenses, clarify ambiguities, and clearly spell out all the “hidden” understandings that experts divulge for a fee. In particular, the fact that it was necessary to invent the “Commitment” hack is a sign that it’s time to write new licenses that can easily be upgraded over time, as Richard Stallman recently suggested. After all, the Commitment was necessary because Linux is under “GPL 2,” not “GPL 2 or later,” meaning that it’s impossible to move Linux to GPL 3 without getting permission from every Linux contributor to do so since presumably they made their contributions under GPL 2 as well. It’s also a sign that we should think a lot harder about the terms under which projects accept contributions (like Developer Certificates of Origin or Contributor License Agreements) and perhaps accept that promising contributors that the license of a project will never change might be detrimental to the long-term success of open source in general if it means that fundamental technologies like Linux remain under stone age licenses and force many Linux-adjacent technologies to also live under outdated licenses in order to maintain license compatibility.

These are undoubtedly large issues to tackle, but necessary ones as the open source movement matures and we need a wider perspective that encompasses a license’s entire lifecycle and the inevitable changes the future will necessitate because of new laws, new legal interpretations, and new technologies. The open source legal community should set its sights on these larger issues rather than putting their fingers in the dike. It’s not sustainable to keep using the same old licenses and letting a self-selected group of companies declare they mean something that they don’t at their whim. That’s a path for turning the GPL 2 into a religious text instead of a legal document.

 

Part 1: The Dark Practice of Free & Open Source Software Law

This will be part 1 of a 2 part post, the second of which will be titled “The GPL Cooperation Commitment: Coincidentally, Great for Lawyers.” I promise the connection between the two posts will be revealed!

As an open source attorney to a number of tech startups, I often get asked how an attorney can learn more about this field and start practicing within it. I think it’s important to understand the shape and nature of the field, though, before getting into a detailed how-to. In my experience, this is a dark and murky area of law, where success largely depends on one’s connections.

Let’s start with a basic fact about lawyering: law school teaches very little about the actual practice of law, and that’s especially true for transactional or corporate attorneys who do not have a litigation practice, which would include most open source attorneys. When I went to Columbia from 2007-2010, there were no classes specifically on open source or even related fields like licensing, contract drafting, or negotiation. Sure, we could learn about various legal decisions in the areas of contracts and IP, so we had an idea of how the courts interpreted various contractual clauses and statutes, but we only ever read and interpreted one or two contracts and we learned nothing about how to actually put a client’s goals into legally binding writing. At graduation, none of us could really be trusted to write anything more complicated than a bathroom hall pass.

Most lawyers learn the day-to-day business of lawyering on the job, by taking on increasingly complex tasks that are heavily supervised and directed by more senior attorneys. In many areas of the law, this is relatively straightforward because there are many statutes, regulations, court rulings, law review articles, and even treatises available. Clients ask questions, junior attorneys look up the answers, and senior attorneys make sure the junior attorneys looked at the right things and communicated their findings clearly. There might be issues that no one has squarely addressed, in which case the attorney would have to guess as to how it might come out based on the information they have, but there’s no difficulty in figuring out what body of resources they need to examine to make that guess.

The open source world, in contrast, is relatively devoid of resources. In the US, there have only been a handful of cases related to open source and they’ve barely scratched the surface with respect to open source licensing interpretation. Outside the US, there has been more open source litigation, but that litigation has mostly taken place in Germany (and thus limited in applicability to Germany) and has mostly focused on the procedural aspects of the cases that have little bearing on open source license interpretation. With limited judicial interpretation of open source licenses, there’s not much for lawyers to write law review articles, books or treatises on.

So what on earth do lawyers use as resources in guiding their clients? Well, lawyers can guess as to how they think a license should be complied with based on a simple reading of the license, assuming there is just one applicable license. But, given that some licenses weren’t drafted by lawyers, some licenses get fairly technical, and that most commonly used licenses are so old that they predate pivotal concepts like software patents, containers, dependency managers, SaaS, and interpreted languages, simply reading the license leaves most lawyers with more questions than answers. Open source licenses as a whole are completely incomprehensible even to licensing attorneys if they’re unfamiliar with the culture and ethos of the open source movement.  

In practice, even determining how any particular piece of software is licensed is not straightforward. Some software packages aren’t marked with any license at all. There might be licensing information on the project’s homepage instead. While many software packages have a COPYING or LICENSE file indicating the package’s license, many also have additional license information in other files in the package. It’s not uncommon to see packages with 10 or more licenses and finding all of them is either a long manual effort or involves automation.  Additionally, it’s not uncommon to see a package licensed one way within the package itself but for there to be either additional or conflicting terms on the project homepage or an idiosyncratic explanation with regard to how that project interprets its chosen license.

Next, lawyers look to the authors or stewards of the license for help in interpreting it just like litigators look to congressional records for help in interpreting statutes. The GPL, Eclipse, and Apache FAQs are nearly sacred in this world. Sometimes this may involve more digging; going through old email threads, blog posts, and bulletin board posts to dig into the history of how the license was drafted and why. Some of this is available online, but a lot of this is oral history, passed down from one lawyer to another. It can be hard to know where to look or who to ask, so it’s a field where knowing others with this expertise is critical. Without understanding the historical context for how a license was born, what its intended function was, and what, if any, industry consensus there is on how a license should be applied in a particular case, it can be nearly impossible to make heads or tails of what a license written many years or even decades ago might mean in 2019.

Ultimately, lawyers advise their clients based on a risk analysis: if we don’t get this right, what is the likelihood we will be sued and by whom? Here, lawyers start looking at who the entities enforcing open source licenses are, what types of non-compliance they are targeting, who they targeting, and what their goals and motivations are. Some of this information has been memorialized in various writings, but knowing who is doing what today and what they may want to do in the future requires being plugged into the open source legal community and keeping abreast of various organizational politics within these entities. Some of these entities are license stewards or are formally organized as open source compliance organizations, but some of these entities are commercial players motivated by profits and the competitive landscape, and others are just trolls.

It’s also important for an open source lawyer to have some technical expertise. Understanding software architecture, the differences between various programming languages, and various concepts like user space v. kernel space, virtual appliances, APIs, sockets, linking, calling, etc. are all vital to giving clients good guidance. This information is easily understood by lawyers who are also engineers, but lawyers who aren’t engineers need to acquire this knowledge from disparate sources including engineers, other lawyers, and various websites and books. Because the software industry innovates so quickly, there’s no one resource for this information. Given the scale of open source software consumption today, an attorney’s technical expertise also has to extend to familiarity with a number of open source compliance tools, how to properly implement and configure them, and how to create practical workflows with them.

You’ll notice that the common theme here is more or less “you gotta know a guy/gal.” Should be easy enough… but the willingness to exchange legal thought around open source licenses is, perversely, inversely related to the number of court cases in this area. With very little substantive interpretation of open source licenses by the courts, lawyers are extremely reticent to share their understanding of open source licenses with each other. No one wants to reveal an interpretation that another attorney might dispute, and in so doing admit that what their client is doing fails to meet someone else’s understanding of what an open source license requires. That might lead to unwanted attention and litigation.

This leads us to the Free Software Foundation Europe’s Legal Network mailing list. This is probably the definitive mailing list for open source attorneys and the mailing list as a whole is invited to attend an annual conference in Europe called the Legal and Licensing Workshop, which is only open to list subscribers. This is the single largest gathering of open source attorneys in the world and it’s probably fair to say virtually all serious open source legal practitioners try to attend this conference. How does any US attorney knows about this list? You gotta know a guy/gal. How does one get approved to join the list? Again, you gotta know a guy/gal. Someone somewhere has to vouch for you. The list itself can be a valuable resource, but also requires tricky maneuvering: most of the list consists of in-house attorneys who lurk but dare not speak (see above) and some folks on the list are from open source license enforcement organizations. It’s great for outside counsel like me who can ask questions without necessarily divulging on whose behalf I’m asking them, but it’s a “look, don’t touch” arrangement for in-house counsel who might accidentally reveal they’ve being doing it all wrong all along – directly to the people most likely to instigate an enforcement action.

In short, becoming an open source attorney is less about learning the law in a particular field and more about being plugged into a particular community. To give clients the best guidance you can, you have to understand copyright law and contract law (and patents, trademarks to an extent, etc.), be familiar with dozens of licenses, understand their history, understand a good bit about programming and computers, know who the license stewards are and how they interpret their licenses, understand the enforcement players, have a grasp of the competitive landscape, and learn about various compliance automation tools. This is truly a multidisciplinary field in which resources are scattered and hard to come by and where every analysis contains multiple layers.

In my opinion, becoming a real expert in the field takes years of working with a number of different technologies and licenses and getting to know others in the open source world personally or at least through their writing. It also helps to have experience working on both primarily proprietary and primarily open source products. Unsurprisingly, there are relatively few open source legal experts in the world – the last Legal and Licensing Workshop in Barcelona had fewer than 200 attendees. Breaking into this field is just plain hard and strongly depends on having the right connections.

CommunityBridge: Probably Not What You Were Hoping For

This past week I had the honor of being invited to the Linux Foundation’s Open Source Leadership Summit (OSLS) at the Ritz Carlton in Half Moon Bay (pictured above). The Summit had a packed itinerary, with about 300 other attendees which included founders, executives, open source office program managers, community managers, developers, and a handful of open source attorneys, as well as several open source foundations.

With the Linux Foundation’s announcement of its new CommunityBridge platform at the Summit, much of the conversation at OSLS inevitably shifted towards the monetization of open source software. CommunityBridge allows a Linux Foundation-selected set of developers to raise funding through the platform and offers a number of tools to help open source projects find and fix security vulnerabilities, track their dependencies, and connect mentees with mentors, who are required to offer some number of interview spots to their mentees. In this, CommunityBridge joins other efforts like Open Collective, OpenGift, Gitpay, Patreon, Topcoder, and Bountysource.

What was striking to me about the Linux Foundation announcement was the language used around it such as “helping hand” and “collective responsibility.” The recurring theme was one of charity. In talking about CommunityBridge and its benefits to open source maintainers and contributors, the conversation returned again and again to this idea of developers gaining recognition through the platform and “landing” jobs at Linux Foundation’s consortium of backers like IBM, Google, and VMware.

From a developer perspective, we should support any and all efforts to grow the open source ecosystem and to remunerate the people whose time, knowledge, and effort has provided commercial technology firms with billions of dollars in value. However, I have deep misgivings about a system that has no interest in empowering developers to simply make a living by working on open source software, and instead believes that developers should want nothing more and expect nothing more other than to join giant corporations as salarymen. This is unsatisfying for developers who work on open source software specifically because they don’t want to work for the tech giants, and is a bit of a “the reward for winning the pie eating contest is more pie” scenario. It’s not actual remuneration for past work, it’s an obligation to produce future work – on someone else’s terms.

Even from a corporate perspective, it strikes me that companies have no shortage of means for donating to open source projects. They can and they do when they think they have to (and have sufficient information from which to form that belief) and they have the right personal relationships with the project maintainer(s) and perhaps that community, that they feel like the donation will support something of value. We’re not low on internet payment processors. But companies are generally not all that interested in making payments that don’t come with contractual promises like regular support, timely updates, quick security fixes, clear licensing information, etc.

From a community perspective and a broader view of the future of open source, I see CommunityBridge normalizing and reifying the view that open source software is charity. Perhaps this isn’t surprising considering that one of the first slides the executive director at the Linux Foundation showed was of the open source ecosystem and the circle of life was: create open source software, have corporations consume the software, corporations donate to open source software projects, repeat. As someone who owns her own business, I am perhaps biased, but I would like to think that there is a future for independent developers who create something of value to simply get paid for doing so.

I’d like to see a marketplace where open source developers can get paid for their work and companies can get a full set of services, each exchanging something of equal value. The only effort I know of on this front is Tidelift. I know the open source world has a long tradition of hobbyists and people passionate about making software that the rest of the world can use without restriction, who don’t want to mix money with something they see themselves doing out of love. Maybe we’ll live in a world like that someday, but today, notions of free sharing mostly apply to the taking of open source software and not the giving of profits made off of that software. In the last decade, especially, the goal for both open source projects and businesses alike has been “get big and then we’ll figure out how to make money.” But when you look at companies like Redis and Elastic, it turns out nothing actually changes when you’re big – your open source license is still your open source license and your monetization problem hasn’t gone anywhere because the culture around open source is still mainly one of charity instead of markets, and project maintainers are optional donees instead of critical partners.

 

 

Should I Use a Developer’s Certificate of Origin or a Contributor Agreement?

A very common question I get from corporate clients is whether they should use Developer’s Certificates of Origin (DCOs) or contributor agreements for their open source projects. I’ll refer to both contributor licensing agreements (like Apache’s) and contributor copyright assignment agreements (like MongoDB’s) as “CLAs” here.  

In short, the answer is that DCOs work well for entities that are ideologically committed to open source. DCOs are a particularly good fit for license stewards like the Free Software Foundation, who are very invested in their licenses of choice. DCOs work less well for for-profit entities that are concerned with retaining licensing flexibility and being able to exercise their intellectual property rights, both offensively and defensively. While DCOs are definitely becoming more popular and failure to use them may mean fewer contributors, it’s important to remember that they were introduced and propagated specifically to rein in corporate behavior with respect to open source projects.

Companies can successfully go the CLA or the DCO route, but that success will be highly dependent on the company’s priorities, competitive environment, licensing models, and need for licensing flexibility. Here are the main divides between DCOs and CLAs:

1.        CLAs allow for easy relicensing whereas DCOs discourage it. Contributor licensing agreements typically require that the contributor grant a very broad license to the contribution to the project’s owner. In the case of contributor assignment agreements, the contributor transfers copyright ownership of the contribution to the project’s owner. Either one allows a company to easily change a project’s (or a contribution’s) license to a different open source license or to license the project (or a contribution) under a commercial license.

DCOs function under the “inbound=outbound” model, i.e. contributors grant the project contributions under the same license as the project itself. That means that if a project wanted to change its license, the project would need to actively reach out to all of its contributors and ask for a broader license that would allow for the contributions to be relicensed.* (That would also be the case if the project had no DCOs or CLAs at all.) If a company wanted to move a feature out of an open source version of its product and into an enterprise version of its product, it would likewise need to separately get a license from contributors to that feature to license that contribution out commercially and not under the original project license.**  

It took Mozilla 5 years to move Firefox from MPL 1.1 to MPL 2.0 because they did not have contributor agreements in place at the time. It took OpenSSL about 2 years to move from the OpenSSL/SSLeay license to Apache 2.0. In both cases, the projects were not owned by commercial entities, the licensing move was not motivated by profit, and the license change was not drastic. Corporate projects should probably expect this process to take longer and to receive more pushback from contributors, especially if the licensing change results in the project moving from a permissive to a copyleft license or vice versa or if the project is going to become commercially licensed.

As you can see, DCOs offer less flexibility for a commercial enterprise that is driven by the needs of its customers and the shifting market. A need to relicense for a commercial enterprise may arise because of changing developer preferences, a court decision that redefines the open source license in an unfavorable way or invalidates it entirely (this happened with the Artistic License 1.0), a desire to pick a license more compatible with another key technology, or the need to rethink which features should be under an open source license and which should get moved into an enterprise version of the product. That desire for flexibility runs into direct conflict with DCOs precisely because DCOs were designed to prevent projects from changing licenses over time (“inbound=outbound is the way a FLOSS community implements their morality”).

Think about it this way: the projects where DCOs originated are ones where the participants have as much if not more allegiance to the license itself than they do to the project. These entities are likely to defend their chosen license in litigation (including via amicus briefs and the like), and to manage litigation in a way that will preserve the intended meaning of the license, even at the expense of a specific project or copyright holder. For most corporate entities, however, their primary commitments are to their customers, shareholders and employees; they should switch licenses if they need to and retaining the ability to do that in the worst-case scenario can be the difference between staying in business or not.

2.       CLAs have explicit patent grants that can protect a company from patent lawsuits, whereas DCOs don’t. Individual contributors are very unlikely to instigate patent litigation with respect to an open source contribution they made, but a corporate contributor might. While it may seem silly that a company would sue another company for contributions it willingly made, keep in mind that a company will not consider a contribution “willingly made” if its legal department wasn’t aware of it and didn’t sign off on it.

A patent grant is standard and straightforward in a CLA, clearly signed by the corporate contributor. DCOs, on the other hand, are problematic for three reasons:

1) DCOs don’t look and feel like a legal contract, making it less likely an employee will run it by their legal department and get proper sign-off;

2) No court has ruled that tags in DVCS commit logs can substitute for signing a contract (click-throughs, however, do constitute a legal signature), and

3) It’s unknown if the tag is being put in place by someone in their individual capacity or in their corporate capacity – there’s no way to tell who is actually “signing” up to the DCO since there is no point when a contributor is prompted to disclose this information.

Even Bradley Kuhn, who is one of the biggest proponent of DCOs will admit this shortcoming of DCOs.

3.       CLAs make the contributor responsible for any intellectual property infringement due to their contribution, whereas DCOs mostly don’t. This is not particularly relevant or useful for individual contributors because no one would want the public relations fallout from suing an individual contributor no matter the circumstances, and individual contributors are unlikely to be able to pay out any significant damages.

However, this is useful for corporate contributors, especially those whose contributions are not new features but instead just integrations to their own products or services. Even if they were unaware of their code violating someone else’s patent, it may be equitable to hold them liable if they are receiving as much or more benefit from the integration as the project. Note that the DCO’s language with respect to this issue is fairly weak and it is unclear just how far it goes, whereas CLAs are clear that the contributor is responsible for all intellectual property infringement in their contribution.

The best way to square the difference with respect to individual and corporate liability for intellectual property infringement is to offer separate CLAs for individual and corporate contributors.

4.        Copyright assignment agreements can ensure a company’s ability to sue or countersue a competitor for intellectual property infringement. In order to have standing in court to sue or counter-sue in relation to a contribution, a company must have copyright ownership over the contribution and the copyright must be registered. Only a contributor copyright assignment agreement can effect that.

Under a DCO, a contributor grants a company a non-exclusive license to the code they are contributing, but not ownership, meaning that it would not aid in securing a company’s standing before a court. Practically speaking, a company may have to find the contributor or their heirs and ask them to participate in the litigation in order to enforce an intellectual property claim related to a contribution given under a DCO.

Many CLAs also do not take copyright ownership over a contribution, but merely a broad license. With regard to this issue, they are on equal footing with DCOs. Whether to ask for copyright assignment rather than a broad license is a question that’s answered differently by different tech companies and even different open source foundations. Google does not take ownership for example, but the FSF does. Whether or not this aspect of a CLA is important to  a company hinges on whether it is in a competitive space that is likely to yield lawsuits from competitors, whether the company itself is likely to bring lawsuits against competitors, whether and what portion of the contributions the company receives are substantial/key to its products, and how well a company tracks who is contributing what to its products.  

5.        CLAs can help minimize administrative overhead. With a CLA, any code contributed to a company can be used in whatever way the company desires and it is not necessary to track the contribution or its provenance. The CLA itself can be a simple click-through whose results are automatically stored.

However, if a company does not use CLAs, but it remains concerned about its ability to relicense or its ability to bring or counter a lawsuit, then it will still want to keep track of who contributed what (and whether in their personal or professional capacity), including contact information. This may be difficult at first because not all contributors mark their contributions with their names and contact information, and it will become harder over time if code is merged or refactored since notices can easily be lost during that process and over time there will be downright philosophical questions about who really wrote the resulting code.

Note that this is truly more difficult than it may seem given the German court’s ruling for VMware against a Linux contributor. The court there said that the contributor’s reference to his GIT commits was insufficient basis for determining what was his copyrighted work. This ruling potentially goes both ways: if GIT commits aren’t sufficient for a contributor to lay claim to his contributions, then they may also not be sufficient for a project owner to lay claim to its own work, either.

In the end, the system a company creates to track this information is likely to be even more complicated than just a simple click-through CLA.

______________________________________________________________________________

* It might be possible for a project to change licenses but keep the contributions under the original project license if the original and the new license were compatible. However, in many cases the entire reason for a license change is to become compatible with some other license, so this may not be possible. Also, keeping contributions under one license while moving the project as a whole onto another is practically very difficult because over time as code is modified and refactored, it becomes difficult to draw the line between that original contribution and the evolving project. So, keeping a few contributions under the original license might be possible if they’re distinguished and sequestered, but this is like not a viable plan for all of a project’s contributions.

** Depending on the original project license, the company could include the feature in a commercially project licensed without getting contributor sign-off, so long as that particular feature remained under the original project license. Of course, if the license is copyleft, the company would still have to provide source code for that particular feature.

Creating a Comprehensive 3rd-Party Package Licensing Policy

Last November, I attended FINOS’s Open Source Strategy Forum in London. It was a terrific opportunity to meet people in the fintech space and to get a sense for how companies large and small in this industry were thinking about open source compliance and the overall open source value proposition for their companies. After the conference, FINOS’s General Counsel & Director of Governance, Aaron Williamson, kindly invited me to present to FINOS’s Open Source Readiness (OSR) Working Group.

The OSR Working Group hosts a regular speaker series, of which my presentation was but one of many. If you’re in the fintech space, I highly recommend checking it out. Even if you’re not in the fintech space, many of the presentations and resources they have available are useful across many industries.

My presentation focused on creating a comprehensive third party package licensing policy. This is often one of the first things my clients ask me to create for them and creating one is often a major hurdle for companies who otherwise have the tools and desire to jump-start the open source compliance process, but aren’t sure about the legal implications of the various open source licenses and quasi-open source licenses out there. This presentation gives an inside view as to how lawyers go about creating such policies and the types of concerns they often address.

The presentation was recorded and posted to YouTube here.

You can also download the slides here. I recommend downloading the slides and viewing them via PowerPoint because Google Slides preview will strip out a lot of the nice pictures and formatting.