Change the license of Open Watcom

[yuhong]

From the license:

"7. Versions of the License. Sybase may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. Once Original Code has been published under a particular version of this License, You may continue to use it under the terms of that version. You may also choose to use such Original Code under the terms of any subsequent version of this License published by Sybase. No one other than Sybase has the right to modify the terms applicable to Covered Code created under this License."

This would make it easy for Sybase/SAP to release a new version of the license that is DFSG-/FSF-free. Do anyone have contacts at them that can ask about this.

[ArmstrongJ]

I'm pretty sure Sybase had been asked in the (now distant) past and refused just because they didn't see the point. There is a "draft" version 2 of the license, but I'm guessing it can't just be adopted if it hasn't been adopted already. However, if someone really thinks they can convince Sybase otherwise, give it a try!

One thing to remember, though, is that Sybase doesn't hold copyright over all of Open Watcom any longer. Much of the current system has new files that are "Copyright Open Watcom contributors" with no attribution to Sybase. Changing the license outright to something that isn't just a follow-on to the Open Watcom Public License might be tricky.

[yuhong]

The non DFSG-free problem is probably the most important problem. VirtualBox had to be moved to contrib to Debian because of it.

[LocutusOfBorg]

Virtualbox Debian Maintainer here.
I would strongly support changing some bits of the license, we are trying again to get Vbox in Debian and Ubuntu main, and license is still a big issue.
You might want to read some analysis of the license and its problems here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431

and the Ubuntu effort to have virtualbox in main here
https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1605337

thanks!

[austin987]

Winetricks/wine developer here.

Openwatcom would be useful for win as well to be able to add tests for win16 code, but the current license and lack of availability in Debian/Ubuntu and other distros has prevented this. A more OSS friendly license would be greatly appreciated!

[michael-thayer]

VirtualBox developer. I wonder whether Sybase could publish some statement clarifying their intents in the licence which would still be good enough for Debian. I imagine that would be easier for them than changing the licence. Of course this would not make sense unless Debian says beforehand that they could live with this.

[LocutusOfBorg]

I can't speak for the community, but I personally think a clear statement clarifying the situation might really allow me to put a comment on the copyright file, with a reference on that statement, and I think ftpmasters will probably reconsider the license for the specific case.
But unfortunately I can't be sure without reading the statement, and without an ftpmaster authoritative answer.

[michael-thayer]

I would suggest starting by asking the ftpmasters what sort of a statement - if any - would satisfy them, and then asking Sybase if they could consider that.

[LocutusOfBorg]

https://lists.debian.org/debian-devel/2016/08/msg00003.html
I started a discussion here

[LocutusOfBorg]

Hi, seems like we can't accept a statement, because the license is too contradictory and problematic, but the nice thing is that you don't have too many relicensing issues
https://lists.debian.org/debian-legal/2016/08/msg00001.html

"As a consequence, it should be super-easy for Sybase to fix all the
licensing issues in a flash, provided they are willing to do so.
They just have to issue a statement where they declare that they
elect the Expat/MIT license [3] to be the next version (2.0)
of the "Sybase Open Watcom Public License": the OpenWatcom
compiler would instantly become available under the Expat/MIT license.
Or maybe they want to choose the Apache License Version 2.0 [4]..."

[ArmstrongJ]

As I stated, there is a version 2 of the Open Watcom Public License in draft form (warning: PDF link!) that Sybase never adopted. Someone needs to speak with them, but, again, they may be unwilling to bother with it. Additionally, I'm not sure many of the Open Watcom developers here care all that much or they wouldn't be working on Open Watcom in the first place.

