News for hackers. Stuff that matters.
Re:As an Employee, You Are Disposable (2023) by pjc50 on Friday July 12, 2024 @05:05AM (#40943903)
> As developers, IMHO you should always push for open sourcing as much as you can, ideally with a copyleft license and no CLA. Because it is beneficial for you personally: it means that you can reuse your code after you leave, and if you manage to make it copyleft and accept external contributions, it will force your employer to keep distributing the sources after you leave.

How many people have had this work? Am I unusual in working at places that take an extremely restrictive attitude to their IP?

Re:As an Employee, You Are Disposable (2023) by kortilla on Friday July 12, 2024 @06:29AM (#40944260)
No, you're not in an unusual situation and there are very few companies doing anything interesting that would agree to this.

The fact that the parent comment is so upvoted is a reflection of what people dream of, not reality.

Re:As an Employee, You Are Disposable (2023) by II2II on Friday July 12, 2024 @07:35AM (#40944601)
> The fact that the parent comment is so upvoted is a reflection of what people dream of, not reality.

I can see that being the case among software developers. On the other hand, the organization I work for is so far removed from that world that my employer doesn't make any claims on most IP. If I decide to write a program to automate a task, the source is mine to do with as I please. They don't even lay claims on much non-software IP, stuff that ordinary businesses would lay claim to, since the attitude is more akin to the IP being "carpenter's tools" than the product of the job itself. (Granted, working in the education system helps on this front. The definition of restricted IP is rather narrow when the expected outcome is to share knowledge.)

Re:As an Employee, You Are Disposable (2023) by palata on Friday July 12, 2024 @08:26AM (#40944890)
> is a reflection of what people dream of, not reality.

Only if you understand it as "open source everything", it is a dream. But that is not what I say. What I say is that as a developer, you should try to open source as much as you can. Many times that's not nothing.

It's really mostly a matter of thinking about it and seizing the opportunities.

Related is also: don't be afraid to depend on copyleft libraries! As an employee, it's beneficial: it means that you have to contribute back (actually not exactly, but managers usually don't get the details so you can get away with it :-) ).

Re:As an Employee, You Are Disposable (2023) by orta on Friday July 12, 2024 @05:53AM (#40944123)
I've done it pretty successfully ( https://artsy.github.io/blog/2019/04/29/how-did-artsy-become... ) and now regularly look back at prior source code and blogs as I work on something else but with similar patterns

I would say that getting to a point where this sort of thing is possible requires a huge amount of out-of-bounds culture and technical work though. Probably outside of the commitment range of folks who just want to work as an employee and not think about work outside of your paid hours

Re:As an Employee, You Are Disposable (2023) by Aeolun on Friday July 12, 2024 @07:09AM (#40944463)
I asked this once, and I was told “It is fine to work on/contribute to open-source as long as you don’t connect yourself with the company.”

I thought that was a pretty cool thing. My job is essentially subsidizing some open source projects without ever getting the credit for it (or the potentially negative publicity, from their perspective, I guess)

Re:As an Employee, You Are Disposable (2023) by cpach on Friday July 12, 2024 @12:19PM (#40946975)
Out of curiosity, when you commit to those projects, do you do that under a pseudonym?
Re:As an Employee, You Are Disposable (2023) by phito on Friday July 12, 2024 @05:13AM (#40943941)
> How many people have had this work?

Statistically, almost nobody.

Re:As an Employee, You Are Disposable (2023) by starbugs on Friday July 12, 2024 @05:11AM (#40943933)
> Am I unusual in working at places that take an extremely restrictive attitude to their IP?

No.

Re:As an Employee, You Are Disposable (2023) by rty32 on Friday July 12, 2024 @06:21AM (#40944228)
It's not even necessarily about employers. I was pushing to open source an internal project I worked on. Turns out other coauthors are not interested in spending any time on it (reviewing code, make adjustments, go through approval etc). What can I do.
Re:As an Employee, You Are Disposable (2023) by palata on Friday July 12, 2024 @08:31AM (#40944919)
> Turns out other coauthors are not interested in spending any time on it

Because you open source it does not mean, AT ALL, that you need to spend time on it. I like Cap'n Proto as an example: it is a great open source project, but don't think of contributing to it: you will probably be ignored (unless you find and fix a very important bug, but good luck to find that there). And that's fine: the fact that it is open source is already great! Who would I be to expect the maintainers to work for free on top of open sourcing great work?

Re:As an Employee, You Are Disposable (2023) by palata on Friday July 12, 2024 @05:50AM (#40944103)
I would argue that it happens more than you may think. You depend on an LGPL library? Tell your manager that either you can make the module that links to it LGPL as well, or that you can keep it proprietary but it will take "a lot of work". Often the manager will not value that piece of code so much and will allow you to open source it.

Your employer allows you to open source something? Push for a copyleft license and no CLA.

Your manager says that "we could consider open sourcing it"? Take this as a yes.

Learn about licenses, what they mean, and think about IP at work. Many times the employer does not get anything from not open sourcing the code. It's just that they don't care. If you do, you can push them towards doing it.

I am not saying that it will be bad for the employer! It may actually be good. I am just saying that it is better for you as a developer, so you should push for it.

Re:As an Employee, You Are Disposable (2023) by swarnie on Friday July 12, 2024 @05:27AM (#40944008)
If you write something at work does anything realistically stop you retaining enough person documentation / snippets to fully or partially recreate it?

My buddy Slim seems capable of it and has built up quite a portfolio of "ready to go" solutions for common problems over the years.

Re:As an Employee, You Are Disposable (2023) by kortilla on Friday July 12, 2024 @06:31AM (#40944270)
Your buddy Slim is gonna get sued if he’s not careful.
Re:As an Employee, You Are Disposable (2023) by lifeisstillgood on Friday July 12, 2024 @05:41AM (#40944064)
That’s a legal Minefield wit the law on the side of the mines.
Re:As an Employee, You Are Disposable (2023) by pjc50 on Friday July 12, 2024 @05:37AM (#40944054)
https://www.thedrum.com/news/2022/05/19/yahoo-lawsuit-allege...

It's a matter of degree, obviously, but every time you do this it's likely to count as IP infringement. Generic libraries? Probably nobody will ever notice or care. But if they do, it could be expensive for you.

Re:As an Employee, You Are Disposable (2023) by Arch-TK on Friday July 12, 2024 @05:54AM (#40944124)
It may be expensive, but that's unlikely to be due to infringement.

Most code written by most companies has been written a thousand times already, and there is nothing illegal about recreating a library which behaves the same as something you wrote at a company.

Re:As an Employee, You Are Disposable (2023) by arp242 on Friday July 12, 2024 @11:32AM (#40946514)
At my previous job I extracted and open sourced quite a few libraries and such, although never the entire application itself.

And I don't think anyone really would have benefited from open sourcing the application either. The code wasn't all that brilliant, it was hard to run, had a lot of assumptions that would only ever be true for us, and we didn't really want to spend the time fixing/optimising that. Tons of other things to do. Practically we would also have to scrub the commit history, do an audit to make sure we really don't have anything sensitive in there, and stuff like that.

One reason I open sourced this stuff was just enlightened self-interest by the way: it enforces "clean" library-oriented programming with clean separations. When I joined there was stuff like "email parser module" which in principle would parse RFC2822 messages, but then would also call models to do a few database things, and nonsense like that. It was all pretty messy, and this hugely improved things.