This week we’re joined by Jason Bosco, co-founder and CEO of Typesense — the open source Algolia alternative and the easier to use ElasticSearch alternative. For years we’ve used Algolia as our search engine, so we come to this conversation with skin in the game and the scars to prove it. Jason shared how he and his co-founder got started on Typesense, why and how they are “all in” on open source, the options and the paths developers can take to add search to their project, how Typesense compares to ElasticSearch and Algolia, he walks us through getting started, the story of Typesense Cloud, and why they have resisted Venture Capital.
Did you know VS Code has a proprietary license?
Microsoft’s vscode source code is open source (MIT-licensed), but the product available for download (Visual Studio Code) is licensed under this not-FLOSS license and contains telemetry/tracking.
The VSCodium project exists so that you don’t have to download+build from source. This project includes special build scripts that clone Microsoft’s vscode repo, run the build commands, and upload the resulting binaries for you to GitHub releases. These binaries are licensed under the MIT license. Telemetry is disabled.
They also have various package managers covered, so you can
brew install --cask vscodium, etc.
Following thanks to all contributors, the blog notes:
Most applications that worked with OpenSSL 1.1.1 will still work unchanged and will simply need to be recompiled (although you may see numerous compilation warnings about using deprecated APIs). Some applications may need to make changes to compile and work correctly, and many applications will need to be changed to avoid the deprecations warnings.
And points out a couple of new features:
OpenSSL 3.0 introduces a number of new concepts that application developers and users of OpenSSL should be aware of. An overview of the key concepts in libcrypto is available in the libcrypto manual page.
A key feature of OpenSSL 3.0 is the new FIPS module. Our lab is testing the module and pulling together the paperwork for our FIPS 140-2 validation now. We expect that to be submitted later this month. The final certificate is not expected to be issued until next year.
And finally, LWN notes on the license change:
OpenSSL has also been relicensed to Apache 2.0, which should end the era of “special exceptions” needed to use OpenSSL in GPL-licensed applications.
Luis Villa of Tidelift joins the show to discuss GitHub Copilot and the implications of an AI pair programmer from a legal perspective.
The FSF is funding white papers on “philosophical and legal questions around Copilot”. In their post announcing the fund, Donald Robertson states:
The Free Software Foundation has received numerous inquiries about our position on these questions. We can see that Copilot’s use of freely licensed software has many implications for an incredibly large portion of the free software community. Developers want to know whether training a neural network on their software can really be considered fair use. Others who may be interested in using Copilot wonder if the code snippets and other elements copied from GitHub-hosted repositories could result in copyright infringement. And even if everything might be legally copacetic, activists wonder if there isn’t something fundamentally unfair about a proprietary software company building a service off their work.
One thing is for sure: there are many open questions that need answering. How we (as a community / industry) go about answering those questions is much less clear. But it’ll probably take place on blogs, forums, GitHub Issues, and even court rooms over the next decade.
Raj Dutt, CEO and co-founder of Grafana Labs:
Our company has always tried to balance the “value creation” of open source and community with the “value capture” of our monetization strategy. The choice of license is a key pillar of this strategy, and is something that we’ve deliberated on extensively since the company began.
Over the last few years, we’ve watched closely as almost every at-scale open source company that we admire (such as Elastic, Redis Labs, MongoDB, Timescale, Cockroach Labs, and many others) has evolved their license regime. In almost all of these cases, the result has been a move to a non-OSI-approved source-available license.
We have spent the first months of 2021 having sometimes contentious but always healthy internal debates over this topic, and today we are announcing a change of our own.
Ensuring we maintain these freedoms for our community is a big priority for us. While AGPL doesn’t “protect” us to the same degree as other licenses (such as the SSPL), we feel that it strikes the right balance. Being open source will always be at the core of who we are, and we believe that adopting AGPLv3 allows our community and users to by and large have the same freedoms that they have enjoyed since our inception.
Read the entire post for more details on what is being re-licensed, what isn’t, and what it all means. They also have a Q&A on their blog answering other common questions and concerns.
In a copyright decision that will undoubtedly have ripple effects on the software industry for years to come, the Supreme Court of the United States held that:
Google’s copying of the Java SE API, which included only those lines of code that were needed to allow programmers to put their accrued talents to work in a new and transformative program, was a fair use of that material as a matter of law.
This quote pulled from the linked opinion by a hacker news commenter drives right in to the heart of the matter:
“Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as one small part of the considerably greater whole. As part of an interface, the copied lines of code are inextricably bound to other lines of code that are accessed by programmers. Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.”
This week Jerod is joined by Paul Biggar the creator of Dark, a new way to build serverless backends. Paul shares all the details about this all-in-one language, editor, and infrastructure, why he decided to make Dark in the first place, his view on programming language design, the advantages Dark has as an integrated solution, and also why it’s source available, but NOT open source.
This week we’re talking about the recent falling out between Elastic and AWS around the relicensing of Elasticsearch and Kibana. Like many in the community, we have been watching this very closely.
Here’s the tldr for context. On January 21st, Elastic posted a blog post sharing their concerns with Amazon/AWS misleading and confusing the community, saying “They have been doing things that we think are just NOT OK since 2015 and it has only gotten worse.” This lead them to relicense Elasticsearch and Kibana with a dual license, a proprietary license and the Sever Side Public License (SSPL). AWS responded two days later stating that they are “stepping up for a truly open source Elasticsearch,” and shared their plans to create and maintain forks of Elasticsearch and Kibana based on the latest ALv2-licensed codebases.
There’s a ton of detail and nuance beneath the surface, so we invited a handful of folks on the show to share their perspective. On today’s show you’ll hear from: Adam Jacob (co-founder and board member of Chef), Heather Meeker (open-source lawyer and the author of the SSPL license), Manish Jain (founder and CTO at Dgraph Labs), Paul Dix (co-founder and CTO at InfluxDB), VM (Vicky) Brasseur (open source & free software business strategist), and Markus Stenqvist (everyday web dev from Sweden).
Ever since AWS took Elasticsearch and decided to sell a managed version of it there has been controversy around AWS and Elasticsearch. Now that the software created by Elastic is being switched to the Server-Side Public License
(SSPL), which is not a very permissive license, AWS is going ahead and forking the projects.
The debate rages around this. Few people feel sympathy with the behemoth that is AWS, but they don’t seem to be in violation of any licenses. Elastic have definitely worked hard on Elasticsearch and arguably deserves an opportunity to profit from their work. This new license raises significant concern though.
I don’t think we’ll see this settle anytime soon, just like the issue of open source sustainability is neither easy nor straightforward.
Today we welcome Mike Pennisi into our Maintainer Spotlight. This is a special flavor of The Changelog where we go deep into a maintainer’s story. Mike is the maintainer of JSHint which, since its creation in 2011, was encumbered by a license that made it very hard for legally-conscious teams to use the project. The license was the widely-used MIT Expat license, but it included one additional clause: “The Software shall be used for Good, not Evil.” Because of this clause, many teams could not use JSHint.
Today’s episode with Mike covers the full gamut of JSHint’s journey and how non-free licensing can poison the well of free software.
According to the “why does this exist” section of the readme:
When we [Microsoft] build Visual Studio Code, we do exactly this. We clone the vscode repository, we lay down a customized product.json that has Microsoft specific functionality (telemetry, gallery, logo, etc.), and then produce a build that we release under our license.
When you clone and build from the vscode repo, none of these endpoints are configured in the default product.json. Therefore, you generate a “clean” build, without the Microsoft customizations, which is by default licensed under the MIT license.
This repo exists so that you don’t have to download+build from source. The build scripts in this repo clone Microsoft’s vscode repo, run the build commands, and upload the resulting binaries to GitHub releases. These binaries are licensed under the MIT license. Telemetry is disabled.
The Visual Studio Code license referenced is a short read. You should read it if you use VS Code.
DRAT is a Map Reduce version of RAT using Apache Tika to automatically sort and classify the code base files
A well-named solution to an ever-expanding problem. But what is up with Apache projects and their obsession with trademarks?
A distributed parallelized ( Map Reduce) wrapper around APACHE RAT™️ (Release Audit Tool) that goes far beyond RAT™️ by leveraging Apache OODT™️ to dramatically speed up the process.
This is a solid (text) interview with Bruce Perens, former member of the OSI:
… a recognized pioneer of the Open Source movement, 62-year-old Bruce Perens is still thinking about ways to protect the freedoms of software users. “Most people who develop open source don’t have access to lawyers” Perens told the Register last month. “One of the goals for open source was you could use it without having to hire a lawyer. You could put [open source software] on your computer and run it and if you don’t redistribute or modify it, you don’t really have to read the license.”
Bruce suggests we all limit ourselves to just three licenses: AGPL 3, LGPL 3, and Apache 2. He’s a fascinating guy with lots to say on the matter. It’s an exciting time in software licensing, which is a sentence I never expected to write in my life.
2019 was a crazy year for licensing in open source. Luis Villa shared his take at what happened last year…
2019 was the most active year in open source licenses in a very, very long time, with news from China to Silicon Valley, from rawest capitalism to most thoughtful ethics. Given all that, I thought it would be worth summarizing the most interesting events, and sharing some reflections on them.
A stand out to me was on the subject of money…
Inevitably, as open source has “won,” money has become ever more central to how it functions. It turns out it is hard to sustain the entire software industry on a part time basis! Licensing has not played a central role in this discussion, but 2019 gave several examples of how licensing and money are entangled.
Extending from topics around open source licensing in this recent conversation with Adam Jacob and this recent conversation with David Cramer, we’re now at a point where Bruce Perens (OSI co-founder) has quit the OSI saying “we’ve gone the wrong way with licensing” regarding the recently drafted Cryptographic Autonomy License (CAL).
The debate over whether or not to approve the license, now in its fourth draft, has proven contentious enough to prompt OSI co-founder Bruce Perens to resign from the organization, for a second time, based on concern that OSI members have already made up their minds.
“Well, it seems to me that the organization is rather enthusiastically headed toward accepting a license that isn’t freedom respecting,” Perens wrote in a missive to the OSI’s license review mailing list on Thursday. “Fine, do it without me, please.”
The copyright battle that’s been going on since 2010 between these two tech giants will finally reach its conclusion at the highest court in the land.
Google will have just 30 minutes to present its case; Oracle will have 30 minutes to respond… The two tech giants have agreed to the following filing schedule:
- January 6, 2020 – Google will submit its brief (i.e. argument why they should prevail).
- February 12, 2020 - Oracle will submit its response brief.
- March 13, 2020 - Google will file a reply to Oracle’s brief addressing any opposing points raised.
If Google wins, the case is finally closed. If Oracle wins, the damages will be calculated by a California jury. Estimated damages in this case are in the $8-9 billion range.
David Cramer joined the show to talk about the recent license change of Sentry to the Business Source License from a BSD 3-clause license. We talk about the details that triggered this change, the specifics of the BSL license and its required parameters, the threat to commercial open source products like Sentry, his concerns for the “open core” model, and what the future of open source might look like in light of protections-oriented source-available licenses like the BSL becoming more common.
As I got started writing open source software, I generally preferred the MIT license. I actually made fun of the “copyleft” GPL licenses, on the grounds that they are less free. I still hold this opinion today: the GPL license is less free than the MIT license - but today, I believe this in a good way.
As someone who has spent tens of thousands of hours developing free software, Drew’s thoughts on these matters are well considered. After reading this, I had to ask myself why I still prefer MIT. Ultimately, I think him and I differ on motivation. He states:
I give people free software because I want them to reciprocate with the same.
I give people free software and I want them to reciprocate with the same. However, I don’t do it because I want them to do it. I do it because I want to give the world a gift. Full stop. What about you?
The co-founders of CockroachDB — Peter Mattis (CTO), Ben Darnell (Chief Architect), and Spencer Kimball (CEO) — co-wrote a post explaining their move to MariaDB’s Business Source License (BSL) in order to thwart competitors, otherwise know as “highly-integrated providers,” from offering a version of CockroachDB “as-a-service” without purchasing a license to do so.
We’re witnessing the rise of highly-integrated providers take advantage of their unique position to offer “as-a-service” versions of OSS products, and offer a superior user experience as a consequence of their integrations.
Here’s the tl;dr of this license change:
Today, we’re adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license.
Nadia Eghbal, on the role of licenses in open source funding:
I’m skeptical that new licenses are the right approach on a systemic level, both in terms of feasibility, as well as where I think the world is going. I’ll tackle each of these concerns separately.
I tend to agree with her take on the Right Way™️ to be thinking about it:
I’m more interested in solutions that aim to capture value on the production, rather than consumption side. While everyone is focused on putting up tollbooths, opportunities to “price” maintainer attention, and access to maintainers, remain undervalued.
There are issues with this as well. For one, buying access to maintainers is a proxy for buying influence over the project’s direction. This isn’t a guarantee, but it’s definitely a concern and could negatively impact other users.
That being said, I think production-side monetization in the world of open source is a winning strategy over consumption-side monetization. What do you think?
MIT and BSD open source licenses are well known, popular, and legally deprecated. They served long and well, but they’re older than many open source software developers, and haven’t been maintained.
With licenses like Blue Oak available, it’s time open source upgraded from academic forms of the ’80s. There are good social, practical, and especially legal reasons to do so.
Kyle goes on to enumerate all the reasons why the Blue Oak license is a better fit for open source.
This op-ed from Bryan Cantrill (CTO at Joyent) goes deep into the details around “service providers’ parasitic relationship with open source,” and the other concerns around open source makers shifting to use licenses like commons clause and others designed to restrict service providers from developing commercial products from their open source.
Lots of thoughts shared around the subject and many links as well, so — get to digging.
Here’s an interesting twist on open source funding: require all users to back the project on Open Collective, but only enforce that rule via social pressure. In other words, use an honesty policy:
It is an honesty system with no code or legal enforcement. When raising an issue or a pull request, the user may be checked to ensure they are a patron, and that issue/PR may be closed without further examination. If a individual or organization has no interest in the long term sustainability of Fody, then they are legally free to ignore the honesty system.
The software is MIT-licensed, so all of those liberal rules apply, but don’t expect to get your PR merged or your issue taken seriously unless you’re a patron.
You must be a Patron to be a user of Fody. Contributing Pull Requests does not cancel this out. It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project.
The project currently has 4 organizations and 10 individuals supporting it. What do you think those numbers will look like in 6 months or a year?