I wouldn't call it theft, exactly. Presumably work did get done. If I'm reading it right, its just a terrible conflict of interest. The board uses donations to pay companies to work on LibreOffice. That seems totally fine. Some of the board were running/part of companies that rely and work on LibreOffice. That also seems mostly fine? You want your board to represent your community. Then, those same board members directed work towards their companies.
That's definitely a conflict of interest, but I wouldn't call it theft unless you prove the foundation was getting a bad deal. Could the foundation have gotten the work done better or cheaper hiring non-represented companies? That's the question you have to answer to call this theft.
It doesn't seem that is really what the foundation is arguing though, so I'm guessing it wasn't that bad. It seems more their argument is that this violates the non-profit laws they operate under.
> It doesn't seem that is really what the foundation is arguing though, so I'm guessing it wasn't that bad. It seems more their argument is that this violates the non-profit laws they operate under.
It may have been that bad. They don't really have to get into the messy arguments of "was this a fair price for this kind of contracting" because that kind of arrangement is inherently unethical, to the point that you can kind of assume it's embezzlement by default (which is why those non-profit laws are set that way).
> Some of the board were running/part of companies that rely and work on LibreOffice. That also seems mostly fine?
Those board members were elected by foundation members who also work for Collabora, so it was a privilege escalation from contributors to (controlling?) foundation board seats
It's a kind of corruption referred to as "self-dealing."
As directors of LibreOffice, they should be looking for the best deals for LibreOffice. Contractors (or any employee) are always (logically and reasonably) looking to do the least amount of work possible for the most compensation possible, so if as a director you use yourself as a contractor, your duty opposes your interests.
And if on the one hand you're being paid a flat salary (or no salary at all) for making decisions for LibreOffice; and on the other hand the worse the contracts you make with yourself are for LibreOffice, the more income you will receive, plunder is absolutely inevitable.
This is exacerbated even more with some nonprofit who is answering to an amorphous public who is funding it. They have no way of stopping you, other than withdrawing entirely.
> The project is Apache licensed, so even if they took it, outside of lacking attribution / retaining copyright, I don't see a problem? They would be require to add it to an "About" tab or something.
They used it without having a license. The apache license would have allowed them to use it, but they didn’t meet the conditions.
This sounds equivalent to using paid software without paying to me.
The original author could well claim that “the cost of a license under the terms which they used it is $2M”. After all, the cost of software licenses is entirely arbitrary and set by the author (copyright owner).
> any analysis built on month-to-month changes […] should be taken with a very large grain of salt
Agreed.
January and February are school vacations in South America. The whole month. Kids have a lot more free hours to tinker and play video games. That might not be the cause of the spike in this particular case, but there's probably dozens of similar random facts that can affect statistics on any month in unexpected ways.
I know that after a phone has been stolen, attackers want to gain access to an Apple account to remove the activation lock. But in this case, no devices had been stolen yet. The most they could do would be to… remotely mark the devices as stolen? Then ask the victim to pay to unlock them?
short term memory, but I'll admit it isn't perfect and sometimes I'm pretty sure that I might be double labelling. But that's okay because even an occasional mistaken double label is still a partially valid signal that the box is being used a lot.
A matter of taste: when I use wine on Linux I prefer to confine all window to a single "real" window. In truth: I suspect that your suggestions is more work to pull off properly.
Anyone with an older toolchain is free to fork it on github, test with the older version, and CI to the project that tests with the older version, and submit a patch, too!
This may not get the project as many users, but not everyone who writes a 50 line project is trying to figure out which versions it supports and setting up full test matrices either.
Not a Go dev, but I typically set up a CI with the oldest toolchains I support (usually a debian release), and only bump those versions when I really need something from the latest versions. Locally I build with the most recent tools. This ensures good enough coverage for very little work, as I notice when I start using something that's newer and can bump the toolchain accordingly.
Sure, but if you start a new small project and throw it on GitHub, it's not totally insane to just put the version you tested. Just because someone put up their tiny library doesn't mean they've put in the effort to figure out which version they need.
I find that (neo)vim enable code navigation to be much faster than any GUI as well, once past the learning curve. If you’re going to work with code long term (eg: years), the learning curve pays off quickly.
Intuitively, I’ve always had an impression that using an analogue circuit would be feasible for neural networks (they just matrix multiplication!). These should provide instantaneous output.
Isn’t this kind of approach feasible for something so purpose-built?
Some founders/directors kept using money from the foundation to pay their own private companies to get work done.
This is highly irregular: you can’t manage funds that aren’t yours and use those funds to buy from a company which gives you profit.
Legal council warned the of this irregularity, and nothing was made to change the status quo during years.
reply