Is there a CLA or similar? Maybe I missed it, but I couldn't find anything in the CONTRIBUTING.md document. Or did they literally get every past contributor to agree?
(IANAL)
91–100 of 150 posts
Is there a CLA or similar? Maybe I missed it, but I couldn't find anything in the CONTRIBUTING.md document. Or did they literally get every past contributor to agree?
(IANAL)
No PR and no discussion and no announcement. This will be a fun time bomb for anyone using Minio at a company where legal dislikes AGPL licenses.
https://github.com/minio/minio/issues/12143
Earlier quoted context omitted.
What's the grief from legal? All you have to do is post source for changes you make to minio, right? That doesn't seem like a huge burden.
Some companies have no AGPL policy. e.g : https://opensource.google/docs/using/agpl-policy/
Earlier quoted context omitted.
What's the grief from legal? All you have to do is post source for changes you make to minio, right? That doesn't seem like a huge burden.
Some companies have no AGPL policy. e.g : https://opensource.google/docs/using/agpl-policy/
Earlier quoted context omitted.
> In fact, one requirement is the very fact you can't remove the license text itself The same section with that requirement also says you may use a different license terms for that notice as long as it complies with the terms of the Apache 2.0 license. In this case since the AGPLv3 is a superset of the Apache 2.0 license it can be substituted for the Apache 2.0 license per these terms.
> since the AGPLv3 is a superset It's not, and I already covered this. AGPLv3 has nothing that is a direct superset of Apache 2.0's requirement 4b. The closest is the section "5. Conveying Modified Source Versions." However, the terms are not the same. Section 5 is a subset of 4b, not a superset. Specifically, 4b pertains to individual files, 5 pertains to the "work" as a whole. The requirement to mark each modified…
Why are most software engineers so terrible at basic comprehension? Licenses are just a set of instructions, how do we consistently fail to follow them? You can't relicense something that is Apache 2.0 as AGPL. You need explicit approval of every single contributor (whose code still exists in the project). You can also attach the AGPL, but it is not a superset of Apache 2.0, which for example contains constraints tha…
Contracts and licenses are built on:
1) Things need to be substantially the same. If I offer to build a house for you with Brand X super-plywood flooring, and it's sold out, I can build it upgraded to Brand Y corkwood flooring since Brand X plywood was sold out, and it's substantially equivalent for the purpose, and that's okay. On the other hand, if Brand X introduces a new low-cost plywood flooring that technically qualifies but obviously isn't what we meant, you've got a case.
I can't imagine any court will care about 4b being on a per-file versus per-repo basis.
2) Damages. There isn't a magic genie which throws contract-breakers or license-breakers in jail. The extent to which these matter is damages. If I break an agreement with you, you need to care enough to sue me. Beyond that, a court will award damages, and you'll need to show you were harmed somehow, or entitled to statutory damages.
I'm not sure how you'd show you were somehow damaged by a change like whether license text is per-file or per-repo.
Contracts are written by lawyers who keep all this in mind. That's why I hire lawyers to help interpret contracts; a plain language read is often misleading. My advice is read the licenses with a lawyer, or at least someone with a basic background in contracts and licenses. Goodness knows there are bad lawyers out there, but even those will give better advice than a stranger on the internet.
Disclaimer: This is specific to common law systems, and perhaps not all of them. But that's how the US works.
Why are most software engineers so terrible at basic comprehension? Licenses are just a set of instructions, how do we consistently fail to follow them? You can't relicense something that is Apache 2.0 as AGPL. You need explicit approval of every single contributor (whose code still exists in the project). You can also attach the AGPL, but it is not a superset of Apache 2.0, which for example contains constraints tha…
IANAL, but you're obviously not one either. A lot of what you said is false. You don't read legal text like a piece of code. Contracts and licenses don't work like that. It took me a long time to wrap my head around this. Contracts and licenses are built on: 1) Things need to be substantially the same. If I offer to build a house for you with Brand X super-plywood flooring, and it's sold out, I can build it upgraded…
I'm not interested in sea lioning. So I'll just ask for one specific claim that is false.
Earlier quoted context omitted.
> In fact, one requirement is the very fact you can't remove the license text itself The same section with that requirement also says you may use a different license terms for that notice as long as it complies with the terms of the Apache 2.0 license. In this case since the AGPLv3 is a superset of the Apache 2.0 license it can be substituted for the Apache 2.0 license per these terms.
> since the AGPLv3 is a superset It's not, and I already covered this. AGPLv3 has nothing that is a direct superset of Apache 2.0's requirement 4b. The closest is the section "5. Conveying Modified Source Versions." However, the terms are not the same. Section 5 is a subset of 4b, not a superset. Specifically, 4b pertains to individual files, 5 pertains to the "work" as a whole. The requirement to mark each modified…
[€] https://github.com/minio/minio/blob/master/CONTRIBUTING.md
[¥] https://wikipedia.org/wiki/Contributor_License_Agreement
Remember, AGPL does not stop you from self-hosting or running a business on the software! It only requires you to share changes if you modify the software , which is a very reasonable requirement. I'm planning on launching a managed S3-alike service later this year and Minio is going to be what I use, it remains to be seen if they'll go to SSPL/BSL or anything else when enough people do this (maybe most wouldn't beca…
> - Entice the community to contribute/produce content/market
> - Change the license of the project
You can't really do that without every contributor agreeing or using a compatible license (unless people sign CLAs, but even then you can only re-license further work).
Earlier quoted context omitted.
> I noticed that they have a large number of contributors yet seem to have no contributor agreement with ownership assignment. I did a quick analysis of the project and there were 41 contributors in the last year that contributed more than 10 lines of code churn to go files. See the following for an analysis: https://public-001.gitsense.com/insights/github/repos?q=file... If you switch to the impacts view, you can se…
How does “reimplement contributions” work in practice? For trivial changes there’s often no alternate implementation (e.g. correcting a typo) and for anything substantial anybody currently involved in the project would be tainted with exposure to the implementation.
The GNU project offers a bit of guidance for what counts as "legally significant changes" to them: https://www.gnu.org/prep/maintain/maintain.html#Legally-Sign... They use about 15 lines rather than the GP's 10 lines, but point out there could be context where even many lines of repeated change (renaming a symbol) is not legally significant. My opinion is there's no hard line, like always you need to weigh the risk of getting sued (some contributors might even be unreachable or identifiable) against the cost of reimplementing even things legal counsel says are insignificant (at the end of which you still might get sued anyway and have to prove you did clean-room/changes were insignificant/it's fair use/whatever).