This is an interesting yet very frustrating read. Every few weeks we see a post on HN about an MIT-licensed project that gets picked up by AWS or Azure and the general response is "should've been GPL". This case right here highlights that in France that doesn't work either.
Their equivalent of AT&T used GPL software (admitted to it) but claims that it's a contract issue and not a copyright one so the case gets thrown out.
Slight correction: it is usually "should've been AGPL".
Not that it usually actually matters, because if you are a smallish company making most of your money by selling support for your FOSS-licensed software the big cloud providers are going to eat your lunch regardless of what FOSS software license you use.
They will be using your software at sufficient scale that it is more efficient for them to handle support for it for their own use anyway, and by extending that support to their paying support customers that support they were already going to have to do for their own use becomes an advantage for their customers.
The original company's advantage over everyone else providing support and maintenance is that the original company knows the direction of future development. That's a great advantage if the software is the kind for which people really want to rapidly upgrade to the latest version.
The kind of cloud infrastructure services that are usually involved in the "cloud company X killed my business by selling support for my project" stories are the kind of services that people don't rush to upgrade.
AGPL only changes things if you give access to your software over the internet. If you're just using the software internally (e.g. it's used in the corporate SSO solution for access to an internal wiki) than no OSS license will force you to publish the code.
Furthermore, if I contract a company to build a service which I will run internally, and they use (A)GPL software in this service that they are building for my internal use, neither I nor the company probably have any requirement to publish the source code to anyone, perhaps except that the contractor may have to provide me with the source code if this was not otherwise stipulated. But you don't have any right to see the code that they modified for me, even if you are the initial author of that code.
> perhaps except that the contractor may have to provide me with the source code if this was not otherwise stipulated.
They wouldn't have the right to otherwise stipulate. The contractor can't change the license to the software without losing the license to the software. Even if they were distributing a modified version to a single customer, that customer would have the right to the source. That customer, using it internally, wouldn't have the obligation to distribute any of the source or changes but they would have the right to.
Otherwise, you could just sell software as a "contractor" in name only to any number of customers, and effectively relicense it with "stipulations."
Yes, I agree with everything you say. What I meant with that phrase was the opposite - I was thinking that for software subcontracting it is somewhat common to explicitly stipulate that the source code of what is being built belongs to the client. I meant that the (A)GPL would give you the right to the source even if the there were no other stipulations to give you that right to other source code.
I don't believe this has everything been tested in court, but I fail to imagine how a USB cable or SATA constitutes a network. Wifi, sure. If you have an IPX or TokenRing or an ISO/OSI network, then sure.
Either way, the more relevant part here is the use inside an internal organization.
It's about intent. If the customer is communicating with you then it's "supposed" to count. This is important, because it covers devices that you talk to to use.
Per the literal text of the AGPL, it's about providing a service over a network via a protocol. So if it's a SATA device the network is peer to peer and the protocol is SATA. I have no reason to believe a real test of the AGPL would be so restrictive.
The service you are offering is SATA compliance for storage, or USB (sub)protocol compliance for one of myriad reasons. E.g. I have projects where the main interface is USB or CAN bus. I expect the AGPL to apply. I mention this explicitly when discussing the license as well just to be airtight, but it's my belief it is already.
Did Orange then "distribute" the library to users as part of deploying this authentication service, or was this purely internal, SaaS use? If the latter, it makes sense that the counterfeiting claims were dismissed, since these only arise when the software is "distributed".
> Every few weeks we see a post on HN about an MIT-licensed project that gets picked up by AWS or Azure and the general response is "should've been GPL".
Just to clarify even further, it's not only AGPL instead of the GPL (some times it's also GPL instead of MIT), but the cloud providers would be perfectly conformant with the AGPL too.
Usually the HN people that are complaining are talking about market concentration.
> Every few weeks we see a post on HN about an MIT-licensed project that gets picked up by AWS or Azure and the general response is "should've been GPL".
If you are distributing GPL software, the GPL says that you are obliged to provide the source code of the software on request. Amazon or Microsoft use this as a loophole to claim they have no obligation to release the source code of any GPL software they use on AWS or Azure. They claim they are not distributing the GPL software but only executing the softwares on their servers and providing it to the users as a service offering.
This is why the Free Software Foundation created the Affero General Public License (AGPL).
The AGPL includes all the provisions of the GPL but also has extra clauses that makes it obligatory to provide the source code even if the software isn't distributed but made available as a "service" through some server.
"The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there."
(Why the Affero GPL - https://www.gnu.org/licenses/why-affero-gpl.html ). This is why everyone now recommends that you should use the AGPL (instead of the GPL / MIT / BSD license etc) for open source projects.
> This case right here highlights that in France that doesn't work either ... it's a contract issue and not a copyright one so the case gets thrown out.
The French court did conclude that there is no case to be made under copyright law, and that it considered the GPL as a contract. And so any dispute between parties on the GPL can only be judged under France's "contract laws". This doesn't mean that the GPL is no longer valid in France. France is just asserting that the GPL is a contract. You can still take anyone who violates the GPL to court. You just have to file the case under the right law. When you claim in court that someone in breaking the law, you have to point out the right laws that you claim are being violated, or your case will be thrown out.
(It's like adultery laws - adultery was once a criminal offence. It is now treated as a civil offence in many countries. Meaning, you can no longer file a complain with the police if your spouse cheats on you, and have them investigated, arrested and tried in court as a criminal. But you can still sue your spouse in court and get damages.)
Their equivalent of AT&T used GPL software (admitted to it) but claims that it's a contract issue and not a copyright one so the case gets thrown out.