Relicensing effort

Motivation

History

Watcom was open sourced by Sybase, with the help of SciTech Software, back in 2002. Open Watcom is released under the Sybase Open Watcom Public License version 1.0.

The problem

Unfortunately this license is problematic. The good news is it is considered to be Open Source. The bad news is it is not considered to be Free Software by either the Free Software Foundation, Debian, or Fedora. This is very unusual: usually Open Source code is Free Software, and vice versa, with the difference between Open Source and Free Software being philosophical.

This can be viewed as a legal or philosophical problem. It is also, immediately, a ‘practical’ problem. To flip it round to a positive: if Linux distributions like Debian and Fedora were to ship Open Watcom, it would increase the number of potential users and contributors.

One major specific problem with the license is the definition of Deploy in clause 1.4. The definition is overly broad and prohibits some private use (without publishing your changes). Moreover, clause 2.2(c) is at the very least annoying, by requiring you to distribute source code for up to twelve months after you stop distributing binaries. This is even if you offered the source code side-by-side with the binaries, back when you distributed the binaries. This is, again, a practical annoyance. There is also concern that clause 12.1 Termination is overly broad, preventing litigation over non-software patents, unrelated to Open Watcom; in contrast, the Apache licence patent termination clause only relates to patent ligitation over ’the Work’.

Finally, it has long been recognised that open source license proliferation is bad, due to redundant choice, and unnecessary incompatibilities. (To be fair to the history of the project: the license which we are relicensing to didn’t exist back when Open Watcom was open sourced. And it is only relatively recently that the free and open source communities have coalesced around a limited number of licenses.)

Prior art

There is prior art for relicensing large open source projects. Both Mozilla (Firefox etc.) and OpenSSL were relicensed. MAME as well.

Relicensing projects can take years. The basic procedure is that all historical contributors (copyright holders) are tracked down, and contacted. This can be difficult if email addresses were never given, or no longer work. Each contributor is politely asked to relicense their contributions.

If the contributor approves, great.

If not, there are a few options, which aren’t always ideal. The default option is to remove the code. The code can be rewritten, in an original way; the downside being this takes time, especially if somebody contributed a large, or many, changes. Sometimes you might get lucky, in that their contribution has already been removed, or rewritten, with the passage of time. Finally, trivial, few line, bug fixes or typo fixes probably do not meet the threshold of originality for copyright, and so permission may not be required. For example, contributing to GNU Emacs requires assigning your copyright to the Free Software Foundation, but this is generally not required for contributing fewer than fifteen lines of code.

Relicensing

Project formation

Because of these issues, there has been a desire, for a number of years, to relicense Open Watcom. This has gone (IMHO) from wishful thinking, to an ambitious project, to an almost-inevitability. For the full historical details of this relicensing project, you may wish to skim the GitHub discussion. Certainly, the discussion shows how many people have been interested and involved over the years, because relicensing is a huge project.

With the desire of several people to relicense, the next question is: how?

Non-approaches

SAP bought Sybase in 2010. As such, SAP, and only SAP, can create new versions of the Sybase Open Watcom Public License.

It had initially been hoped that SAP could simply put out a formal statement to “clarify” the license. However, the license has sufficiently many issues that a clarification would not be sufficient.

It had then be hoped that SAP could release a new version of the license. This license would have the issues fixed, perhaps by relabelling an existing common free and open source license. Then, under clause 7 of the license, you could choose to use Open Watcom under the new license. The good news is SAP are willing to help. The bad news is SAP (very reasonably) think that they can only relicense their own code, and specifically not code that others have since contributed to Open Watcom. This is disappointing, but we stress that SAP are being reasonable and moreover helpful, so the situation is annoying but it’s nobody’s fault.

Required approach

SAP are willing to relicense their own contributions under the Apache License, v2.0. Sebastian Wolf from SAP reached out to the community, to say such. This is important, because Sybase/SAP’s code is the original basis for Open Watcom. SAP will likely grant addition permissions, possibly the GCC Runtime Library Exception, or maybe more likely probably the LLVM Exceptions. These additional permissions will reduce the burdens on compiler users when linking against standard library code. SAP are now making a final decision on licensing.

Similarly to the aforementioned Mozilla, OpenSSL, and MAME relicensing, we then need to contact existing contributors, to ask for their permission to relicense their code. As before, the ideal scenario is we can get in touch, and they agree to relicensing.

SAP had originally proposed that they would host a new repository. First, SAP would re-open source Open Watcom v1.0. Then, the Open Watcom history would be recreated, by re-committing changes only from contributors who were happy with the relicensing. This was a very reasonable offer, which was appreciated. Nonetheless, Iain Nicol felt it would be simpler to simply delete (or rewrite) code which cannot be relicensed, as opposed to re-creating a new history. Under this alternative suggestion, SAP would relicense the historical Open Watcom v1.0 code. Fantastic. Then, creating a suitably relicensed version of Open Watcom v1.9 and v2.0 would be left to the community. SAP are deciding which approach to take.

