|
How are these required theft test security checkpoints different from mandatory drug tests, for which employers are required to compensate employees for their time?
|
#
¿
Dec 9, 2014 23:31
|
|
|
|
| # ¿ Apr 30, 2024 04:13 |
|
|
evilweasel posted:Because a mandatory drug test is a thing that happens when you are already at work. Here, the court ruled the security checkpoints are part of going to or leaving work. But they don't always happen at work, and the DoL indicates that employers are required to compensate if they happen outside of work hours. Here's the DoL page: http://www.dol.gov/elaws/esa/flsa/hoursworked/screenER13.asp I haven't read the decision or followed the case, so I'm sure that it came up in the arguments, but I'm really not seeing what how drug testing would be more related to the business than a security checkpoint - and at that point it's just "boo-hoo, my bottom line" because of quantity of testing. Just seems like I'm missing something and/or the law as written is bad. Probably both.
|
|
#
¿
Dec 9, 2014 23:53
|
|
|
esquilax posted:It's not preliminary or postliminary to the principal activities, and drug testing outside of work hours doesn't necessarily "occur either prior to the time on any particular workday at which such employee commences, or subsequent to the time on any particular workday at which he ceases, such principal activity or activities". If I read the law plainly drug tests are not really the type of thing that was supposed to be exempted. Okay, the decision makes more sense now (from a legal perspective). Basically, if drug testing results came back faster then companies could just implement them at the beginning of the day, call them "preliminary activities", and employees would just have suck it up or find work at a better employer. Sounds like an American law!
|
|
#
¿
Dec 10, 2014 01:10
|
|
|
Jarmak posted:I'm not going to even pretend this is an area of the law I know a drat thing about but Kalman's explanation is pretty straightforward and makes perfect sense and you're responding like he's speaking Greek. The reason people keep acting like Kalman and Discendo Vox are speaking Greek is that they keep posting that people are misinterpreting the decision when they say that "APIs are now copyrightable", as if the statement wasn't true. I also can't pretend to know much of anything about copyright law / fair use, but I can see how Kalman's explanation (and the discussion of the last 10 pages) misses the point from a programmer's prospective. I can't say 100% what tekz meant, when I say "APIs are now copyrightable", it means that the relevant form and functionality of the API is protected by copyright law. One cannot implement an API designed to provide the same interface as an existing API without infringing upon the copyright claimed on the existing API. In turn, this means that it is not possible to provide an independent API that works with existing code without licensing the original. So far as I can tell, that is exactly what the decision says about the copyrightability of the "Structure, Sequence, and Organization" of API packages. The decision's wording is: quote:The court further explained that Google could have offered the same functions in Android by “rearranging the various methods under different groupings among the various classes and packages.” That is, Google could have changed the class and method structures and/or names in order to not infringe upon the SSO of the API. But doing so would result in a different API, one that is not compatible with existing code (if the goal is portability) or requires learning new structures (if the goal is provide a unified interface to users of the competing APIs, as it appears was Google's goal). That's why all the "clean environment reverse engineering" talk in the past 10 pages is nonsensical to the programmers in the discussion. Sure, you can clean room an implementation of the API (as Google [mostly] did), but the you clean room the API then you lose interoperability and ease of use. With the copyrightability of APIs, my understanding is that the current undecided question whether such unlicensed reimplementation falls under fair use. Regardless of whether this decision is legally sound, the end result is for programmers is that if you use an API in your code, you are stuck with using the implementation provided by the copyright holder (barring licensed reimplementations). If the copyright holder's implementation fails for some reason (no longer provides updates, buggy code, etc.), then, so far as I can tell, it is infringement to implement the API myself to ensure continued functionality of my code. It also makes clear that actions like Google's are likely not permissible - unlicensed reimplementation of an API in order to provide interoperability and/or ease of use. What's not clear to me right now is how different an API would need to be to avoid infringement. From the decision, it sounds like the structure and names would need to be independently developed to provide the same functionality. Anyway that's why Kalman's explanations don't always make sense to me. He's arguing from the perspective that APIs are somehow separable from there "structure, sequence, and organization" and that people think that ruling means you can be sued for using APIs. Kalman posted:I think a lot of people are confusing the ruling ("the structure, sequence, and organization of a set of APIs can be copyrighted") for the shorthand ("APIs are copyrightable!"), and it's leading to bad predictions of effects, like developers being worried they'll be sued for developing using the APIs a language presents. I haven't found any blogs/posts claiming that you can be sued for APIs. Instead the EFF has been saying that you can be sued for reimplementing or extending an existing API. This seems to be exactly what the decision says, and it's an activity that is perhaps more important than Kalman or DV realize? None of Kalman or Discendo Vox's posts have helped me understand why that isn't the case or why they believe APIs are not copyrightable. It also doesn't help that they take a very confrontational approach to addressing comments/questions about the issue. E: I do see Kalman's point about the short phrases. It's possible that Google's arguments in the case where inadequate, and that the decision was correct given current IP law (though I wasn't convinced by the courts reasoning on the API SSO as a "method of operation"). That doesn't preclude it's consequences in the software development field. Stickman fucked around with this message at 06:45 on May 15, 2016 |
|
#
¿
May 15, 2016 06:35
|
|
|
Mr. Nice! posted:bolded part is wrong and it's because a lot of people don't understand how copyright works. You can still absolutely implement an API that mirrors an extant one so long as you either properly licensed it or developed it independently of the other. Google is hosed because they blatantly disregarded the legal avenues they had in front of them and deliberately chose to infringe. We're not disagreeing at all. If you license the software you can reimplement an API. You need a license because the SSO of the API (which is exactly what a software developer means when he/she says "API) is covered by copyright. You can also independently develop an API that provides the programmatic functionality of the existing API. This independently developed API will never provide the same interface (bolded from the bit you quoted) as the original, and thus will not provide interoperability. That's my whole point. Google didn't copy the SSO of the Java APIs out of lazyness (well not totally), they did it so that existing code would be easy to port to their system and so that programmers would not need to learn new APIs in order to use their alternative software system. There now is literally no (unlicensed) way to accomplish that goal without infringing Oracle's copyright. Hence, "the API is protected by copyright" seems relevant shorthand, given the developer's meaning of "the API". Edit: Well, we're disagreeing on what an "API" is and what "implementing an API" means. I believe you are arguing from the perspective of that "the API" means it's semantic functionality; that is, what it accomplishes. I.e. I could write a new API that provides classes for windows and text boxes etc. that doesn't look anything like the Windows API or Java's windows API. To a developer, the syntax of the API is also relevant when using the API. My new windows API would not be and implement of Windows API to a programmer, because it provides a different interface. Code written for the Windows API would not be compatible with my new API, so it is not an "implementation" of the Windows API from the perspective of programming functionality, despite provide the same end functionality. Stickman fucked around with this message at 07:03 on May 15, 2016 |
|
#
¿
May 15, 2016 06:54
|
|
|
Mr. Nice! posted:Yes there is. They could have wrote code that functionally was identical to the java api with the same function calls etc if they had wrote it independently. They did write a bunch of it themselves, but deliberately chose not to in some instances. When you say "functionally identical to the Java API", do you mean that code written for the Java API would work with the newly reverse engineered interface? How do you think such a reverse implementation would work? How would it look any different from the code that Google produced? The decision says that the APIs contain "37 packages, with over six hundred classes, with over six thousand methods". If Google changed the name or structure of any of those packages, classes, or methods, they would break the interoperability of existing code (and thus be developing a new API, not reimplementing the Java API). The structure and syntax of those packages, classes, and methods is defined in the header files. If, by some miracle of God, Google managed to reproduce this interface, those header files would look exactly the same as if they had been copied. Barring comments and English commentary, of course. Does anyone know if those were actually copied? Comments are irrelevant, regardless, because the decision specifically says that Google would have needed different structure and names to avoid infringement.
|
|
#
¿
May 15, 2016 07:13
|
|
|
Kalman posted:The point ulmont seems to be missing is that the declaring code copyright is bound up in the structural copyright - I.e., reimplementing a couple of lines for a couple of calls isn't copyrighted (because short phrases would apply) but when you reimplemented a significant chunk of the full API, you lose that protection. This make sense to me from a legal. It still leaves it unclear as to how much of an API you can reimplement and use the "short phrases" defense, and highlights why using copyright to protect functional code is such a "square peg" situation. The real-world reasons for and consequences of "copying" all or part of an API declaration are very different from the reasons for and real-world consequences of copying bits or all of Bleak House (though I guess now that's totally up for grabs?).
|
|
#
¿
May 15, 2016 07:22
|
|
|
Mr. Nice! posted:yes they could have reverse engineered something that was functionally identical and been in the clear. That's been the rule basically since sega v accolade. This is the clean room process that evil weasel is talking about. This, of course, takes a lot more man hours and work, but there's nothing stopping them from doing it. The other alternative is to license the original code from the source. Kalman posted:You document the method by which you produced it to show it truly was independently composed. Okay, I see where you are coming from now on clean rooms and headers - I haven't read the bits about Google clean room approach, so I'm willing to take your word that it wasn't ideal. But, and here's the big but, the "functional specification" that the dirty room team would have sent to the clean room team is basically exactly the API specification (the SSO). The case decision says that the SSO of the API is copyrightable, and thus not possible to send to a clean room. That is, even if the headers were rewritten in English - i.e. "there is a class Foo with method Bar taking an int Baz and character string Bleh. This function returns a character that is the Bazth character of Bleh" - the functional specification (taken together with all other such specificiations) still replicates the SSO of the API. I've not done on dirty/clean room development, but from brief, this sort of functional specification has been standard practice for API reimplementation. The wording of the Google decision seems to make it necessary to abstract this a step further, which you suggest could be done using pure clean room testing to tease out the syntax of the API. Does this match your assessment of the ruling? Did the ruling actually mention Google's clean room practices? I can't see it anywhere. Since the semantics of the API are not subject to such strict regulation (they can be obtained from documentation/decompilation/public source codes and translated to functional form), it seems put such strict regulation on the syntax and structure simply because they already are "the functional form". Regardless, this is very different from Sega v. Accolade. As for why others benefiting from your work, remember that reverse-engineering is allowed for a reason. Interoperability has already been estabilished as a valid goal of reverse engineering, and that reverse engineering can use publicly available specifications. Even the literal book on Application Software Reengineering says that clean room reverse engineered software can be developed using publicly available specifications. This ruling seems to go beyond saying that Google's literal copying of headers was off limits by saying that the SSO of the API is off limits and suggesting that Google should have changed the SSO (rather than your suggestion of hard-core clean rooming of the SSO). So developers seeing this as problematic hardening of the rules (with potential chilling effects on interoperability and code reuse) makes sense to me. Here's another question (that I'd love for someone more knowledgeable than me to answer). If, when developing and interoperable device, the dirty-room coders reverse engineer a closed API or protocol, can they write specifications based on that protocol for the clean room development team? That seems like that protocol would now be subject to copyright and thus off limits. Edit: Regardless, is your problem with the EFF's interpretation ("APIs are copyrightable!", "We can't reimplement APIs anymore") simply that you believe that API SSO and specification details themselves have previously been subject to copyright protection, and thus have never been fair game for a proper clean-room reimplementation (which you seem to believe can be achieved with some extra hoop jumping, but I'm still skeptical)? Stickman fucked around with this message at 11:03 on May 15, 2016 |
|
#
¿
May 15, 2016 10:11
|
|
|
Munkeymon posted:Wait, where is that from? I skimmed the decision but didn't notice the court substituting an alternate reality for ours in there. It's from the 2014 appeals decision, in the section about the Structure, Sequence, and Organization of APIs. Here's the uscourts.gov link (it's the same document that was linked from its EFF mirror earlier): http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/13-1021.Opinion.5-7-2014.1.PDF The quote is from the end of the section, pages 44-45. Stickman fucked around with this message at 20:42 on May 15, 2016 |
|
#
¿
May 15, 2016 19:34
|
|
|
Munkeymon posted:So they're selectively quoting to make a totally different, willfully ignorant argument that the original opinion didn't. I guess it's not just for Scalia Yep, just read the district court decision, and the appeals decision left out the following sentences which reads quote:They would not, however, be interoperable. Specifically, code written for one API would not run on an API organized differently, for the name structure itself dictates the precise form of command to call up any given method. The appeals court rejected that this had any bearing, because they argue that interoperability is a commercial goal that has no bearing on whether the SSO is protected by copyright. And perhaps they are right under current law, but it does mean that API reimpelementation is now held to a much stricter (and perhaps unattainable) standard than clean-room reverse engineering in other fields, since the specification itself (not just the specific documentation of the specification) is protected by copyright. Or maybe this is applicable to all fields now? Can a corporation make a copyright claim on, say, the specification of the diameter and thickness of a water pipe so that a third party creating a water meter would be in violation of that copyright if they used publicly available documentation of the water pipe rather than measuring the pipe? Stickman fucked around with this message at 21:09 on May 15, 2016 |
|
#
¿
May 15, 2016 20:50
|
|
|
Kobayashi posted:If I understand properly, and I may not, it's OK to lock some random programmers in a room, point them at https://docs.oracle.com/javase/7/docs/api/, and tell them to create Google Java. It's not OK for them to go to http://openjdk.java.net and look at the source code or poach Sun engineers to speed things up. It might also be necessary to tell the team to make sure that they also list all the classes and methods in the Java files in reverse-alphabetical order or something. Idk though, am I close? Nope, my understanding is that this ruling specifically makes the https://docs.oracle.com/javase/7/docs/api/, off limits for clean room design, because it embodies the Structure, Sequence, and Organization of the API, which is protected under copyright law. That's why Kalman and Mr. Nice! are arguing that they should instead scrape the specification from existing Java code (though it's not clear to me how this allows you to "independently develop" the SSO of the Java APIs, since they also embody the SSO of the API, and the end result will be exactly the same as the SSO in the public specification). This is how reimplementation has been done up to this point (see, for example, url=https://www.winehq.org/docs/winedev-guide/api-docs]Wine's clean room guidelines[/url]), but because the decision makes the SSO itself subject to copyright (rather the expression of the SSO), it seems to mean that publicly available expressions of the SSO should also be off limits. Also, my understanding is that clean rooms are not strictly necessary to avoid copyright violation, they're just helpful in arguing the case. If the code is sufficiently different, then no infringement occurred, even if the code is written by the same person! There was some case president for this in software reverse engineering (clean room implementation not strictly followed, but code was non-infringing), but I seem to have lost my tab - maybe someone else knows the case? Edit: I'm not saying Google should be in the clear here - they did copy the 7-line rangecheck function, as well as (portions?) of the headers. The header "copying" is where the SSO copyright comes in, as the functional portion of that code is necessarily identical, and would be identical if they had gone through a "translate to English and back again" or language scraping song and dance. And both of those are simply reexpression of the SSO, so it's not clear to me how they would avoid infringement. Stickman fucked around with this message at 21:40 on May 15, 2016 |
|
#
¿
May 15, 2016 21:35
|
|
|
Mr. Nice! posted:By virtually identical I mean they could put a closing brace on the same line right after a semi colon instead of on a new line. Those little differences would be present in independently created versions even if the line by line code ends up the same. And yes, this would be an extensive and costly project, but it isn't at all impossible and similar things have been done in the past. If they really wanted to independently build a compatible API, they could. The point of the matter is the reason behind google's copying in the first place is bogus. They weren't using it to be interoperable with Java. They stole it to entice Java developers. Those sorts of of changes may avoid infringement on the copyright of the code (though they are superficial and likely wouldn't hold up in court - I'm looking for the case reference now!), but they don't do anything to avoid infringing the SSO of the API. That's why Kalman has been putting forth the idea of constructing the API specification by scraping existing code (which I also think doesn't necessarily avoid infringing the SSO copyright, and is also a pretty ridiculous automated added step). Edit: Couldn't find the specific case, but it undoubtedly falls under "Derivative work" if you're simply changing whitespace/non-coding sections. WhiskeyJuvenile posted:It will work, though. Like there's no functional difference, just a practical one of needing refactoring What do you mean by "refactoring" though? If you mean "translating to the original API", i.e. providing a wrapper, then sorry, now you're copying the API SSO! Kobayashi posted:Hmm. I thought I understood but I guess I don't. I thought "the API" was just what was defined in the actual source code and that Mr. Nice! said the javadoc URL was a "specification" that the clean room team could work against. I don't care either way, I just think the discussion is interesting. I admit I have no idea what I'm talking about. That was the understanding the software developers had been working from - that the code itself is copyrighted, but the that the specification is a specification of a "method of operation" and thus not subject to copyright protections. Hence, projects like Wine and Linux (heck any language compiler not written by the language creator) could reimplement the computing functionality of an API starting from the API documentation without fear of infringement. This decision changes that by making the structure and organization of the API subject to copyright protection. Stickman fucked around with this message at 03:06 on May 16, 2016 |
|
#
¿
May 16, 2016 02:42
|
|
|
Mr. Nice! posted:You misunderstand. By creating an independent version even if it is 100% functionally identical, Google would have the ability to claim fair use under accolade and Sony. This would be a defense for all of the infringement. Presumably if you are changing braces in the headers, then you are working from the the API specification and/or headers? How are you claiming that you have created an "independent version"? Previously, you could create an independent version of the implementing code simply by working from the specification. The headers may end up exactly the same, but you wouldn't be infringing. Now you would need to create an "independent" version of the specification (that is, the SSO of the API). And I'm not seeing how moving braces are helping you to create and independent version of the specification (and how did you know to move the braces in the first place?) Edit: Our point is that no one has put forth a convincing approach to developing an "independent version" of the API. It's also more than just "100% functionally identical". The SSO of the API will be 100% exactly identical (up to the point that interoperability is desired), and the functional components of the headers will likely be 100% identical (since they are simple a literal 1-1 translation of the API specification into the host language). You're right that that's beside the point if it's independently developed, it's just not clear that independent development is possible. It does make showing that someone copied/didn't copy those components more difficult, and makes the whole "independent development" component more ridiculous, when the end result is 100% identical to the original specification. WhiskeyJuvenile posted:Existing Java applications are derivative works of Oracle's APIs, and therefore aren't amenable to use in clean room reverse engineering Yeah, I think that's Space Gopher's argument as to why code scraping wouldn't work for legal clean room reimplementation of an API. I'm not sure if "derivative work" would hold up here - the creators of Java certainly cannot claim copyright on code you've written in Java! On the other hand, a lot of code does seem like it would encompass derivation of parts of the SSO of the API (inheritance, etc.). WhiskeyJuvenile posted:Rewriting application code to use non-copyright API calls (i.e. System.console.printLine instead) Our point is that this ruling precludes (or makes extremely convoluted) reimplementation of APIs and programming languages, either for interoperability or for reuse of existing code. So yeah, "use a different API" may need to be the answer, but it means that using an API locks your code to the API developer, and prevents extension or reimplementation (unless the appeal find fair use?) Also, just renaming methods is likely not enough to protect you from infringing on the SSO of the API. Stickman fucked around with this message at 03:33 on May 16, 2016 |
|
#
¿
May 16, 2016 03:12
|
|
|
Northjayhawk posted:The Supreme Court just put a hold on the court decision in Virginia forcing the state to allow transgender students to use the bathroom of their choice. Keeping the status quo of loving over trans people doesn't seem terribly courteous? E: I get it, it's just hard not to be snarky about how long such obvious bullshit gets to stay in the system.
|
|
#
¿
Aug 7, 2016 07:33
|
|
|
MrNemo posted:Ok now I feel like a bit of a jackass. Nice history to that company then. Nice *fictional history! I didn't look into it further, but the footnotes day that the history is fictional and ties in with some book an blog that they also have?
|
|
#
¿
Oct 4, 2016 04:18
|
|
|
So several of the GOP's more visible voter suppression tactics are currently being litigated. Are there any grounds to litigate some of the more subtlety heinous tactics like poll site consolidation, or are "budgetary concerns" enough of a bullshit shield that a suit would go nowhere?
|
|
#
¿
Nov 22, 2016 19:11
|
|
|
Evil Fluffy posted:All those suits are pretty much guaranteed to die at the SCOTUS. The only one I have any hope for is NC's simply because the NC GOP didn't even try to hide the fact that they were tragetting minorities and others who vote Democratic. Even then I'm wary of any conservative justice seeing it as more than "they targeted Democrats specifically, not minorities specifically, so it's ok" even though it's some of the most oppressive bullshit imaginable. Yeah, I'm sadly aware that they're probably dead in the water, I'm just curious if there is legitimate existing legal grounds for fighting limitation of poll access beyond trying to prove that it disproportionately affected minorities. Even if it disproportionately affected non-minorities, it seems like it could be argued as violating a fundamental right to vote, but is there precedent equating "right to vote" with ease of voting access beyond oppressed groups? E: I mean, I guess if the suits get shot down, the answer will be "no and not for minorities either" from now on, so it will be moot 
|
|
#
¿
Nov 22, 2016 19:31
|
|
|
Evil Fluffy posted:For the people who will still be allowed to voted by 2018, sure. Trump is currently at Bush's 2006 approval/disapproval, which lost Republicans the house, senate, and a bunch of state and local races. The 2018 election map is pretty bad, so it's tough to say whether Dems will be able to capitalize on his unpopularity (if it maintains). Trump is well on his way to being more unpopular than Bush, though.
|
|
#
¿
Feb 17, 2017 19:24
|
|
|
Correct me if I'm wrong, but if the court has successfully argued that discrimination against LGB folks is covered under sex discrimination, then laws that allow discrimination against LGB individuals are, by definition, clearly promoting discrimination in the basis of sex. Plus, if the 7th circuit's reasoning holds, I don't see any way that discrimination against trans people wouldn't be covered under sex discrimination - it's so much more obviously discrimination based on sex.
|
|
#
¿
Aug 27, 2017 19:55
|
|
|
Rigel posted:The reasoning doesn't really extend to trans. LGB aren't technically a protected group, but they are effectively a protected group because they can always use the heightened scrutiny that the courts give to sex. This still doesn't make sense to me because I don't how any argument that discrimination against LGB is sex discrimination could fail to cover T. I haven't read the decision in full, so I'm just going off the reasoning given in this slate article. Slate article posted:Wood provided three interrelated reasons why Title VII’s ban on sex discrimination must encompass discrimination on the basis of sexual orientation. First, the Supreme Court held in 1989’s Price Waterhouse v. Hopkins that sex discrimination includes sex stereotyping—that is, mistreating an employee because she fails to conform to gender stereotypes. That logic, Wood explained, applies to gay employees. “Hively represents the ultimate case of failure to conform to the female stereotype,” Wood wrote. “She is not heterosexual.” Because she is a woman who dates other women, Hively defies the stereotypical expectation that women date members of the opposite sex. By allegedly discriminating against Hively for failing to conform to this gender role, Wood held, Ivy Tech engaged in unlawful sex stereotyping. Slate article posted:Second, Wood deployed what she calls the “comparative method” of Title VII interpretation. I call this the textualist reading of Title VII, because it is derived from the plain language of the statute itself. On its face, the law bars “discrimination because of sex.” If Hively were a man dating a woman—or if she were dating a man—she would not face discrimination. She only faced discrimination because she is a woman dating another woman. “This describes paradigmatic sex discrimination,” Wood writes. “Ivy Tech is disadvantaging her because she is a woman.” These facts lead to “the common-sense reality that it is actually impossible to discriminate on the basis of sexual orientation without discriminating on the basis of sex.” Slate article posted:Third, Wood relied upon the “associational theory”—also known as the Loving theory—of sex discrimination. In Loving v. Virginia, the Supreme Court found that when the government discriminates against an individual for associating with a different race, it has discriminated on the basis of race. Many courts have extended this theory to Title VII, holding that when an employer mistreats a worker for marrying a person of a different race, he has violated Title VII’s ban on race discrimination. Additionally: Slate article posted:Wood easily carries that logic over to the sex discrimination context. When Ivy Tech refused to promote Hively because of her orientation, Wood explained, it discriminated against her for intimately associating with people of the same sex. As Easterbrook made clear during oral arguments in Hively, this mistreatment qualifies as discrimination “because of sex,” in the same way that Virginia’s anti-miscegenation law constitutes discrimination because of race. “If we were to change the sex of one partner in a lesbian relationship,” Wood wrote, “the outcome would be different. This reveals that the discrimination rests on distinctions drawn according to sex.” I'm also not seeing how LGB "aren't technically a protected group, but can always use heightened scrutiny". This decision says that they can use heightened scrutiny precisely because discrimination against them is covered under a protected class of discrimination. There's no "technically not" about it. If this decision is upheld by the SC then they are a protected class. If not, then heightened scrutiny does not apply to them until congress acts, except in cases (like marriage) that warrant heightened scrutiny. Stickman fucked around with this message at 23:01 on Aug 28, 2017 |
|
#
¿
Aug 28, 2017 22:58
|
|
|
Mr. Nice! posted:Sex stereotyping might come into play and that could be an argument for standard hostile work environment situations under title VII, but that's not going to come into play at all for the military. The two relevant arguments I keep seeing come up are 1) cost of ongoing medications, and 2) cost of and time lost to transition surgery. It seems like these could be attacked by comparing costs of gender dysphoria to other non-disqualifying diseases. I don't know anything about what is disqualifying or not, so I'm not sure how they'd stack up. Also, I understand medical discharge has less stringent requirements than enlistment or induction - that could potentially be used to at least allow currently serving individuals to keep their positions. The wildcard is the "battle readiness" argument - would current courts buy that are armed forces are so transphobic that serving alongside trans individuals will hurt their performance? (Gorsuch  )Rigel posted:That is exactly what the people pushing gay marriage bans wanted to do, though. They were specifically focused on the sex of the individuals, not gender. They were loose with their language sometimes but if you pin them down, they cared about their physical sex. It really doesn't matter what people pushing gay marriage bans think they wanted to do. What matters is whether the resulting discrimination is discrimination based on differences in gender presentation, and whether the court thinks that Title VII applies to such discrimination. The 7th circuit says yes, and it remains to be seen what the rest of the court system says. Stickman fucked around with this message at 23:19 on Aug 28, 2017 |
|
#
¿
Aug 28, 2017 23:15
|
|
|
Rigel posted:And that argument probably depends entirely on if Trans are a protected group. If they are not (currently they aren't), then the courts are extremely deferential and will accept lame excuses. You pretty much have to be utterly arbitrary to fail a rational basis test, like passing a law saying people born in January can't have a driver's license. The courts don't push back much until you get to protected classes, like arguing whether women should be able to serve in frontline combat roles. (used to be a flat no, now I think we're moving towards "ok, but they have to pass the exact same tests as the men") Doesn't that bring us back to the 7th circuit's decision being easily extensible to transgender individuals? I think I've thoroughly confused myself, because I see why gender discrimination arguments wouldn't hold up as arguments against discriminatory military employment, but if protected class status is required for heightened scrutiny, which would allow other reasonable arguments to be submitted, it seems like it is exactly those gender discrimination arguments that would argue for protected class status? Stickman fucked around with this message at 23:32 on Aug 28, 2017 |
|
#
¿
Aug 28, 2017 23:28
|
|
|
That makes sense, thanks! Does that mean that legal challenges to other types of structural discrimination in the military (e.g women in combat, racial discrimination, etc.) are also only subject to rational basis rather than strict scrutiny? Or would the 7th's decision only make lgb (and maybe t) a second-class protected class, even if the decision is upheld (like Rigel was suggesting)? Ending the question with impeachment would work for me, too. Stickman fucked around with this message at 23:57 on Aug 28, 2017 |
|
#
¿
Aug 28, 2017 23:50
|
|
|
Here's another one to think about : Flyers urging LGBT students to kill themselves would have been allowed if the posters had followed proper procedures. Reminder that LBG and especially T students have much higher rates of attempted suicide and depression than the general student body. If we want to prevent this kind of discrimination in workplaces, including government workplaces, why would we support allowing it on college campuses (or support preventing administrations from addressing it)? If a trans student committed suicide after these posters (or worse) went up, would you support bullying/manslaughter charges? Stickman fucked around with this message at 20:30 on Oct 21, 2017 |
|
#
¿
Oct 21, 2017 20:23
|
|
|
VitalSigns posted:"ceremonial handwringing" Have you met the Supreme Court?
|
|
#
¿
Jan 11, 2018 07:18
|
|
|
Rigel posted:He was also correct in his observation. Then rule that all states must undergo preclearance until the formulas are updated. The VRA was a legislative remedy to violations of constitution. Eliminating the remedy across the board because it no longer made sense in some areas was a poor judicial remedy because it (very predictably) led to mass constitutional violations. It was purely racist, partisan BS and abdication of judicial responsibility. Stickman fucked around with this message at 21:42 on Jan 31, 2018 |
|
#
¿
Jan 31, 2018 21:40
|
|
|
Syzygy Stardust posted:One year ago today Neil Gorsuch was nominated to the Supreme Court.  Pennsylvania's constitution requires that state legislative districts to be drawn in a certain way. the PA Constitution posted:The Commonwealth shall be divided into 50 senatorial and 203 representative districts, which shall be composed of compact and contiguous territory as nearly equal in population as practicable. Each senatorial district shall elect one Senator, and each representative district one Representative. Unless absolutely necessary no county, city, incorporated town, borough, township or ward shall be divided in forming either a senatorial or representative district. Even the dissenting conservative judges acknowledged that this year's map likely violated the state's constitution, but wanted to "wait for guidance from the SC". So no, they're not "trying to find legal justification. They might be trying to cement guidance on what exactly constitutes a violation of PA's districting clause, though.
|
|
#
¿
Feb 1, 2018 14:51
|
|
|
Polygynous posted:You know someone's just going to "well actually" that this is about federal districts, right? I mean, they might but wouldn't it be patently ridiculous? The only connection between state districting and federal districting would be from the federal side, through the 14th Amendment (or apparently maybe the 1st) or maybe other relevant laws that I'm unaware of. But I don't see any relevant connection that could supersede Pennsylvania's constitutional districting requirements, unless you want to argue that requiring compact districts that don't break up townships is somehow itself in violation of the 14th Amendment.
|
|
#
¿
Feb 1, 2018 20:55
|
|
|
Polygynous posted:That may be the point I was badly trying to make? If the PA court declares that also applies to federal house districting and they base it solely on the PA constitution it's a state matter. Until it isn't because ~*~originalism~*~ or something. The PA SC isn't going to declare that this also applies federal districting because it doesn't apply to federal districting. The PA constitutional rules are explicitly for state house districting. It's not a federal matter unless one side or the other wants to make a claim on federal laws or federal constitutional protections (E: whoops, misread your "originalism" statement). Polygynous posted:This is what always confuses me about gerrymandering. Even in some hypothetical where everyone agrees on some definition of what a "fair" district looks like it seems like it would take like an hour to draw districts to that standard that maximally benefits the party drawing them. Presumably, a reasonably agreed-upon definition of "fair" would result in maximal benefits that are much smaller than under the current free-for-all system. Stickman fucked around with this message at 21:30 on Feb 1, 2018 |
|
#
¿
Feb 1, 2018 21:25
|
|
|
Polygynous posted:Sure, it just seems likely this would end up with a 35 or 40 seat majority rather than the 45 in the current congress. Great job, everyone. Part of the problem is that it's mathematically impossible to reconcile regional representation with proportional representation in a single system. I personally think that scrapping districts entirely and moving to proportional representation would fix a lot of the problems, though there would need to be some region-based advisory system and apportionment rules. Of course that's not something that the courts have remotely any say over, unless they want to take the radical step of declaring district-based representation to be in violation of the 14th amendment.
|
|
#
¿
Feb 1, 2018 21:58
|
|
|
evilweasel posted:The House doesn't need to be proportionally represented, because at the end of the day it usually doesn't matter. But it's important that the party that gets the most votes tends to get the most seats. It doesn't really matter if 55% of the vote gets you 75% of the seats instead, so long as it gets you 51% or more. That's fine if you want to keep a two party system, but proportional representation would be a step towards moving away from that. Also, it's still impossible to guarantee that the majority of votes translates to a majority of seats in district-based system. Stickman fucked around with this message at 00:03 on Feb 2, 2018 |
|
#
¿
Feb 2, 2018 00:00
|
|
|
So if the can't legislate hearings, is the next step to just order immediate release when the court feels long detentions have violated a detainees' rights? Seems petty unlikely the conservatives would go for that, but did Kennedy leave any room for remedy at all, even with the punt? E: Kennedy is not Roberts :/ Stickman fucked around with this message at 21:15 on Feb 27, 2018 |
|
#
¿
Feb 27, 2018 18:13
|
|
|
Rigel posted:The argument is that since we are negotiating with the state rather than a private employer, and since that can also involve needed tax increases, having to adjust priorities, etc depending on whether we beat up on "management" then that gets into politics, so the union, which the "freerider" is being forced against their will to pay dues to, is engaging in political speech using their money. This argument becomes stronger if it focuses on the union's political activities and spending on opposing people they don't like and helping the campaigns of people who they think will be kinder at the bargaining table. If it flies, wouldn't this apply to individual employees as well? They'd be completely unable to negotiate for any sort of change in compensation or benefits without being engaged in "political speech". Not that they'd be able to anyway, considering that the government is, by definition, the most powerful negotiating agency.
|
|
#
¿
Mar 2, 2018 18:52
|
|
|
Kazak_Hstan posted:What is and isn't a threat, and how severe or imminent a threat is, are inherently subjective judgments. If you ask multiple humans to make subjective judgments, even subjective judgments they are highly trained for, you will get different results. That's not just true of cops. That's true of pilots deciding what's safe to fly in or radiologists diagnosing people. It's not like 'imminent threat of serious bodily injury or death' is reducible to a math formula. Maybe it's because I'm not a legal expert, but the distinction between readying one's weapon and putting four bullets into someone seems rather important.
|
|
#
¿
Apr 3, 2018 08:53
|
|
|
Kazak_Hstan posted:Under standard law enforcement training you don’t draw your weapon in response to a known threat (as opposed to a felony warrant apprehension, builing clearing or etc.) unless you can articulate lethal force criteria. There is obviously a difference between pulling a trigger and not. But if you have your gun out in response to something you don’t consider close to a lethal force situation you are in the wrong. That might be the training and doctorine, but the fact that American police officers draw their weapons at least an order of magnitude more often than they fire them suggests that it's absolutely not how drawn weapons are used in practice.
|
|
#
¿
Apr 3, 2018 17:20
|
|
|
Kazak_Hstan posted:That just as plausibly suggests it’s common for cops to draw weapons in response to serious threats, gain compliance, and work their way back down the force continuum. It doesn’t necessarily mean they are just drawing down willy nilly. No, but it does mean that cops are drawing their weapons usually does not result in shots fired. Regardless of training and protocol rhetoric, it suggest that drawn weapons are used by American leos to gain compliance and to be ready to apply deadly force, as distinct from imminent atomic and immediate use of deadly force. In that light, it to distinguish between the act of drawing weapons and the firing of weapons; the other officer's drawn weapons do not make Kisela's firing reasonable, and the fact that they did not fire (and said that they did not believe firing was necessary) suggests that it was, in fact, unreasonable. Stickman fucked around with this message at 19:56 on Apr 3, 2018 |
|
#
¿
Apr 3, 2018 19:17
|
|
|
hobbesmaster posted:Unfortunately any example like that would be patent law. Which is yet another reason why it's insane to protect APIs under copyright.
|
|
#
¿
Apr 5, 2018 18:56
|
|
|
Mr. Nice! posted:I think an airline cockpit isn’t a good analogy at all. Every airline cockpit is not identical. The individual functional switches may be generally in the same place and have the same function, but there is still creative design work going on with the design of the cockpit, location of every device, chairs, etc that is absolutely the intellectual property of the various manufacturers. Well, you can change the font and spacing of your API documentation (you know, the non-functional components that aren't integral to the constructed mode of communication). Oh and the wording of English language descriptions, etc. What you can't change without changing function are the API headers, except in the most trivial of ways. Stickman fucked around with this message at 19:11 on Apr 5, 2018 |
|
#
¿
Apr 5, 2018 19:07
|
|
|
Mr. Nice! posted:If google had made even the cursory attempt to generate their own java compatible api I might be swayed by such arguments. They whole cloth copied in bad faith and profited hundreds of billions based in large part to said theft. If the content of API headers is entirely functional, why should copyright and fair use come up at all when it comes to the functional components? Just because some functional components were changed doesn't make those components any less functional. You could argue that some form of patent should apply (it shouldn't), but it seems pretty backwards to defend shoving it into a copyright box.
|
|
#
¿
Apr 5, 2018 19:36
|
|
|
|
| # ¿ Apr 30, 2024 04:13 |
|
|
Rigel posted:There is almost always a remedy against a city or county government. It may be a confusing remedy requiring bureaucratic paperwork and brutally short deadlines, and you may fail and end up having a judge tell you that you are the victim of "sorry, poo poo happens". However, thats a political problem with the city or state that needs to be remedied with elections. We still shouldn't hold the city worker personally responsible (except for the exception I described earlier). What makes them more special than, say, doctors who have to carry malpractice insurance for when they gently caress up? Just being a government employee?
|
|
#
¿
Apr 13, 2018 02:16
|
|