Paul Ganssle @pganssle@qoto.org

@binsrc Joel Spolsky outlined a compelling case for why these kinds of policies actually make a lot of sense: https://www.joelonsoftware.com/2016/12/09/developers-side-projects/

As much as my CC-0-moving sensibility chafes under these kinds of policies, I'd almost certainly enact similar ones if I started a company (at least one with a traditional relationship with IP).

@binsrc As to the original policy I alluded to, IANAL but my understanding is that one of the clauses (and the company owns your output usually if *any* condition is met) is that the company owns your output if you use company resources, meaning anything you need to work at the company to have access to. BYOD muddies the situation but I think it would probably not be sufficient unless you used software the company paid for, did it on company time, etc.

@binsrc I refuse to use my work devices for everything. If I worked somewhere with a BYOD policy I would just buy a dedicated work laptop.

It is a bit inconvenient but definitely in your interests you have separate devices. Even assuming you aren't worried about a "messy break-up" situation, consider that in the highly likely event of your company being in a lawsuit, suddenly your entire laptop may be subject to discovery.

@design_RG @binsrc Yeah, I have only worked there for about 6 months. We still have "20% projects" but it's not an unlimited work-on-what-you-want thing. I'm not sure if it changed or it never worked that way. Both possibilities seem plausible.

I think managers have a lot of discretion about what their staff does, so it probably varies across the organization.

@binsrc There's a good chance that if they don't want to be associated with it they'd either grant me the IP or say I can't release or publicize it.

I suspect they don't really want to exercise any rights like that on random weird fiction, though, so they'd probably either grant me the IP or some unlimited license to it. IANAL and I can't speak for Google, I just know people involved in OS at Google and they aren't really in the business of being petty (they're really very nice).

@binsrc I don't think my boss would appreciate it if I were to spend work time on Welcome Back, Kotter fan fiction, but the default contract in NY state has employers owning any IP related to what your company does, plus anything done with company resources, so if I do it on my own time but use the work computer or something, my company has a strong claim to own it.

"Oops, I used my work computer for this by 'accident', better put '© Google' on 'The Sweathogs meet Dracula'."

Most tech contracts in the US stipulate that the company owns any IP you produce under some conditions. You can use this to give your employer a weird IP portfolio. Personally, I'm looking forward to Google owning an extensive collection of "Welcome Back, Kotter" fan fiction.

PSA: Someone has apparently typo-squatted a package with a similar name to dateutil on PyPI and is serving malicious code on it!

Please check that you depend on `python-dateutil`, no other variants. (The malicious package is `python3-dateutil`).

https://github.com/dateutil/dateutil/issues/984

@design_RG Heh, I was actually referring to Usenet, though maybe this is your subtle way of discouraging meme culture. 😛

@freemo #introductions

I am interested in:

#programming
#foss #opensource #privacy #wikipedia #decentralization #maintainership #testing #python #rust #science #rationality #logic #hardware #transhumanism

From the python-dev mailing list:

> Having tried comp.lang.python with no response, I turn here...

MFW a property testing library keeps finding increasingly obscure bugs in my code.

Just finished putting the stickers I made in Austin on my laptop. That tesselation is very satisfying.

@artfulsodger I don't know what I'm going to do if this stops working on my phone or if Twitter's API changes or something. Possibly stop using Twitter?

None of the FOSS alternatives seem nearly as good, and I don't think I'd be interested in installing a proprietary one.

@bitecode Despite the fact that it makes the abstraction of "open a file" less clean, I think it was definitely the right choice.

@bitecode I admire your impulse here, but this would be a usability disaster unless "text open" were the default and "bytes open" were something else.

The reason is that you very rarely actually manipulate files as bytes - you mainly use some sort of abstraction. Almost certainly "put some text in this file" is the most common abstraction people use. "Why do I need to always call the `.text` method every time I open a file?" would be one of the top complaints about the ergonomics of Python.

Not to mention people would probably get confused and start using bytestrings.