It turns out we did attribute the right way (in our terms of use) and could prove it with logs of when we added the language and when it was removed after we removed the image, but I am sure they nail people all the time with this strategy. This didnt stop them from sending 20 emails, demand lawyers get on the phone, etc.
There are a couple of similar scams like this out there.
His stuff is so widespread that the consensus on Wikimedia Commons was to keep his photos and add a warning so that no one ends up accidentally using it. Some accused him of sock-puppetry to get his content into a place.
Today, intellectual property maximalism is a much more mainstream position so perhaps modern Internet users will think that he is in the right, but I think it's a bit much.
Here's the thread where he's discussed: https://commons.wikimedia.org/wiki/Commons:Administrators%27...
Here's an example forced-attribution photo: https://commons.wikimedia.org/wiki/File:Flaming_Lips.jpg
1. Post the photo to Wikimedia Commons
2. Mark it CC-BY or derivative (say CC-BY-SA etc.)
3. Have a highly precise attribution clause
4. Sue everyone who uses it without the specific attribution
The funny thing about this copyleft troll is that Someone Who Is Not Him creates accounts on Reddit (e.g. this one[0]) that post exclusively about how they made a mistake and the photographer was well within his rights to sue and you should take him very seriously and negotiate the amount.
> We actually violated copyright law before he wrote to us. So it was our mistake and we apologized for that.
I really should create a List page for this on my personal wiki so I can remember all these guys. I find this kind of behavior galling.
People did bring up this stuff here: https://commons.wikimedia.org/wiki/User_talk:Der_Wolf_im_Wal.....
But since I don't speak German well enough and inevitably this is going to end up in such a situation where you have to, I think it best I don't pursue deletion here. Hopefully a German speaker will see fit, referencing the other cases here.
All these are clear. The wedding officiant isn’t saying “You might have permission to kiss the bride! Just try it and we’ll find out! Ha ha!”
To interpret this as saying that you might be licensed is just as nonsensical as that in this context. It’s in a file named “LICENSE.txt” explicitly meant to describe the license terms.
Would ‘are’ be better? I’d say yes, but it’s silly to argue that this isn’t proper English for granting permission.
Even if you're a lawyer, whether it's obvious to you is irrelevant: it has to be obvious to everyone. And if it's not (and it should be abundantly clear that it's not, given the linked discussion), the license needs fixing.
Yes, there's a definite codex of legal terms that have specific legal meaning but sound like "open to interpretation" english, but, those are vanishingly small.
Largely, if you read defensively and try to read what is not said, then you get very very far.
Source: spent about half-a-decade with very expensive swiss lawyers.
It is - it might not be successful (the court may rule against you) - but if what you thought "may" meant was close to what a "reasonable person" would have thought, you may be ruled against with no or low penalty.
Also, the ambiguity is not only in the "you may be" part, but also in the "to create compiled versions" part. Open source is more than creating compiled versions of source code.
You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:
1. Under the Free Software Foundation’s GNU AGPL v3.0, subject to the exceptions outlined in this policy; or
2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com
This really seems like a dual license situation where they are saying "Let's encourage Open Source, but if you want to just use our work to make yourself rich and not even acknowledge you're using us then fuck you, pay us."
I expect this to become more common as companies routinely infringe on OSS licenses while simultaneously many companies are hesitant to use OSS because of licenses. This at least gives an out for the good actors and allow devs to make money (other than being reliant on donations, because... that's worked out...).
But maybe I'm misunderstanding? If so, I don't know what I'm missing
In the anglophone world, yes. In many other parts of the world, the gratis/libre distinction is clear in the language used.
"Mattermost is an open source platform for secure collaboration across the entire software development lifecycle.. "
MIT for binaries distributed by Mattermost.
But, if you compile it yourself: GNU AGPL v3.0 XOR Paid-for Enterprise License
Then, for some odd reason, they append the text of Apache License Version 2.0!!!
Note that they have multiple licenses. This isn't entirely uncommon. The difference licenses apply to different things.
"...You are licensed to use the source code in Admin Tools and Configuration Files (server/templates/, server/i18n/, server/public/, webapp/ and all subdirectories thereof) under the Apache License v2.0...."
I don't think this has ever been the case. If a license is not mentioned, it is always "All rights reserved" by the authors of the project, by the Berne convention (1886).
Always wonder what leads people to write like this. What does "as such" add to the sentence? At least "at this time" is temporally conditional to the future, it has purpose.
Entertaining is posh "thinking about" or "interested in" so had the merit of being one word in place of two but so is "considering"
Are we not entertained?
It's what we used to call "load-bearing vagueness"
Stealing this. That's ACE!!
I'm open to a different title than "LICENSE: _may be_ licensed to use source code; incorrect license grant", which is obscure enough to qualify as misleading if not linkbait. However, its replacement should be an accurate, neutral title that preferably uses representative language from the article itself (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...).
Re the "don't editorialize" bit in the rules: If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
Mattermost should be aware of the contra proferentem ('interpretation against the draftsman') doctrine of contractual interpretation. Ambiguity works against the party who provided the wording.
Sometimes a license is confusing to a layman but consists of standard, established legal jargon. Don't touch the code until you know what it means from a source that knows what they are talking about. Don't take internet guesses or opinions as fact.
This is why using standard well drafted licenses verbatim is so useful. Legal phrases that have established meanings clear things up for legally even if they confuse the rest of us.
I think we understand that random devs on GitHub aren’t the right ones to resolve it, but I find it hard to believe the correct response is for the company to do nothing.
It's been 7 years and not fixed, apparently.
Legally? Likely not. Ethically, definitely not.
Legally, (in the US at least,) any ambiguity in the interpretation of a contract will most often be interpreted to benefit of the party that didn't draft the contract. In this case, the interpretation of license would likely benefit the user. But then, I'm only repeating what you've already said. So the ambiguity here doesn't benefit them legally speaking. I do agree, a frontline engineer shouldn't be trying to clarify the legal meaning in a github issue (without the legal expertise a good legal team would contribute). I don't agree that leaving the understanding to be ambiguous, is a solid legal decision.
Then, ethically. If someone ask if the license is trying to trap them, and all you do is shrug. You're not the good guy, ethically speaking.
> This is why using standard well drafted licenses verbatim is so useful. Legal phrases that have established meanings clear things up for legally even if they confuse the rest of us.
This may be pedantically true, but the part that trumps the US doctrine of contra proferentem, is the original intent that both parties likely understood. The legal interpretation, while you say it may be confusing for some people, doesn't override what the parties reasonably understood the contract to state. Or in this case, license, to grant.
That is to say, if you represent your offering as open source, and enjoy the benefits of such. It's a fundamental error to assume the courts will later back you up when you change your mind, and attempt a rug pull. And that's ignoring the ethical implications, which are enough for me to wanna peace out. (I.e. if you're pissing off your users and supporters, it was the wrong decision.)
Just forget the company and software, there is no reason to bitch about it. 7 years is too long to fix.
I'm also not so sure a serious business person checked off on annoying and scaring users that aren't but might in the future become customers or otherwise paying users.
Either the original license grant is expansive, so the clarification is welcome and the fork will become the standard unless/until the modification is upstreamed, or else the grant is restrictive, so the fork language is invalid, and the grantors face the risk of laches or other equitable defenses if they don't stop the fork from offering the less ambiguous interpretation that grantees rely on.
Fork as legal test case, if you will.
I wasn't involved in any of the Dev Ops aspect when my former employer used them, but the search function actually worked which is better than I can say for Slack.
[0]https://github.com/RocketChat/Rocket.Chat/blob/develop/LICEN...
Rocket Chat does look nice! I quite liked Mattermost except for the mobile app being trash. How is the Rocket Chat mobile app?
I thought it was fine, but I can't compare to the Mattermost app since I've never tried to use that.
My reading of the license is: either (a) buy a license or (b) be bound by the AGPLv3 -- with _very_ limited exceptions.
So, my question is: are the people that are upset with the "ambiguity" people who neither (a) want to buy a license nor (b) be bound by the AGPLv3?
If so, I have no sympathy.
> (a) want to buy a license nor
> (b) be bound by the AGPLv3?
No and no. People first want to know what the correct licenses are even before deciding which licensing path (including buying a commercial license) to take. You don't just commit to buying a commercial license without first understanding your options and comparing those options. People want to know what those options are.
People are upset that a company cannot get the simple matter of open source licensing right. It's the easiest kind of licensing. But they cannot get it right. These upset people would now never want to do business with this company.
People who would have otherwise been happy to purchase a commercial license would also stay away from the company because messing up open source licensing is a red flag. Who knows what kind of mess would be present in their commercial contracts. Yes, you can hire a lawyer to sort it out but I'd much rather do business with a company where I'm confident that the company is acting in good faith even before lawyers get involved.
> If so, I have no sympathy.
Your sympathy means nothing to me when I am picking vendors for my business. When I'm picking my vendors, I'm going to rely on professional legal expertise available to me, not the sympathies of random strangers on the internet.
> No and no.
[...]
>> If so, I have no sympathy.
> Your sympathy means nothing to me
Well, regardless... via the rules of logical implication, you have it.
If you aren't comfortable with the word "may", you'll have a lot of trouble with open source languages.
Then it goes on with the Apache license text.
MIT licensed binary in a source code repo does not make any sense.
This is a huge red flag.
From the license page on their repo (https://github.com/mattermost/mattermost/blob/master/LICENSE...):
> 1. You are licensed to use compiled versions of the Mattermost platform produced by Mattermost, Inc. under an MIT LICENSE
So just the compiled versions, not the source code. Ok, at least that is clear. But - the MIT license explictly allows for modification and redistribution. So can I do that?
The next line.
> See MIT-COMPILED-LICENSE.md included in compiled versions for details
Except this file doesn't exist anywhere in the repo or outside.
> You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:
> 1. Under the Free Software Foundation’s GNU AGPL v3.0, subject to the exceptions outlined in this policy; or > 2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com
What does "may be licensed" mean? Do I have to contact them for a license? Or is an AGPL license implied?
> You are licensed to use the source code in Admin Tools and Configuration Files (server/templates/, server/i18n/, server/public/, webapp/ and all subdirectories thereof) under the Apache License v2.0.
Sure, let's throw another license in there, because there weren't enough already.
> We promise that we will not enforce the copyleft provisions in AGPL v3.0 against you if your application ... [set of conditions]
WTF does a "promise" mean here? Is this actually AGPL or not?
Then they have copy pasted the entire Apache License, even though the project isn't licensed under Apache. Why??
Oh but that's not all.
There's a separate license page at https://docs.mattermost.com/product-overview/faq-license.htm..., which says:
> Mattermost Team Edition (Open Source) - Open Source MIT License.
Uh, what? That goes against everything said in LICENSE.txt. So now we are back to fully open source?
> All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying
So, my interpretation is that I am free to license it under the AGPL; there is no "well, we might decide to do that", and I can strip all conditions they place upon me and comply only with the AGPL, and legally there is nothing they can do about it.
> > We promise that we will not enforce the copyleft provisions in AGPL v3.0 against you if your application ... [set of conditions]
It is AGPL 3.0, except they give you slightly more rights with a promise not to enforce certain provisions in certain circumstances.
The concept of MIT licensing a compiled software artifact, but not the code used to generate the artifact, is also extremely strange.
(EDIT: though, having read the whole document, it seems like there is just a trademark carve-out, which is explicitly allowed under the AGPL, so this seems reasonably straightforward, except for the strange 'we promise not to enforce copyleft if you don't modify the code' which seems entirely redundant. Oh, and the 'licensed to use source code to create compiled version' which seems like a very strange phrasing)
https://github.com/mattermost/mattermost/blob/master/LICENSE...
----
You are licensed to use compiled versions of the Mattermost platform produced by Mattermost, Inc. under an MIT LICENSE
- See MIT-COMPILED-LICENSE.md included in compiled versions for details
You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:
1. Under the Free Software Foundation’s GNU AGPL v3.0, subject to the exceptions outlined in this policy; or
2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com> ... licensed to use source code to create compiled versions ...
Why's it calling out compiling specifically? Are they trying to imply you can't modify/distribute/etc the source? Presumably that would be a "further restriction" per the AGPL and hence ignorable, but it's sloppy at best and misleading at worse, which isn't great for a license document...
A work is protected by copyright the moment it's authored, and all rights are reserved unless it's explicitly licensed otherwise.
The reality is licenses are all nonsense and none of it makes any sense. There could be secret patents nobody knows about. That precise wording written by American lawyers might not hold up in Chinese courts. There might be two compatible licenses, but one is 20x the length of the other; obviously some legal expert thought those extra words were needed - but are they? What's going on with linking and derivative works? Do you need to copy-and-paste the full legal blurb into every single file, or not? Why are some sections written in all caps, and does the reason for doing that apply globally? What if someone claimed to have the right to contribute code to an open project but actually had an employment contract meaning the code wasn't theirs to transfer? What's the copyright status of three-line stackoverflow answers?
The truth is nobody knows, and nobody cares. You and I won't get sued, probably, and if we do it's not like we'd have avoided it by reading the license. Might as well ignore it, like people ignore website terms of use and software click-through licenses and other legal mumbo-jumbo.
On the other hand, if you're the kind of gigantic enterprise that has policies on software licenses and a team of in-house lawyers and you can't use this software without greater license clarity? Well, you can get that licensing clarity with the enterprise version of the software.
But I don't think I'll ever buy an enterprise version of the software which can't get the simple matter of open source licensing right. It isn't that hard. Thousands of developers are doing it.
If the tool was totally enterprise version only, I'd probably have less qualms about it. But to advertise a tool as open source license but then violate the open source licensing method both in spirit and the letter of the law is just too unprofessional for me that I'd steer clear of them in future and discourage anyone I know from spending their money on them.
That’s pretty clear to me (a native speaker from the UK) - i can’t really see how else it could be interpreted. As another poster said, it’s the same “may” as “you may go to the washroom” or “you may enter now” - which implies consent from the speaker.
Do you really want to bet your business on that? Vizio thought the same when using GPL code, and now they are in court. Software Freedom Conservancy sues Vizio for GPL violations - https://www.zdnet.com/article/software-freedom-conservancy-s...
Open source is notorious for being implemented in $$$ COTS and commerce and then contributing $0 in money and then even less in contribs bug fixes or sharing in house tweaks,isn’t this what Wordpress has been melting down over for a year or two now?
And I’m sure many more projects are pissed off or resenting their chains but not making an ugly scene about it.
Something has to give here.
I don’t have a dog in this fight other than to say that what mattermost went with here “is a choice” , and I have “a choice” whether to accept these terms.
I’m interested in watching how it plays out though. They cast their die. Problems have solutions. We could all get into whether this solution is viable or not — doesn’t matter this is what they went with and they made it clear they’re not taking user input on it. I’m not even a user so I expect them to care even less about my thoughts.
Im supportive of anyone trying to find an equitable balance but maybe that’s a situation where they could roll their own license with these clauses and exclusions.
Its not like Microsoft or iTunes user agreements aren’t complete bullshit, yet people click okay and use all that.