SMB3 is usually encrypted by default. The "locks" on it are very well designed these days.
Microsoft considers SMB3 with transport encryption secure enough that it's used as an ingress point for their Azure cloud.
There are no known vulnerabilities in the SMB3 protocol. Implementations however, of course, can and do contain bugs.
"companies still stuck with samba clients"
You mean running Windows
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'.
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
To write good code is a worthy challenge, and a source of civilized delight. -- stolen and paraphrased from William Safire