I'm reading about GitHub Packages and it seems to be a way to host Maven-style repos that you can "upload" artifacts to from a GitHub Action workflow. I know we have Clojars so we just tend to host there by default but I wondered if anyone is using GitHub Actions together with Packages to host artifacts?
GitLab also supports maven-style repos, FYI
we've been looking into Packages a little bit at work. the big thing is the 50GB of storage for Github Enterprise feels like it'll fill up really quick
Does anyone have any good examples of wording from dev employment contracts that navigate IP rights? We're trying to come up with a sane way of allowing (and encouraging) side projects and open source while also maintaining IP clarity on company work, without having to rely on fixed hours or work being done in the office.
IANAL but https://en.wikipedia.org/wiki/Work_for_hire#Law_in_the_United_States seems pretty clear and equitable if you are in the US
things can get funky. I know the emacs dev (FSF maybe) copyright assignment stuff requires permission from your employer. apple is famous for not allowing any open source stuff at all. and things can get tricky with employer owned equipment. If i enhanced a feature in CIDER using my work laptop while working on a work project, do they then own that contribution, etc. best advice is spend a couple hundred to talk over with a lawyer what you want and how to write that in a contract.
I guess that is kind of my point, companies putting language in employment contracts about IP rights over and above what exists in the law are not putting it there for clarity and to just protect there IP, they are putting it there to cling to more than what the existing law gives them
ah you mean the default if nothing else is stated
like, when you sit down and draw up the contract you are doing it with your (the companies) lawyer, they are drawing it up to protect you (the company) and get you (the company) the best possible deal from your employees
so if you are only interested in clarity, have your lawyer create a synopsis of the existing law and just have people sign it saying they read it (they won't anyway, but whatever)
So, has anyone gotten their hands on an Apple Silicon Mac and tried to get a REPL going?
I’m not sure if you got a more recent response, but FWIW, I have. Seems to work fine.
My wife has one on the way so I might find time to do some experiments and comparisons! Thanks for the info.
Are you running the x86 jdk and home brew?
i got my m1 mac mini today. builds feel fast. im using the zulu openjdk 11 ARM, from azul
@orestis yes. Installed with no issues. Installed OpenJDK 11 via Homebrew
I have two installs of Homebrew, one for Apple Silicon and one for Intel, as per: https://soffes.blog/homebrew-on-apple-silicon
I would guess that’d be faster than my translated JDK, but I’m not familiar with Zulu; wanted to start with my tried and true JDK distro.
I’ve also been using clojure on the M1 Mini for the last week or so. Very nice performance and mostly straightforward dev environment migration from a work laptop.
It's so fast, you don't even need a REPL anymore
It should make the startup time a non issue 😛
It seems like even without an ARM JVM things should still run correctly under Rosetta though. But I haven’t found an experience report that mentions Java yet.
@orestis someone I know saw a 21->16s reduction in startup time for a big application, but ssd and ram speed improvements can account for that too
Although the 21s was on a much more expensive machine
Yeah the overall benchmarks are ridiculous, these machines rival Mac Pros in many cases.
There’s still some compatibility humps, like eg Docker but I was wondering what the JVM and JIT would look like under emulation. Most apps suffer just 20% hit, which given the baseline performance is negligible.
I’ve been looking to get a Mac mini to do more iOS dev and a bit of gaming, the latest one is very tempting given the perf reports. I think I still want to wait until 32gb+ in RAM
re: the contract stuff above, the difficulty isn't so much the legal wording but trying to find a fair way of drawing a line between what is work (and owned by the employer) and what is not (and therefore isn't) when employees have hobbies that overlap with work; especially when you can't easily separate based on time or location. Nor can you necessarily say 'stuff we asked you to do is work' with more senior employees who are supposed to show initiative and define their own work.
again, IANAL but "a work prepared by an employee within the scope of his or her employment" seems to have you covered
@clarkema One thing to consider is perhaps to explicitly state that the company does not and will not claim IP rights to any open source software projects to which the employee has already contributed prior to <insert date of employment>. I've specifically asked employers to add that to my employment contract in the past, before I would sign it. That at least makes it clear that they can safely continue contributing to any projects (including their own) to which they had already contributed. It doesn't cover any new projects they might want to start while employed but that's open to future negotiation anyway since both parties would need to establish that such projects are not within the scope of his or her employment (and it's best to ask on a per-case basis IMO).
That's an interesting approach. The scope of employment thing seems wide open to later argument; defining that scope is generally the crux of the problem
i'm not sure it's completely possible to perfectly draw the line. The issue is that as an employee, even if the line is drawn well, if the employer is a jerk and sues or otherwise acts in bad faith, you're in for a bad time. same thing if the employee acts in bad faith, although employees generally fewer resources for being a jerk
True. And of course an employee's "scope of employment" can change over the course of their employment. The company might start a completely new product in a new niche and the employees assigned to that might now find that some cool project they wanted to work on outside work would now overlap with what the company is paying them to do. I always ask a company about its open source policies during my first interview with engineering management -- I suspect a lot of engineers just don't think to ask about that 😐
as an employee who has cared about retaining IP in the past, I think @seancorfield’s point is really good. additionally, having an employer that seems authentic about caring about allowing employees to do their own thing helps. however, I personally try to avoid work that has overlap with side projects I care about.
Which is why I like that clause explicitly drawn out in the employment contract -- it gives the employee at least some recourse for existing/prior OSS work.
scope of employment is also about you doing work for your employers benefit, so just because an opensource project overlaps with something at your place of employment that does not automatically make any work on that project part of your scope of emplyoment
I definitely think having clauses that match what you're looking for are important, but I'm also pretty aware that if the employer wants to sue or give me a hard time, they probably have more resources to outlast me, even if I'm in the right
Aye, and our employer is extremely supportive of that.
I think @smith.adriane is right about it being impossible to draw the line perfectly, which is what leads many companies / lawyers to horrendous, overly-broad monstrosities that try to lay claim to your whole life. That's what I'm trying to avoid
what @seancorfield is saying is basically being prematurely defensive about your IP rights as an employee, which I think illustrates how brazen and common it has become for companies to just demand this stuff
I will say that it's still important to try and draw the line well!
I mean, the main reason I maintain most of the Clojure libraries I do is because we're using them at work -- and I get to work on them during work hours (as needed), so I'm essentially being paid to work on OSS that my company does not claim IP rights over. But I also trust my current employer 🙂
I like the "for the benefit" part here
not working for jerks has lots of perks
you know lein got started (inspired by stu's lancet) because technomancy was fed up with the maven multi-module build we were using at sonian
Possibly the problem is due to lumping 'IPR' together, instead of breaking into different assets and thinking about what the company is really worried about (code export and reuse vs 'ideas', etc.)
and then trying to apply a blanket protection to different classes of thing
and then basically as soon as it was released our boss came and ripped the multi-module build out of the git repo replacing it with lein
what a tangled mess of scopes of employment that would be
i was thinking about lein a bit today. maven search results have coordinates formatted for easy copying for lein. I was wondering how to get the format for tools deps in there as well
this kind of thing
Yeah, that would be messy! I suspect it's unique to jobs like software dev (I doubt too many lawyers write contracts in the evening for fun.) I've certainly written software inspired by frustrations at work, but done in a different language or using a different approach than I would have used had I been on the clock
had leiningen offered some kind of commercial add on you may have found out
a few of the operations team at sonian started sensu for monitoring stuff (I believe at work, but not entirely sure, wasn't on that team), they left to start a company around it(no idea if or how that was arranged), and as far as I know that company is still around while sonian got bought and disappeared down the gullet of some larger company
so like, it does happen, side projects going commercial
Sonian still exists, as part of Barracuda :)
that must have been an interesting discussion!
we had a guy, I forget his title at the time, maybe vp of engineering, who spent most of his time between coming on and then leaving for his cloud monitoring startup, building spreadsheets of all the random ec2 instances we had running wasting money
(and then the vp of product left to start a different company that as far as I could tell was also a cloud monitoring startup)
to be a fly on the wall for that
we still use sensu, so i guess no harm, no foul ¯\(ツ)/¯
thanks for the discussion -- it's useful to get some other perspectives 🙂
First time hearing of cryogen for static blogs... neat!
I've been very happy with it so far -- and the team of maintainers seems to be pretty active. There's a #cryogen channel if you need more info/have Qs.