v1.9 versus v2.0

Relicensing is beneficial to both communities. The arguments in favour, such as shipping in mainstream Linux distributions apply equally, both for v1.9 and v2.0. Thankfully it turns out many contributors are in favour of relicensing, in both communities.

Version 2.0 was of course forked from v1.9. Hence permission for relicensing (or failing that, having to rewrite lots and lots of code, etc...) is required of v1.x contributors, to be able to relicense v2.0. As said, relicensing v1.9 should also be beneficial on its own merits, for v1.9.

v1.9 contributors

Michal Necasek (the maintainer of v1.9), David Ryskalczyk (who helped a similar effort with MAME), and almost certainly others who I don't know (sorry), made a very strong initial pass at contacting contributors. Later, Saulius Krasuckas and Iain Nicol joined to help finish the effort.

The great news is all v1.9 contributors have been tracked down, and are open to relicensing.

However, we may need to go back to a few v1.9 contributors, and double check they are ok with the exact licence (depending on how general or specific the permission they have already given is). This is the easy part: it was tracking down everybody which was hard.

v2.0 contributors

In the table below, we note where people are v1.9 contributors. This isn't to make drama regarding the fork. It is simply because their permission was already required for relicensing v1.9 (and relicensing v1.9 is conversely is required for relicensing v2.0).

People who contributed to v2.0 only were specifically asked about their willingness to relicense under Apache 2.0 plus the LLVM Exceptions. Earlier on in the process, there was some uncertainty as to what additional permissions to the Apache license would be granted. But by the time v2.0-specific contributors were approached, there was reasonable certainty that the extra permissions would be the LLVM Exceptions. Regardless, several contributors are pretty relaxed about which specific new (free and open source) license is chosen.

This list of contributors is complete, up to and including 7 July 2023. However, we need to check if there were any new contributors since this date. (Note that for the most part, commit counts were calculated in May 2023, so the current counts may be larger.)

