AzureAD and shares
-
@travisdh1 said in AzureAD and shares:
@scottalanmiller said in AzureAD and shares:
@brandon220 said in AzureAD and shares:
FFIEC Cybersecurity Assesment Tool
It is REALLY fishy that a government agency is trying to put small banks at risk and goes directly against requirements for the big institutions.
Have you DEALT with a government agency lately? Just last week I had to fix a client's access to the Social Security billing system which is forcing use of Internet Explorer 11 to run software that downloads on demand and establishes a VPN into the main billing system database. They think they're secure, but use a security model from the 90s at best on old browsers that should have been retired.
They don't think they are secure - they just have a platform that 'worked' in the 90's and amazingly still works, so they won't update it.
-
@Dashrender said in AzureAD and shares:
@travisdh1 said in AzureAD and shares:
@scottalanmiller said in AzureAD and shares:
@brandon220 said in AzureAD and shares:
FFIEC Cybersecurity Assesment Tool
It is REALLY fishy that a government agency is trying to put small banks at risk and goes directly against requirements for the big institutions.
Have you DEALT with a government agency lately? Just last week I had to fix a client's access to the Social Security billing system which is forcing use of Internet Explorer 11 to run software that downloads on demand and establishes a VPN into the main billing system database. They think they're secure, but use a security model from the 90s at best on old browsers that should have been retired.
They don't think they are secure - they just have a platform that 'worked' in the 90's and amazingly still works, so they won't update it.
No, I talked with their support people, they insist that their "system" is secure.
-
@Dashrender said in AzureAD and shares:
@travisdh1 said in AzureAD and shares:
@scottalanmiller said in AzureAD and shares:
@brandon220 said in AzureAD and shares:
FFIEC Cybersecurity Assesment Tool
It is REALLY fishy that a government agency is trying to put small banks at risk and goes directly against requirements for the big institutions.
Have you DEALT with a government agency lately? Just last week I had to fix a client's access to the Social Security billing system which is forcing use of Internet Explorer 11 to run software that downloads on demand and establishes a VPN into the main billing system database. They think they're secure, but use a security model from the 90s at best on old browsers that should have been retired.
They don't think they are secure - they just have a platform that 'worked' in the 90's and amazingly still works, so they won't update it.
It didn't work then either, they just know that their customers aren't very smart or concerned.
-
@scottalanmiller said in AzureAD and shares:
The OS license changes is mostly a change to how you use the code, not the product.
Not with AGPL. Say you modify a FreePBX script that comes with the software for some reason. You have to make that available to the customers using your software along with the original source.
Or another example is you modify the script that comes with NextCloud to correctly set SELinux labels (that's definitely happened here). You need to make that modification and the original available to the users of the software. GPLv3 doesn't deal with networked software, which is why AGPL was created.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
-
@stacksofplates said in AzureAD and shares:
@scottalanmiller said in AzureAD and shares:
The OS license changes is mostly a change to how you use the code, not the product.
Not with AGPL. Say you modify a FreePBX script that comes with the software for some reason. You have to make that available to the customers using your software along with the original source.
Or another example is you modify the script that comes with NextCloud to correctly set SELinux labels (that's definitely happened here). You need to make that modification and the original available to the users of the software. GPLv3 doesn't deal with networked software, which is why AGPL was created.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
While minor, those are code changes. I see what you mean. But I always keep those things vanilla, because they need to be updated with every download. If I wanted to change those things, I'd do so in the public repo. From an IT perspective, I'd be making those modications outside of those scripts themselves.
-
@scottalanmiller said in AzureAD and shares:
@stacksofplates said in AzureAD and shares:
@scottalanmiller said in AzureAD and shares:
The OS license changes is mostly a change to how you use the code, not the product.
Not with AGPL. Say you modify a FreePBX script that comes with the software for some reason. You have to make that available to the customers using your software along with the original source.
Or another example is you modify the script that comes with NextCloud to correctly set SELinux labels (that's definitely happened here). You need to make that modification and the original available to the users of the software. GPLv3 doesn't deal with networked software, which is why AGPL was created.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
While minor, those are code changes. I see what you mean. But I always keep those things vanilla, because they need to be updated with every download. If I wanted to change those things, I'd do so in the public repo. From an IT perspective, I'd be making those modications outside of those scripts themselves.
I agree, but we've had real world cases here on this site where it's happened. It's important for people to know that those changes still legally count.
-
@scottalanmiller said in AzureAD and shares:
From an IT perspective, I'd be making those modications outside of those scripts themselves.
From what I've seen it's murky if you don't have to provide those also. I've seen some people say that things written along side of the application need to be made available also.
I guess my overall point is that it's not cut and dry with these licenses and it's sometimes a good amount of work. Look at the amount of discussion we've had on it already and it's not even that in depth.
-
@stacksofplates said in AzureAD and shares:
From what I've seen it's murky if you don't have to provide those also. I've seen some people say that things written along side of the application need to be made available also.
People claim lots of things, but if that is the case, then the risks of open source instantly apply to proprietary, and all concerns of OS are gone (relatively speaking.) Unless the risk comes solely from modifying the code itself, the open vs close debate is off as the risks become equal.
-
@stacksofplates said in AzureAD and shares:
I guess my overall point is that it's not cut and dry with these licenses and it's sometimes a good amount of work. Look at the amount of discussion we've had on it already and it's not even that in depth.
I'm not convinced of that. I think that legally it is pretty cut and dry and people are fans of scare tactics. That would never hold up in court because the license would extend to teh OS, hypervisor, bios and other impossible things. It's a non-plausible license that would make the software simply impossible to use if it were true and would have to be removed from the market as an attempt to trick people with no possible use case.
If the licenses aren't cut and dry, that protects OS from concern. It's that simple. By making it extend to other code, you give unlimited risk to all ilcenses, that one is open isn't a factor.
So, if cut and dry, it's not a real issue. If not cut and dry, not an issue of open source. So in either case, open can't be a concern.
-
@scottalanmiller said in AzureAD and shares:
@stacksofplates said in AzureAD and shares:
From what I've seen it's murky if you don't have to provide those also. I've seen some people say that things written along side of the application need to be made available also.
People claim lots of things, but if that is the case, then the risks of open source instantly apply to proprietary, and all concerns of OS are gone (relatively speaking.) Unless the risk comes solely from modifying the code itself, the open vs close debate is off as the risks become equal.
I think you're missing my point. I'm not saying one has more or less risks than the other. I'm saying that both have them. They both take understanding. You (the editorial you) can't say proprietary licensing is hard and takes a lot of time, and say open source doesn't. Same the other way around. They both take time and understanding in how the language is actually written.
-
@stacksofplates said in AzureAD and shares:
@scottalanmiller said in AzureAD and shares:
@stacksofplates said in AzureAD and shares:
From what I've seen it's murky if you don't have to provide those also. I've seen some people say that things written along side of the application need to be made available also.
People claim lots of things, but if that is the case, then the risks of open source instantly apply to proprietary, and all concerns of OS are gone (relatively speaking.) Unless the risk comes solely from modifying the code itself, the open vs close debate is off as the risks become equal.
I think you're missing my point. I'm not saying one has more or less risks than the other. I'm saying that both have them. They both take understanding. You (the editorial you) can't say proprietary licensing is hard and takes a lot of time, and say open source doesn't. Same the other way around. They both take time and understanding in how the language is actually written.
Okay, that I buy. Licensing is hard, period. But it's never a reason to avoid open source. Closed source carries all risks of open source, and more. That doens't mean open source doesn't have risks, just fewer.
