Dual licensing isn't the same as adding the GPLv3 termination conditions to GPLv2.

If you dual license, then if it's accepted under GPLv3 terms that means you have the replacability and anti-DRM provisions along with the termination grant.

If you accept under GPLv2 then you don't get the termination grant from GPLv3 but don't have to obey the replability or anti-DRM provisions.

Dual licensing isn't an 'AND' of licensing terms, it's an 'OR'.

https://www.zdnet.com/article/...

A fellow Samba Team member and Red Hat engineer has just pointed out to me that it's unfair to call out Red Hat specifically for this, and in retrospect I agree with him and would like to apologize to Red Hat.

Many others including my own employer Google also signed on to this statement as well.

Sorry Red Hat. Hats off to you for all your sterling Open Source work :-).

Here is a great retrospective on GPLv3 from a good friend of mine, Richard Fontana at Red Hat:

https://opensource.com/article...

One of the things he notes (that to be honest I'd forgotten about for my talk) is that Red Hat and others have lead the charge to adopt the "forgiveness" provisions of GPLv3 (which as I recall was one of the primary concerns of corporate lawyers taking part in the GPLv3 drafting process) into GPLv2.

To quote from the linked article:

> "This in turn was followed by a Red Hat-led series of corporate commitments to extend the GPLv3 cure provisions to GPLv2 and LGPLv2.x noncompliance, a
> campaign to get individual open source developers to extend the same commitment, and an announcement by Red Hat that henceforth GPLv2 and LGPLv2.x
> projects it leads will use the commitment language directly in project repositories."

From Richard's blog post:

https://www.redhat.com/en/blog...

> "As of today, all new Red Hat-initiated open source projects that opt to use GPLv2 or LGPLv2.1 will be expected to supplement the license with the cure
> commitment language of GPLv3."

A cynic would read that as an attempt by Red Hat to neuter possible adoption of GPLv3 with it's "problematic" (for corporations) anti-DRM provisions. In the words of one of my favorite fictional characters - "You might think that, I couldn't possibly comment" :-).

Note that I'm not saying Conservancy shouldn't continue their enforcement efforts. Far from it. I just want to try other things as well.

I have experience with license enforcement. I have done quite a bit of it behind the scenes (think about my own project to understand where this experience may have come from). It isn't working. There is a great asymmetry between individual developers and corporate legal departments that makes it virtually impossible for developers to successfully enforce their rights.

Look at the VMware case for the latest sorry example.

Maybe. But not all software is written by large corps.

But this isn't the point of the talk, and I don't want people to get hung up on that one idea.

The main point of the talk is that the asymmetry in power between individual developers and corporate law departments means that even if you pick copyleft licenses, it's almost impossible to get them enforced. Most developers have given up - full disclosure, I'm on the Board of Directors of the Software Freedom Conservancy who is (I'm going to make another claim here) the *only* organization that still tries to enforce the GPL. The FSF have long since given up on enforcement.

So let's concentrate on things that have a better chance of working - concentrate on opening up the protocols between software components and not getting bogged down in the licensing.

I have been around since "the early phase" of GPLv2. The adoption curve for GPLv3 and AGPL is different. It's unclear as to exactly why, although the co-opting of the most important FLOSS project (the Linux kernel) by corporations may be a big factor.

Remember, back when GPLv2 was created, gcc was one of the most important FLOSS (not that we called it that back then) projects and it was an early adopter of GPLv2. These days there is llvm as competitor. No compelling, category-defining GPLv3/AGPL programs exist to my knowledge.

I don't have *any* problem with the GPL. I was one of the people who helped author the GPLv3. I think it's a great license.

"rejected soundly" to me means the fact that the creators and curators of the license, the FSF, refuse to license some of their most important code under it (glibc for example).

If you think I have a "religious/political problem with the GPL" you don't know me very well :-).

Ask for help on the samba@lists.samba.org mailing list. We're very friendly !

> How many Linux SMB installations are vulnerable to this?

None.

>Microsoft is probably not alone in this.

Nope. In this case they are, actually. The added an SMB3 transform compression header which Samba doesn't implement (yet). There was a bug in their compression libraries. Hence the bug. Even if we did implement SMB3 transform compression we'd be using different compression libraries (which may have their own bugs of course - compression/decompression code is notoriously hard to get right).

> All these samba exploits have been a big *yawn*. Wormable it may be in theory, but a threat it won't be in practice.

Just a correction. This is not a Samba exploit. It's an exploit in Microsoft's implementation of the SMB3 protocol (which is native on Windows). Samba is *not* the same as the protocol - it's actually a separate open source project that implements SMB1/2/3 - https://samba.org./

Yeah I know it's easy to get the two mixed up. Even Microsoft marketing have done so on occasion :-).

Microsoft hasn't contacted us (Samba) so this almost certainly isn't a protocol level bug (they're *very* good about being proactive on these), but an error in their implementation of the SMB3 compression transform.

In other words, a typical buffer overrun in a compression library. Gee, wonder where I've seen these before.

Currently Samba doesn't implement that specific SMB3 compression transform header (we do implement the SMB3 encryption transform header, which isn't vulnerable), an example where being slow to implement a feature is an advantage for once :-).

So most Linux-based SMB3 servers and NAS boxes (which use Samba) will not be affected by this (I believe - things may change as more information becomes available).

Microsoft hasn't contacted us (Samba) so this almost certainly isn't a protocol level bug (they're *very* good about being proactive on these), but an error in their implementation of the SMB3 compression transform.

In other words, a typical buffer overrun in a compression library. Gee, wonder where I've seen these before.

Currently Samba doesn't implement that specific SMB3 compression transform header (we do implement the SMB3 encryption transform header, which isn't vulnerable), an example where being slow to implement a feature is an advantage for once :-).

So most Linux-based SMB3 servers and NAS boxes (which use Samba) will not be affected by this (I believe - things may change as more information becomes available).