No. commits	Name in git log	Contact/approval status
14089	Jiri Malak	See Jiří Malák, on next line
356	Jiří Malák	v1.9 contributor (and v2 maintainer)
137	Jeffrey Armstrong	@iainnicol messaged on GitHub; question acknowledged and it is under consideration. Later, Iain asked for an update.
62	rdos314	See Leif Ekblad, on next line
62	Leif Ekblad	v1.9 contributor, and approval on GitHub
38	Michal Necasek	v1.9 contributor (and v1.9 maintainer)
22	bmanga	See Bruno Manganelli
21	unknown	20 of these have email addresses jmala@; see Jiří Malák. One is an RDOS related commit confirmed to be by Leif Ekblad; see said row.
14	Peter C. Chapin	v1.9 contributor (and v2 maintainer)
14	Bruno Manganelli	@iainnicol emailed the address in the git log. Response on 2023-05-21: “Thanks for the email and the effort you guys are putting behind the re-licensing. [...] I am happy to re-license my contributions under whatever license has been chosen.”
14	Christian Rendina	approval on GitHub
10	Peter Chapin	See Peter C. Chapin
7	Sam Izzo	@iainnicol emailed the address in the git log. Response on 2023-05-21: “No problem, I'm fine with that. Thanks for your efforts!”
7	beketata	@iainnicol emailed the address in the git log. Later, @sskras emailed in Russian.
6	sezero	See Ozkan Sezer
6	seyko	@iainnicol and @sskras emailed the address in the git log. Response on 2023-07-08: “Sure, I'd be happy to”.
6	Alexander Misel	approval on GitHub
5	Tim Hentenaar	@iainnicol emailed the address in the git log. Response on 2023-05-21: “I can say that I'm more than happy to consent to my contributions being relicensed under a less restrictive license, hopefully without any undue encumberment.”
5	Jeff Armstrong	See Jeffrey Armstrong
4	Wohlstand	@iainnicol emailed the address in the git log. Response on 2023-05-21: “There are SUPER news, I waited this moment for a while! [...] Yes, I agree, and I want license being changed into something more libre to allow legal mixture with a lot of nifty things!”. Also approval on GitHub.
4	Stas Sergeev	@sskras emailed the address in the git log. Response on 2023-06-29: “My contribution is too minor, so please treat this message as a copyright transfer: I trust you to do anything you want with my contribution, including the license change to any license you think suits. Therefore I donate my copyrights to these changes to you.”
4	Jonathan Campbell	@iainnicol emailed the address in the git log. Response on 2023-05-22: “I don't mind at all, go right ahead.”
4	Jens Staal	@iainnicol emailed the address in the git log. Response on 2023-05-21: “Yes I am definitely open for relicensing. Good luck!”
3	Wayne LaBelle	@iainnicol emailed the address in the git log. Response on 2023-05-21: “Sounds good to me. I approve re-licencing my contributions. [...] Thanks!”
3	Cameron Cawley	@iainnicol emailed the address in the git log. Response on 2023-05-28: “I'm OK with my changes being relicensed, particularly since it’s quite minor. Looking forward to the license change going ahead.”
3	Andrei Warkentin	@iainnicol emailed the address in the git log. Response on 2023-05-21: “Thanks for the write up and all the context. I am easygoing [...]. So I'd be okay with whatever you folks choose to do. Even if the license chosen is something other than what you've listed.”
2	Javier Gutiérrez Chamorro	v1.9 contributor, and approval on GitHub
2	Charlie Root	See Jiří Malák. This was due to default git settings.
1	Yvan Janssens	@iainnicol emailed the address in the git log, and @sskras later sent a reminder. Response on 2023-06-29: “I'm more than fine with relicensing it, especially since this will result in it being easier to redistribute/integrate.”
1	yamori813	approval on GitHub
1	Tomasz Konojacki	@iainnicol emailed a more recent email address. Response on 2023-05-22: “Sure, you're free to relicense my contributions.”
1	Th3T3chn0G1t	approval on GitHub
1	Steven Levine	v1.9 contributor
1	Stefan	GitHub username @GateLinker. @iainnicol contacted on Mastodon. Response on 2023-05-21: “Yes, I'm open for everything that helps the open-watcom project. And thanks for your efforts in preparing this step. I totally agree, that relicensing is an improvement for the project and the community.”
1	Shiz	@iainnicol emailed the address in the git log. Response on 2023-05-21: “Sure, relicensing to Apache 2.0 (with or without LLVM exceptions) is no problem at all for me.”
1	Paweł Stankowski	@iainnicol emailed the address in the git log. Response on 2023-05-21: “Sure, I'd be happy to relicense my contribution to Open Watcom.”
1	Ozkan Sezer	@iainnicol emailed the address in the git log. Response on 2023-05-21: “My contributions are minor, but yes I am open to relicensing them.”
1	OW Contributors	This is a (very large!) subset of Open Watcom v1.9 commits, squashed into one giant commit. As such this requires permission from contemporary v1.9 contributors. Thankfully, as above, we have approval from all v1.9 contributors.
1	Javier	@iainnicol emailed the address in the git log. Response on 2023-05-21: “Hello, thanks a lot for this effort. [...] there's no more code of mine left in any Open Watcom branch. Therefore the following is not required. But just in case: I license all my contributions to Open Watcom V2 under the terms of the Apache Software License, version 2.0, with the LLVM exception.”
1	James Kruth	@iainnicol emailed the address in the git log. Response on 2023-05-21: “I'd be happy to allow my contribution to be relicensed!”
1	Jake S. Del Mastro	@iainnicol emailed the address in the git log. Response on 2023-05-22: “Great to hear that SAP has agreed to relicense the compiler. I would be happy to allow for all my contributions to be relicensed as Apache 2.0. My only concern was the old license had some ambiguities with whether the license applied to code generated by the compiler or not, I would hope that any new license makes it very clear that code generated by the compiler is not subject to the license, however, as far as I understand it, the LLVM exception does this.”
1	Detlef Riekenberg	approval on GitHub
1	Detlef	See Detlef Riekenberg (same email address so isn't a coincidence)
1	Delilah Hoare	@iainnicol emailed a more recent email address. Response on 2023-05-26: “Yes, I’m happy to license my contributions to Open Watcom under Apache 2.0 with LLVM Exceptions. I’m glad to hear progress is being made on freeing Watcom.”
1	David Griffith	@sskras emailed the address in the git log. Response on 2023-07-03: “Any and all contributions I've made to Open Watcom are okay to relicense”. Also approval on GitHub.
1	Davide Pisanò	@iainnicol emailed the address in the git log. Response on 2023-05-21: “Sure, no problem, do what's best for the project.”
1	Count_MHM	approval on GitHub
1	Christoph Neidahl	@iainnicol emailed the address in the git log. Response on 2023-05-21: “I've been checking in on the license situation & relicensing effort every now and then, glad this is starting to come to a close! [...] I'm fine with my contributions being relicensed under that license [Apache 2.0 plus LLVM Exceptions].”
1	Christian Groessler	@iainnicol emailed the address in the git log. Response on 2023-05-23: “I'm happy and ok to relicense it.”
1	Bad Sector	@iainnicol emailed the address in the git log. Response on 2023-05-21: “Yes, i am fine with relicensing the code i contributed to Open Watcom.”
1	Azarien	approval on GitHub
1	Anders Carlsson	@iainnicol emailed the address in the git log. Sadly, he has passed away. His widow thinks “that Anders would be willing to do this”. Response on 2023-06-16: “You have my permission”.
1	Alexander Udovichenko	@sskras emailed the address in the git log. Response on 2023-07-02: “I fully agree to the change of license. [It can] be Apache-2.0 with or without LLVM [Exceptions]”