Comment by jhallenworld
7 years ago
When I worked for IBM (via acquisition), I wanted to fix bugs in Cygwin (owned by Red Hat). Red Hat does not accept patches unless you get permission from your current employer. I could not get anybody in IBM to sign Red Hat's permission slip. Nobody would sign because it's all risk, no reward from IBM's point of view.
I have the same problem in academia, being in a non-CS department, I'm required to notify the University's Center for Technology & Venture Commercialization about assigning my copyright over software to another entity (like the FSF), but so far I have been unsuccessful at getting them to sign the letter the FSF wants, despite the code I would be contributing being completely outside of my work at the University and so therefore theoretically outside of their purview. I suppose the moral is that all large organisations converge towards bureaucratic processes that waste the time of high$/hour employees and attempt to hinder all not immediately commercialisable progress.
Come to Sweden then :) As a researcher you explicitly own the rights to any foreground, i.e. results, as stated by law — the so called teacher’s excemption.
Careful, this might only apply to professors, not the rest of the staff.
1 reply →
If this is indeed true it is a killer argument for moving to sweden.
Europe also more generally has much higher salaries for postdocs and grad students from what I've seen floating around listservs.
If you have a job for me, I'm happy to. :)
> I suppose the moral is that all large organisations converge towards bureaucratic processes that waste the time of high$/hour employees and attempt to hinder all not immediately commercialisable progress.
All large organizations have a decent amount of bureaucracy around copyright and IP, but the difference is good ones make it easy and straightforward for employees to go through that process.
Google, for example, has a well-documented and clear process for contributing to open source software (both in work hours and in personal time): https://opensource.google.com/docs/patching/
Wait, so your university owns copyright on all your work by default?! That's a bummer if true. Outrageous, actually.
My contract requires that anything I develop using University resources, which in practice means potentially anything in my areas of specialisation, the University has some claim on.
It's not entirely unreasonable - imagine someone in Biochemistry developing some drug using University labs etc. and then turning around and selling the formula to a private lab.
But it's the petty bureaucratisation which is infuriating. (And usually the people making the decisions aren't practically qualified.)
5 replies →
Well, that is the result we got from turning Universities from public knowledge centers into private for profit IP accumulating businesses.
It's the standard in many universities and many countries that consider the university your employer if you have a full time equivalent dedication, even if the university only considers you under some kind of stipend or scholarship.
And yes, it's outrageous.
I think this is US specific.
3 replies →
It's actually the norm in the U.S. ...
It is the same in the UK. You don't own any of the code made for university assignments.
I totally understand that large organisations don't want to sign papers about things that are none of their business. It's ridiculous that they need to sign them. This shouldn't be a requirement for Open Source contributions. But with some businesses claiming their employees' unrelated work done in their free time, I can see how this has become a necessity.
It's harmful for open source, and a terrible situation that's not to anyone's benefit. I guess US law should make more clear that employers don't own their employees' private work?
It's not only owning the outcome that is the problem, if you develop a software system that in any ways competes with your employer they may have a reason to fire and/or sue you.
The problem as someone else stated above in this discussion is that with a company the size of IBM it is hard to do anything that is guaranteed not to compete with anything they do.
Totally agreed.
I always imagined it stems from historical experiences where staff ran off with ideas that they were paid to have within the scope of their employment. So perhaps this is the only way employers have thought of protecting themselves against that. Ie., what other way do we have to offer them?
What if you would just publish your code on GitHub, would they seek to punish you?
I doubt it, but that's not the issue. The issue is that the FSF wants a signed "ok" from the University that I can assign copyright to the FSF, and the University's Center for Technology & Venture Commercialization won't issue that. I'll wait a year or two until I'm (hopefully) tenured and then press the issue again.
1 reply →
In some courses publishing coursework on GitHub can break academic integrity rules related to plagiarism. It’s hurt students as more hiring processes assume portfolios. CS departments are behind the times.
7 replies →
If it's their code by employment contract, they could.
This is also a major obstacle towards open science, and one that the open science community seems generally unaware of. Every day there seems to be another journal article extolling the virtues of data-sharing and imploring other researchers to share, but very few folks seem to treat the elephant in the room, which is that universities have no motivation to allow their researchers to release data for free and potentially relinquish valuable IP.
I'm a current IBMer, and there is a process for getting CLAs signed - it's a bit bureaucratic if it's not a CLA for a company we already work with, but otherwise IBM has no problems with contributing to projects like that.
I left IBM a few months ago, but I led a bunch of developer advocacy efforts for a couple years.
There are several internal programs at IBM that enable employees to make contributions to open source with very little bureaucracy. Go to the intranet site w3.developer.ibm.com for details.
Deeply regrettable. One of my colleagues identified and fixed an issue with Duplicity while he was working on a backups subsystem for our server estate, and after a quick check with a Director I was able to sign off the work for release back to the Duplicity project.
This actually seems like fair policy to me, think of the mess Red Hat would be in if IBM decided that they had copyright on your contributions to Cygwin.
Or is my understanding of copyright law off base?
That's exactly why Red Hat had said permission slips. The ridiculous thing was that IBM refused to sign them
The ridiculous thing is that IP law makes this necessary.
> if IBM decided that they had copyright on your contributions to Cygwin.
How could they decide this if you'd have written the code on a weekend?
Many employers have clauses about owning any IP you produce while employed there, regardless of whether or not it involved company time or property. Whether said clauses are actually enforceable varies from location to location.
2 replies →
The FSF doesn't want to get caught up in a dispute, and thus requires explicit disclaimers of work-for-hire interest from employers https://www.gnu.org/licenses/why-assign.en.html
Couldn't you just submit patches under a pseudonym?
I think that, if you were to ask open source maintainers, "What would you think of me committing fraud to get around your project's policies?" most of them would say, "Thanks, but no thanks."
You'd be surprised. I have first & second-hand experience with the maintainers of GNU projects just agreeing to accept patches on the sly and commit them as themselves with the consent of the submitter because the submitter can't be bothered to sign a copyright release form.
I do understand your point, but I wouldn't spin it that way or bring it up with them, just start committing using a "new" identity, assuming they have no knowledge of your "main" identity.
Easier said then done.
12 replies →
Linux kernel, as an example, expressly rejects this.
Source: multiple discussion with GKH.
I wish Cygwin would get more steam, a new package manager and a repository...
Why wouldn't you use WSL?
I haven't used Windows in quite some time, but I believe they are quite different. WSL is more like a very basic version of Wine in that it implements Linux system calls and can execute ELF binaries, and as such requires you to install a host OS for libc and any other libraries you want. Cygwin is more like Winelib in that it provides a custom libc implementation and toolchain that are natively compiled, and as such requires you to rebuild your applications.
10 replies →
Windows < 10/1809 compatibility, ability to ship standalone applications, force of habit, need for something WSL doesn't support.
Ironically, Cygwin might be closer to "native" than WSL is in some cases.
2 replies →
Perhaps you're right, maybe WSL can do all the job nicely so maybe there is little if any point in developing cygwin. I have never tried it to be honest. I just prefer Windows 7 and loosely-integrated solutions - a 3rd-party Linux in a box feels better than a Microsoft Linux in the Windows kernel (yet just using a VM doesn't feel great for performance reasons and beacuse of not rally seamless file system integration).
You could try MSYS2.
Honestly I probably would have just scribbled a name in a terrible hand writing (not hard for me anyways) and called it a day. They just wanted something on file that would never be looked at again.
That's more a Red Hat legal failure than a IBM legal failure.