What would not be Ok is if these companies would put further restrictions on *my* code.
I knew that from the beginning and chose to go that route. It adheres to the licenses that I chose for my code.
#SOURCETREE GITHUB ORGANIZATION FOR FREE#
From where do I know? Because these companies frequently contact me for free support.Īnd that is perfectly acceptable and fine.
#SOURCETREE GITHUB ORGANIZATION SOFTWARE#
And that is fine.Ĭompanies are using my Open Source and Free Software to make millions of Dollars. If GNU/Linux was proprietary software, then they would have to pay for every single change set going into it.īut Free Software allows them to not pay all these bills. These rights are at the base of Red Hat's business. That is the basic concept and foundation of Free Software. These people are exploiting the *same* rights that Red Hat exploits to run their business. > sources comes from either those who do not want to pay for the time, effort andīecause these people are just doing what the licenses permit. > I feel that much of the anger from our recent decision around the downstream What is not Ok is saying things like this: It adheres to the licenses that the developers chose for their code. How much of the work do they pay? 1%, 2%? 10%? Probably not more.Īnd that is perfectly acceptable and fine. Red Hat is one of the biggest single contributors to Free Software.īut it's also far from paying all of the work that goes into their product. >If all commercial companies involved in free software behaved like RedHat, we'd be in a better place. By sponsoring important initatives (e.g ). >By employing contributors to key projects. And that is perfectly acceptable and fine. > I guess that means RH is now going to pay all upstream developers for the time, effort and ressources going into it, right? So that idea above, that $WHATEVER_ENTERPRISE_LINUX corps are good ways to help fund FOSS, is not one that I could agree with at all. They employ leading developers on high-profile projects that they care about and they employ maintenance engineers to support all the other stuff, often engineers from outside any of the communities of said software.Īnd a developer on some project, who really could use some kind of security in terms of employment, that was at least friendly to some OOH or even 10% time on non-core-job free software project maintenance, may be excluded from consideration by enterprise Linux corporations for any number of reasons - from where they live (e.g., not somewhere the corp hires), to industry politics (dev has issues with some other industry corporates, and said Linux corporate has some level or relations with those other industry corporates). another employer, or their own consulting). These "enterprise Linux" corporations do not generally go and find some way to support all the developers of all the software they ship and support, where those developers do not already have some other support (e.g.
"Just buy a $WHATEVER_ENTERPRISE_LINUX licence - that's a good way to support open-source developers" He got my hopes up by scheduling an interview for a role I would have really liked, tbut wasted my time, and - as the months went by and I could see the ad still open - made me feel like he'd treated me like a fool. Perfunctory questions to query my knowledge, no discussion about the role, and he concluded the interview telling me already had someone for it and sorry - but then the job req was left open for something like 12 months after. Something I didn't really want to discuss much - certainly not in that setting. It was clear to me afterwards the manager went into the interview with 0 intention of considering me for the role, but he just did it cause he wanted to ask me about issues with that (unrelated to the role) project. The role was in the same general area of computing as the project, but not related otherwise.
I was applying for a role that had nothing to do with the free software project I'd worked on - indeed, I was happy to get away from that project. CentOS Stream moves faster than RHEL, so it might To call RHEL “closed source” is categorically untrueĪnd inaccurate. Gitlab source is where we build RHEL releases, in the open forĪll to see. There is CentOS Stream the binary deliverable, andĬentOS Stream the source repository. That confusion manifested asĪccusations about us going closed-source and about alleged GPL Longstanding tradition where we went above and beyond, and change That brings me to CentOS Stream, of which there Under any obligation to make things easier for rebuilders this is Ultimately, we do not find value in a RHEL rebuild and we are not To the many criticisms aimed at the company since it changed its policy
0 kommentar(er)