The big problems with the license are some vagueness surrounding distributing source (it's currently interpreted similar to the GNU AGPL), some patent indemnification language, and specification of a venue for legal matters.

Regardless of the Debian's stance, the license is approved by the Open Source Initiative as being a valid "open-source" license. If it doesn't show up in Debian repos, I'll survive. Apparently it's causing issues with VirtualBox, but that doesn't really directly affect this project.

Changing the license would have to be done carefully. Open Watcom isn't just a "little compiler project" like GCC. It's a suite of compilers, a runtime library, and whole pile of development tools. Using any sort of viral license would be exceptionally bad as it would preclude use of the runtime library in projects with alternative license terms.

[ArmstrongJ]

@iainnicol I'm not completely familiar with the Apache 2.0 license, so I'll have to give it a read and maybe read up a bit more about its terms. It is unfortunate both that SAP didn't settle on a BSD license or something similarly simple and that the project has to go along with an uninterested company's corporate lawyers, but here we are...

[Conan-Kudo]

There was no way that was going to happen in the era of software patents.

[iainnicol]

Yeah, as @Conan-Kudo says, Apache 2.0 is a safe licence, because it grants a patent licence explicitly, but terminates that patent licence (IIRC) if you are a patent aggressor.

@ArmstrongJ The LLVM Exceptions https://llvm.org/LICENSE.txt then make Apache more permissive (IIRC by waiving attribution clauses etc). This makes the overall licence pretty unrestrictive, and suitable for compiler runtime and standard library. Hence being used by Clang and LLVM.

[sskras]

LLVM Exception is mentioned here with a try to decipher it into plain language a two comments below:
https://news.ycombinator.com/item?id=18699228#18699514

The first bit says effectively "this doesn't apply to compiler libraries [1] we link into your code".
The second bit effectively says "you can use this with GPLv2 code" (normal Apache v2 only is compatible with GPLv3).

[iainnicol]

@ArmstrongJ I was wondering if you have any new thoughts about the licence? Thanks.

[michael-thayer]

I suspect that the updated draft would not satisfy Debian either. How actively is Sybase working on the code base? If they have effectively let go of it then a reasonable argument (which may well still not be good enough for them) would be that changing to an MIT licence or similar would just be the last logical stage of letting go. Other companies have done the same in similar situations.

[ArmstrongJ]

Sybase has not, to my knowledge, contributed any code since the project was open-sourced; they only provide some infrastructure and Perforce licenses to mainline Open Watcom development (which stalled out years ago).

Sybase would need to specify that "The Sybase Open Watcom Public License Version 2 is the MIT License," as an example. They do not hold copyright over all of Open Watcom, and they cannot unilaterally "change" the license. The project's license would need to be upgraded to OWPL v2, which might happen to be worded exactly as an MIT, BSD, or Apache license. I'm not particularly concerned with the Debian project's particular misgivings about this license, though.

[LocutusOfBorg]

that would fix every issue I think

[owainkenwayucl]

I've been looking at the wording of the license and trying to work out what implications clause 2.2. has if you distribute binaries built with the compiler (mostly for my own interest because I have no intention of doing so, I just use it to do some hobby programming on a FreeDOS PC in my free time).

It seems to me that if you distribute a binary built with the compiler it will contain libraries, run-time etc which would make it deploying portions of the "Covered Code", triggering all the source redistribution clauses.

Overall this means that although you can technically use the compilers commercially for "non-personal/R&D" use, you can't really in practice?

Am I reading this correctly or am I just being really license correctness paranoid?

[sskras]

@ArmstrongJ:

Sybase [...] They do not hold copyright over all of Open Watcom, and they cannot unilaterally "change" the license.

Jeff, do you mean the new code from the post-Sybase contributors, individual persons here?

If they are required to approve changing the OWPL v1.0 into one with different name (which I believe to be rational), then what is the reason / legal mechanism that would allow to avoid such aprovement when increasing the version number of OWPL?

My guess is that any, even smallest change (such as a version number) in a license obtains the same requirements. So contacting individual persons who have contributed would be still required (IMHO).

[tbullock]

As it's currently october, 2021, can someone who's been more involved speak to what the current status of this is and perhaps which tasks are imminently in need of management. Although I have not been involved in contributing to the OW project directly, I have been using it extensively for nearly 2 years and the license issue has always been problematic for me.

At the time of writing this I do not see an openwatcom release in the SAP github project list?

Can I also make one further request regarding licensing if this discussion can still happen. Specifically rather than use the Apache license with exemptions, can I suggest that contributors re-license under something more permissive such as the BSD or ISC license. Adding all the extra language of the Apache license to just add an extra exception is a little burdensome when something simple like the ISC license could handle all the predominant issues in a screen of 80x25 character.

[LinoMastro]

@SebastianWolf-SAP , it might be worth politely mentioning in the email sent to the contributors that if they do not wish to re-license, their code will necessarily have to be removed from the new open-source OW repository, and on the other hand if they accept to provide their code under the new license, lots of OW users in the community will benefit and be very grateful.

Obviously the wording should not sound pushy or upsetting, but it's worth being explicit that this is not an academic choice between two similar licences: there are very practical consequences if too many contributors are not willing to provide their code under the new license, people will have to spend considerable time to reimplement their contributions from scratch or live without them.

[SebastianWolf-SAP]

@LinoMastro Just to avoid misunderstandings, the code of people who don't want to re-license their contributions simply won't be added to a potential new repository as we need to start with the code from the original open source publication - see my post for details. It's correct though that it would be very beneficial if people re-licensed their contributions - otherwise it would be very tricky to re-establish a new project that is on a par with the existing OpenWatcom project.

[tbullock]

I believe that the issue with licensing with the apache 2 license was mostly that there is controversy about whether it's compatible with gpl v2. I'm guessing that the llvm exception somehow circumvents that compatibility issue, but truly I don't understand the details of that whatsoever.

Personally my view, and again, I'm a user here, not a copyright holder, is that the BSD/MIT/ISC copyright statements are much less verbose and preferable (to me), and FAR easier to actually understand and follow. The fact that the Apache license language needs to have a special exemption to handle some sort of edge case of legalese is REALLY REALLY bad mojo and I genuinely think should be avoided. Like consider the ISC license template from OpenBSD for example, it's dead simple even someone like myself with literally no legal training can easily understand in a few seconds.

/*
 * Copyright (c) YYYY YOUR NAME HERE <[email protected]>
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

I cannot believe that many (any?) of the stake holders are particularly invested in the terms of the apache license, nor would be able to state them simply if asked casually, nor would they understand why the specific exemption to the license was important.

TLDR: More words bad, less words good

The word count alone should be enough to dissuade people from using the apache license tbh:

ISC License:

• 108 Words
• 749 Characters
• 629 Characters without space

apache v2 with llvm exception:

• 1,711 Words
• 12,261 Characters
• 9,377 Characters without space

Here is the Apache license with the special exception for comparison:

                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

    TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

    1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

    2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

    3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

    4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

    5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

    6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

    7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

    8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

    9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

    END OF TERMS AND CONDITIONS

    APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.


--- LLVM Exceptions to the Apache 2.0 License ----

As an exception, if, as a result of your compiling your source code, portions
of this Software are embedded into an Object form of such source code, you
may redistribute such embedded portions in such Object form without complying
with the conditions of Sections 4(a), 4(b) and 4(d) of the License.

In addition, if you combine or link compiled forms of this Software with
software that is licensed under the GPLv2 ("Combined Software") and if a
court of competent jurisdiction determines that the patent provision (Section
3), the indemnity provision (Section 9) or other Section of the License
conflicts with the conditions of the GPLv2, you may retroactively and
prospectively choose to deem waived or otherwise exclude such Section(s) of
the License, but only in their entirety and only with respect to the Combined
Software.

[jmalak]

I hope it won't be a big deal. Contributions are very specific to OW, so I don't see why contributors shouldn't allow re-licensing, especially if it's a more open license.
Rather problem will be contact all contributors, some could be non-active or not available.
The occasional contribution could be re-implemented but if some of main contributors will not confirm re-licencing or will not be available it will be hard.

[sskras]

@tbullock wrote:

Personally my view, and again, I'm a user here, not a copyright holder, is that the BSD/MIT/ISC copyright statements are much less verbose and preferable (to me), and FAR easier to actually understand and follow.

Yes, but I say you should also remember why do licenses exist at all.
IMO, they are here due to the Law of intellectual property or similar. So for first they should be clear for software / I. P. lawyers.

And namely here BSD/MIT statements generate some legal mess (as is mentioned in the article from the lawyer K. E. Mitchel which I refered to in my comment circa 2019).

Recently I also made a summary about this in a foreign issue nuta/kerla/issues/5, which I would like to quote here too:

• MIT and BSD don’t handle patents.
• MIT and BSD are hard to read.
  (In the eyes of I. P. / legal guy)
• It’s not clear what MIT and BSD are, legally.
  (licenses, or licenses and contracts, or both, or potentially both?)
• MIT and BSD attribution is a land mine.
• MIT and BSD breed confusion.
  (many variants, uncertainty filling authorship information)
• MIT and BSD don’t expect more contributors.

So in the eyes of a lawyer, MIT/BSD are not without problems.
Not sure what would that guy say about ISC statements.

The fact that the Apache license language needs to have a special exemption to handle some sort of edge case of legalese is REALLY REALLY bad mojo and I genuinely think should be avoided.

Yes, that too. Quoting another piece from my summary (of that article) about Apache Public license:

• Rules and expectations are very complex.
• It’s not clear if or how the contribution-licensing conditions work.

So, mainly yes:

TLDR: More words bad, less words good

But that also needs a legal skill. That's why the aforementioned lawyer created something I would call a better middle between the two camps:

the Blue Oak Model License.

BTW, would you count word/character stats for it? They would be interesting to compare.

The only two drawbacks of BOML I see would be:

• its' spread is relatively narrow at the moment;
• it's unclear at what degree it's compatible with the GPL.
  (But it's on the FSF license review queue already)

[bartoldeman]

I'm one of the contributors to OW, though it's been quite a few years!
I'm very happy to see its license finally changed (I've always considered it awkward), and consent to my contributions being placed under the Apache 2.0 license or any other FSF-approved free-software license.

[stratvox]

Hello there! I was recently contacted about some work I did on that decades back. AFAIC I'm happy to permit a more open license for OpenWatcom.

That was back in the mid-nineties; I'm having a hard time even remembering what I did, though I do remember I did /something/ for it. Bleah :D

Cheers all, and best of luck on the quest!

[sskras]

Cheers to the oldschool folks!

[MetalMaxMX]

Hey. So, how are things going with the relicensing of OpenWatcom? Any news so far?

[iainnicol]

@MetalMaxMX to answer your original question...

Disclaimer: I can't speak on behalf of anybody else.

However, it seems to me there's critical mass to make this happen. This feels like a 'when', not an 'if'.

Almost every Open Watcom v1.9 contributor has now been contacted and is on board with the relicensing. I and sskras resumed contacting v1.9 contributors, but it turns out a lot of the groundwork had been done by d235j and Michal N. Regarding Open Watcom v2.0-only contributors, there are a still a handful to reply. On the other hand, we only started contacting most of them four days ago. You can see a breakdown of contributor statuses on the wiki.

Because I think we have now enough contributors on board to make this a success, I've asked SAP to kindly resume the work on their end. SAP gave basic approval (at least in principle) a couple years ago. However, they now have to make some final decisions, regarding licensing and procedure. SAP have now restarted this from their end, which is great. Of course, legal due diligence can't be rushed, and they're resuming from something started a couple years ago, so of course we will wait patiently.

[SebastianWolf-SAP]

Thanks, @iainnicol for your work and for summarizing everything after our direct conversation. I can only confirm your statement here and will let you know once I have an update.

[MetalMaxMX]

@iainnicol Hi thanks for answering and sorry to reply a bit late! I am so glad that it seems things are moving forward toward the relicensing of the Watcom compiler. If anything more happens, do tell me. I do wonder however if we got everything needed to relicense the original official Watcom 2.0 release by their original authors or this fork too? Ideally, I assume we should have all the versions of the Watcom compiler relicensed. From the oldest to newest release?

[iainnicol]

Heya @MetalMaxMX, no problem about the delay. We all move io to other things...

Yeah, so it turns out we got most permissions for v2. One person couldn't be tracked down, but they don't have enough lines of code remaining for it to be a problem. Another contributor hasn't agreed, so we need to rewrite their code.

Relicensing old versions... I think I see where you're coming from, but it's unfortunately infeasible. To be honest we have been staggeringly lucky, with the number of contributions willing to relicense. So, once we are done (this is not legal advice) it may be reasonable to consider any old version as being 90%? 99%? under the new license (if you update the headers). But there is still that 10% or 1% of code which there was not relicensing permission for. It's a smaller task to remove that code once for the latest version, than for every interesting old version.

[MetalMaxMX]

@iainnicol Ah fair enough, I'll admit that when it comes to the topic of relicensing things can get fairly murky the older you go back. Though I think having both 2.0 and the fork relicensed are already big enough steps as they are. But that such a high number of contributors have agreed to relicense is really, really good news.

I suppose the last major task (outside of rewriting the contributor's code) is to wait for SAP on their end right? Though since you added that because it is a legal matter, it will take a fair amount of time. Though that is no problem, so long as a solution is eventually reached down the line, things will move in a positive direction from there.

[stratvox]

I'm JackT, and I have already approved the new license. The email I submitted under is long defunct. Cheers! Jack

…

On Tue, Jan 31, 2023 at 2:46 PM Jiří Malák ***@***.***> wrote: I'll ping the volunteers who compiled the information. Currently, I don't have access to the spreadsheet anymore... :( I exported all commiters from OW perforce repository with e-mail addresses, it could help. Commiter e-mail Alexander Kobets akobets_at_mail_point_ru AxelH Bart Oldeman Bartosz Polednia bartosz_at_chill_point_com_point_pl Bob Piskac bob_at_pbsoftware_point_com Bryce Simonds kfiresun_at_gmail_point_com Carl Young carly_at_openwatcom_point_org Daniel Cletheroe David Azarewicz david_at_88watts_point_net David Golub golubdr_at_gmail_point_com DavidM Dmitry V. Uvarov dmitri_point_uvarov_at_gmail_point_com DmitryM Dr. Lawrence W. Haynes ErnestK Frank Beythien Gregg Young ygk_at_qwest_point_net Hans-Bernhard Broeker Hartmuth Gutsche hgutsche_at_xplornet_point_com CharlesL Christof Meerwald cmeerw_at_web_point_de Jack Schueler JackT Jan van Wijk JavierG Jiri Malak malak_point_jiri_at_gmail_point_com Jim Buckeyne jbuckeyne_at_greater_point_net Jim Shaw jimshaw_at_iinet_point_net_point_au Jiri Malak Johannes Diedrich JDiedrich_at_t-online_point_de Ken Blackburn KenBlackburn_at_us_point_nc_point_rr_point_com Kendall Bennett Leif Ekblad leif_at_rdos_point_net Lynn McGuire MarkO watcom_at_markoverholser_point_com Mat Nieuwenhoven Michal Necasek Norbert Matzke Paul S. Person Peter C. Chapin PChapin_at_vtc_point_vsc_point_edu PeterS Philipp Diethelm dip_at_646_point_ch Roald Ribe Roman Trunov script_daemon StephanL StephenH SteveA Steven Levine Vesa Jaaskelainen WalterB Wilton Helm Anyway I could help with integration too. — Reply to this email directly, view it on GitHub <#271 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJFZUMJCFG3V2WK6HQEJTRTWVFTZLANCNFSM4XSTDLJQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[Conan-Kudo]

Hey folks, long-time occasional user of OpenWatcom and current Fedora Linux contributor. I'm super-excited to hear that the OpenWatcom licensing situation is (slowly) being resolved by @SebastianWolf-SAP and OpenWatcom contributors!

I've wanted to see OpenWatcom packaged in Fedora for so many years, and once it is relicensed to Apache-2.0 with LLVM-Exception, I look forward to helping bring it into Fedora Linux to enable so much retro awesomeness. 😄

If there's anything I can do to help, please let me know, and I'll try my best!

cc: @davide125 @mattdm

[iainnicol]

Per @sskras's suggestion, I have created a wiki page on relicensing. I've added background information, because I want information to link to, when asking people to relicense. (There's obviously been a lot of great work in this discussion already, but IMHO it's too much information to unpack).

Either today or in the next couple days, I will add the main bit to the wiki page, namely a table of Open Watcom contributors, and relicensing contact/approval status.

I won't start off by emailing everybody. I'll focus on the top few contributors (not already aware), without whom this might be infeasible. Fingers crossed they're receptive.

If. If. If those top contributors are receptive then I guess, @SebastianWolf-SAP, can I politely ask you to resume what needs done on your end? We haven't spoken before (and I'm just a random Openwatcom user / retro computing enthusiast). So I want to pass on my gratitude to your and your colleagues for being receptive to relicensing. Thanks for both your time and the corporate ethos which allows that.

I think I have two questions for you, Sebastian:

1. Shall we finalise the licence selection? You seem 100% certain about Apache 2.0. But what about the additional permissions grant - are you also going with the LLVM Exceptions? I agree with others that would be a fine choice. You initially mentioned the Runtime Library Exception. I don't know if this is a typo, because if you mean the GNU one, it has two downsides compared to the LLVM one. One, the GNU one is tied to GCC, so would need reworded. Two, the GNU one is a grant on top of the GPLv3, in contrast to the LLVM one which is on top of the Apache licence. Of course, I would probably take a GNU style one over nothing, but IMHO the LLVM one is a better fit.

2. In terms of SAP owning the new repository, are we adding unnecessary friction? The related question is, for merging code, do you need formal DCOs, or just any kind of permission e.g. an email or comment on github? I politely suggest it may be easier/less paperwork required if SAP were to simply re-release their initial version, but leave it to others to do the re-integration in a separate repo not controlled by SAP. Like, I understand the principle of starting from scratch, that we can't re-license v1.9 or v2.0 immediately through wishful thinking. Nonetheless, as an individual I am happy with merging code if somebody emails or writes on github that they give permission to relicence, whereas SAP as a large business reasonably may prefer a DCO.

[iainnicol]

@sskras scratch that, Michal has shared with me, thanks.

Also I wonder if I have a lead on an email for Javier Gutierrez from the v2 repo

[javiergutierrezchamorro]

You can count with me too.

[iainnicol]

@Azarien and @Count-MHM: you both contributed a patch to Open Watcom v2, but I don't know your email address.

We are trying to relicense Open Watcom under a more conventional license. And I think we're reasonably close to that happening. Would you each be open to relicensing your commits (under Apache 2.0, probably plus the LLVM Exceptions)?

[Count-MHM]

Absolutely!

[Azarien]

Yes.

[d235j]

As one of the people who helped assemble the list, yeah we did get pretty far.

Is anyone here good at converting Perforce history (ideally including branch/merge history) to Git? IIRC MichalN was having difficulty with that and I did not have time to continue working on it.

[iainnicol]

Yeah, it seems like the v1.9 Perforce repository still exists (for example, despite the website being replaced). There's a reference just last month to pushing changes to it: https://www.os2museum.com/wp/hash-tables-ftw/

Jiří, David also mentions branches. The OW 1.9 git repo is great, but it's only the main branch. I don't know much about the Perforce repo—I've never seen it—but I infer there are a couple other branches, even if they're quite old now.

[iainnicol]

P.S. @d235j I could give it a stab, if required. I've never used Perforce before. However, I've successfully done hg to git migrations. So while I don't want to sound overconfident, I might have the knack required. Looking at the git p4 manpage, it doesn't look like syncing branches is much harder than syncing the main repo.

And yes, you did a bloody great job tracking down so many people AND persuading them.

[d235j]

git-p4 has various limitations; we were looking at using Perforce Git Fusion but it's a mess to set up.

@iainnicol Are you on IRC?

[iainnicol]

@d235j i'm iainn on the IRC

[jmalak]

Yeah, it seems like the v1.9 Perforce repository still exists (for example, despite the website being replaced). There's a reference just last month to pushing changes to it: https://www.os2museum.com/wp/hash-tables-ftw/

Jiří, David also mentions branches. The OW 1.9 git repo is great, but it's only the main branch. I don't know much about the Perforce repo—I've never seen it—but I infer there are a couple other branches, even if they're quite old now.

In this case you need copy of P4 repository from perforce server or access to this P4 server. P4 is centric solution not as git.

[Wohlstand]

I sent a reply to the direct letter. But I'll also copy my letter to here for everyone:

Hello!

There are SUPER news, I waited this moment for a while!

I hope, we finally can take the part of implementations from llvm to make C++ standard being more complete. Because there was a BIG problem that lack of proper support of C++ standard and license was an inability to import a lot of nifty things from GCC and CLang to make OpenWatcom being a good compiler toolchain that can be used to make DOS software, and just use it for other purposes.

Yes, I agree, and I want license being changed into something more libre to allow legal mixture with a lot of nifty things!

Go ahead!

[pchapin]

To be clear, I don't think the use of the LLVM exceptions in the licensing language is intended to imply that there is any plan to incorporate LLVM technology into Open Watcom. At the moment it is a licensing matter, not a statement of intended technology transfer.

The question of whether and how much LLVM technology should be used in Open Watcom is worthy of discussion, but that is a separate, unrelated conversation to this one. However, I do appreciate that the new license might make using LLVM technology legally feasible. It is certainly good to have those options.

[Conan-Kudo]

It opens the doors of leveraging either GCC or LLVM technology as OpenWatcom will be license-compatible with both. That can only bring good tidings for OpenWatcom.

[Wohlstand]

To be clear, I don't think the use of the LLVM exceptions in the licensing language is intended to imply that there is any plan to incorporate LLVM technology into Open Watcom. At the moment it is a licensing matter, not a statement of intended technology transfer.

The question of whether and how much LLVM technology should be used in Open Watcom is worthy of discussion, but that is a separate, unrelated conversation to this one. However, I do appreciate that the new license might make using LLVM technology legally feasible. It is certainly good to have those options.

I meant not "go to use X or die!", I meant just, an ability to take small code pieces that implements various parts and simplify the implementation of the bigger thing. At the same time, others will be able to freely take OpenWatcom's parts for various purposes, or, for example, make Linux ports of GUI apps are part of OpenWatcom. Right now I have to use Wine to run these things.

[sskras]

Folks,

at least when the switch to Apache-2.0 (or whatever) is over, I still suggest considering the Blue Oak Model License (BlueOak below).

It was crafted by a lawyers of Intellectual Property who love F/LOSS: https://blueoakcouncil.org/2019/03/06/model.html

I consider BlueOak being a quality upgrade to both MIT/BSD and Apache-2.0 as mentioned above. Mostly due to its' features:

• Language Simplified
• Permission Clarified
• Contribution Expected
• Attribution Demined
• Uncertainty Avoided

---

I also acknowledge that considering it right now might:

• create an additional load for the SAP OSP Office of reviewing it.
• leave the community uncertain to a degree about the compatibility with GPL v2 until FSF reviews it.
  The ticket is [gnu.org #1760802].

Both things would probably take an additional time. Anyways, I think it's worth the time.

On the positive side, BlueOak creators said they see no obstacles to compatibility with GPL v2:
https://sts10.github.io/2023/01/26/exploring-new-software-licenses.html#obligatory-note-on-license-compatibility

The Council doesn’t see any reason why software licensed under the Blue Oak Model License 1.0.0 can’t be used, combined, and distributed with software under GPLv2, LGPLv2.1, GPLv3, LGPLv3, or AGPLv3.

[...]

Some have argued that GPLv2 and Apache 2.0 are incompatible, [...] Without commenting on the accuracy of this analysis, the Council notes that the Blue Oak Model License doesn’t have patent termination, so this hypothetical conflict cannot occur between the Model License and the GPL.

While BlueOak sits in the reviewing queue of FSF's Licensing and Compliance Team, I also happened to talk to their licensing volunteer lawyer Paulius Galubickas (@i4paga) recently.

Paulius kindly made a quick, personal evaluation of BlueOak in our private conversation:

"I've looked at the Blue Oak licence, and in my personal opinion it would be considered compatible with the GPL. It is a permissive type of license, not very different from MIT or BSD."

(Translated from Lithuanian)

Also one of the BlueOak authors, Kyle E. Mitchell (@kemitchell) made some points about switching license in an open source project:
https://writing.kemitchell.com/2022/03/07/Switching-Open-Software-Terms

---

Longs story short:

it looks to me like BlueOak is a modern and compatible work done by professionals who know the context very much.
Hence my kind reminder (only if a bit repetitive:)

[Conan-Kudo]

I'm generally not a fan of permissive licenses, especially for software being maintained by hobbyists (I would have preferred OpenWatcom to adopt the same license that GCC uses). That said, Apache-2.0 with LLVM-Exception is pretty well understood now, and SAP's legal team is fine with it. I'm happy to take that, since it resolves the problem that blocks OpenWatcom from being packaged in Fedora.

And yes, OpenWatcom could change the license later if the community desires, but that's not a conversation for now. That's a conversation for after this is dealt with.

[sskras]

Fully agreed, and my comment didn't stress about the priority. Surely I could remove it if it hurts the current things.

[iainnicol]

@jmalak Please excuse my pedantry here. The minor problem is there are a couple v2 commits, where the author name is not clear:

• do call configure script right way
• fix division by zero in C++ compiler

Were these commits by you? There are a couple reasons I think they might be:

• You're the only other person to have modified these files (at least in v2)
• The changes were directly committed to the repo, without a pull request. So if not you, it was presumably another member of the GitHub organisation.

Thanks.

[pchapin]

Are these changes too small to be relevant to the relicensing effort?

[iainnicol]

Yeah, you're probably right. It caught my curiosity, when I was going through the list of commits.

[jmalak]

Sorry, if I remember correctly it is my commits. I submit it directly with unconfigured git.

[iainnicol]

Thanks for the explanation. That makes sense. But as Peter said, I was being quite pedantic :-)

[jmalak]

No problem, I understand. Now all is identified.

[ecm-pushbx]

I posted an issue to the JWasm repo about the usage conditions of JWasm and JWlink, which are forks of OpenWatcom's assembler and linker. It's at Baron-von-Riedesel/JWasm#20

(If you are unaware, JWasm is an, in my experience, very high fidelity recreation of Microsoft's Macro Assembler. I use it for some projects of my 86-DOS-related works.)

[tkchia]

Hello all,

Just dropping by to say that I would be happy to see Open Watcom released under a DFSG-free (edit: as in DFSG-compliant) license — even if it might only cover Sybase's Original Code.

Thank you!

[Wohlstand]

"DFSG-free"

Sounds ambigious, sounds like meant the "free from DFSG" or "without DFSG". If you meant "meets to DFSG terms", I recommend you to phrase this differently.

[tkchia]

Indeed, you are right. Thank you!

[Conan-Kudo]

"DFSG-compliant" is probably the more accurate phrase.

[Wohlstand]

Any further news about this thing?

[SebastianWolf-SAP]

Just reached out again to our legal team about this, thanks for reminding. Of course, it was still on my to-do list, but the beginning of the year was really tough, so I'm a bit late to follow up. :(

[MetalMaxMX]

Hey @SebastianWolf-SAP, we're now in April! Do we got any updates or anything of the sort? :)

[SebastianWolf-SAP]

I'm still here and we still have the same issue as last year. Please believe me, it's as frustrating to me as it is for you folks.

[MetalMaxMX]

Hello! Just bumping here as we are a few days from August. I would like to know what exactly are the showstoppers and if there's anything the community can do to solve them?

[SebastianWolf-SAP]

I have a reminder on that coming up every other week and I'm continuously following up with the folks internally here, but so far no progress on the root cause. I'm sorry that I can't share any details about the detailed showstoppers with anyone outside of SAP. Therefore, the community also can't do anything here.