So, sending an internal memo to your staff is somehow a public statement now?
An internal memo itself is not a public statement. If material information (such as the internal memo in question) is accidentally leaked to the public, the SEC requires the information to be broadcast as "now public" information within 24 hours. This is intended to reduce the impact of "tipster"-style insider trading. It sounds like there are additional restrictions on IPOs, but I am less familiar with those rules.
I guess during an IPO executives aren't allowed to talk about the companies financials to any of their employees?
Pretty much. The safest way to avoid breaking the rules is to minimize the spread of material insider knowledge.
I think they hoped they could pull a fast one on people in IPO. Remember while there's public disclosure it wouldn't necessarily be as intense as Google's examination and more importantly, people wouldn't have to look at anything.
Yes, this is a crucial point. With an IPO, they are required by the SEC to issue a prospectus. However, the SEC makes no claims to actually review said prospectus, so the document could say "we have no revenue and an unsustainable business model and we want to burn your money in a big bonfire" for all they care.
While your solution will likely solve the immediate problem of raccoons living living in the chimney, it may lead to an even greater problem: angry, flaming, raccoons running loose in the house, setting the furniture ablaze.
And if you closely examine your keyboard you may notice that the keys on that are also slightly elevated.
Not always. I'll admit that this keyboard is definitely harder for touch-typing from a cold start, but I've just gotten too used to the minimal movement and relative quiet of laptop keys.
Python uses white space to denote loop level. Just typing that makes me want to punch a python developer in the face.
Risking a religious argument, I have to ask: how frequently does this cause real problems for you? Developers who don't know how to use their editors properly or don't care to follow existing convention don't count—that's a PEBKAC.
If you don't believe something isn't a right you most certainly are disparaging it from the perspective of those who do.
Yes, and my government is disparaging my right to dance naked in the street with chickens under my arms by arresting me for indecent exposure and probably some animal-control law. It's all in the eye of beholder, but some beholders matter more. At present, the GPL's philosophical assertion that open derivation is an inherent right of software (and thus a right that may be disparaged by other licenses) is in the minority.
Sadly I have encountered people that are completely unable to see the argument for GPL
Agreed. Anyone who believes that GPL/BSD is an either/or argument for the future of software is fighting the wrong fight. As someone else pointed out, they represent eigenvectors in the space of software licenses (ideals?), and taking out either one would reduce the culture of F/OSS.
They don't believe that downstream users should have those rights, how does that not fit "disparaging".
The implication with BSD-licensed code is that the authors are not treating openness of forks as a right, so there is nothing to disparage. To that end, an argument such as "corporate entity X can fork the code and keep it private" is irrelevant because the license implies that this behavior is the moral responsibility of the forker and not the original developer.
It's ridiculous for someone to argue that they are sociopaths for this decision, as a BSD license is still an open-source license and still grants quite a bit of freedoms to the world above and beyond the legal default.
Many projects want an isolated test case that demonstrates the bug. This can take time for a developer to craft, given that it may involve very obscure side-effects of a proprietary environment. And by "proprietary environment" I don't mean code, I mean configurations, kernel tuning parameters, network topologies, and other things that naturally arise in a sufficiently large (distributed) system.
No, it's the 'ol "Your disregard for the rights of others is so ingrained, you believe it is an onerous restriction on your freedom when you aren't allowed to disparage the rights of others, therefore you are a sociopath."
You are hyper-focused on the notion of BSD-style licensing enabling "disparaging the rights of others." You forget that people actually write BSD-licensed code. Are they sociopaths because they don't mind seeing someone create a private fork of their code?
Just curious... why BSD rather than placing the code into the public domain?
IANAL, and I have seen some squabbles on the Internet that suggest that it is not possible to relinquish code into the public domain. There are some very large projects using BSD-style licenses which don't raise these sorts of legal concerns. Given that both fill the same role from a layman's perspective, it makes sense to take the path that has more consensus from a legal perspective.
Had it been licensed under gpl, all the child implementations of the parent would be open, and advancements or improvements could cross proliferate.
Alternatively, Microsoft and Apple would have both spent more money to avoid using GPL-"tainted" code, and we would still be left with fragmented socket implementations. Choosing a software license is essentially placing a bet on the behavior and needs of potential downstream developers. In cases like this (BSD sockets, MySQL dual-licensing, Oracle's rebranded RedHat, what-have-you) even hindsight isn't 20/20.
With respect to the sculpture in Chicago, the "don't photograph with permission of the sculptor" statement was specifically with regard to commercial photography since the sculptor retained copyright on his work.
The problem is that the restriction was applied based on equipment. If you had a nice camera, you were assumed to be a professional taking a for-profit picture. That was the problem: enforcement of the copyright should have been done at profit level (find and shut down offenders), not at the photographing level (alienate tourists).
Actually, depending on where you live, you may in fact have the right to use deadly force if you think your property is being invaded.
IIRC, in my state I can use deadly force in my "castle" if I believe I am in imminent danger or if I believe a felony action is imminent. I don't have my list of felonies memorized, but it appears that this offers quite a bit of leeway.
That's what we get for electing so many lawyers to write the laws.
If engineers wrote the laws, do you think they'd be *easier* for people to understand?
I imagine more engineers than lawyers value indentation, curly braces, and text-based version control. In my experience legal text reads just like any other algorithm, but the implementation language is terribly suited!
I don't know why you'd go to a sports bar to watch Starcraft when you could play it at home. And I don't know why you'd go to a sports bar to watch baseball when you could organize a pick up game yourself.
Sometimes you just want to watch players who are good and enjoy the game vicariously through them. Playing competitive (ladder) Starcraft—while very fun—is mentally draining for me, and I regularly get my ass kicked. Watching the best players in the world test their skill against each other is always exciting, but still lets me unwind at the end of the day.
In a good RTS game the loser loses because he could't foresee an event or he could't figure out fast enough how to stop it. In most sports there may be strategy, but often the better team loses because the other team had one lucky point.
I've seen plenty of Starcraft games where a better player lost due to luck. Maybe the scouted areas in the wrong order, or maybe they just baaaarely missed spotting a drop heading towards their new expansion. A good RTS requires economizing the player's actions and making decisions based on imperfect information, which introduces luck into the equation.
you guys don't get out of bed for much of anything.
And we call that 'wining'.
I can't tell if that's a typo for whining or winning, or if you're really talking about drinking wine in bed. I think all three sound about right, depending on your perspective.
Knowing Slashdot, this information was expressed in the form of an obligatory XKCD (#723).:)
I would have complained to you about failing to hyperlink the referenced document, but then I realized that I have the XKCD URL format memorized. Thanks!
I was just amusing myself at the symmetric uncertainty boundaries when the real uncertainty was obviously skewed in favour of the earthquake happening below the surface, rather than miles above it.
It's a complex earthquake. Just because you can't see it in three dimensions doesn't mean its location doesn't project to a real point in the sky.
Everyone was going out into the street to see what was going on. I don't know if they fuckin' expected the Red Army to be going down the street or a goddamned Gundam to be going rooftop-to-rooftop...
In fairness to them, you would feel pretty stupid if you were the only guy in Jersey to miss a Gundam hopping around the rooftops!
No, the devs who never refactor simply do what they are told. It is not your job to save your company from its management.
A dev shop full of people with this attitude will discover that this problem is self-fulfilling and ultimately self-destructive. Managers will never give time to refactor if they don't even know what it is or why it matters.
Slashdot Mirror
An internal memo itself is not a public statement. If material information (such as the internal memo in question) is accidentally leaked to the public, the SEC requires the information to be broadcast as "now public" information within 24 hours. This is intended to reduce the impact of "tipster"-style insider trading. It sounds like there are additional restrictions on IPOs, but I am less familiar with those rules.
Pretty much. The safest way to avoid breaking the rules is to minimize the spread of material insider knowledge.
Yes, this is a crucial point. With an IPO, they are required by the SEC to issue a prospectus. However, the SEC makes no claims to actually review said prospectus, so the document could say "we have no revenue and an unsustainable business model and we want to burn your money in a big bonfire" for all they care.
Sounds like your fire isn't hot enough!
Not always. I'll admit that this keyboard is definitely harder for touch-typing from a cold start, but I've just gotten too used to the minimal movement and relative quiet of laptop keys.
You may have better luck using root privileges.
Risking a religious argument, I have to ask: how frequently does this cause real problems for you? Developers who don't know how to use their editors properly or don't care to follow existing convention don't count—that's a PEBKAC.
Yes, and my government is disparaging my right to dance naked in the street with chickens under my arms by arresting me for indecent exposure and probably some animal-control law. It's all in the eye of beholder, but some beholders matter more. At present, the GPL's philosophical assertion that open derivation is an inherent right of software (and thus a right that may be disparaged by other licenses) is in the minority.
Agreed. Anyone who believes that GPL/BSD is an either/or argument for the future of software is fighting the wrong fight. As someone else pointed out, they represent eigenvectors in the space of software licenses (ideals?), and taking out either one would reduce the culture of F/OSS.
The implication with BSD-licensed code is that the authors are not treating openness of forks as a right, so there is nothing to disparage. To that end, an argument such as "corporate entity X can fork the code and keep it private" is irrelevant because the license implies that this behavior is the moral responsibility of the forker and not the original developer.
It's ridiculous for someone to argue that they are sociopaths for this decision, as a BSD license is still an open-source license and still grants quite a bit of freedoms to the world above and beyond the legal default.
Many projects want an isolated test case that demonstrates the bug. This can take time for a developer to craft, given that it may involve very obscure side-effects of a proprietary environment. And by "proprietary environment" I don't mean code, I mean configurations, kernel tuning parameters, network topologies, and other things that naturally arise in a sufficiently large (distributed) system.
Does that really work???
You are hyper-focused on the notion of BSD-style licensing enabling "disparaging the rights of others." You forget that people actually write BSD-licensed code. Are they sociopaths because they don't mind seeing someone create a private fork of their code?
IANAL, and I have seen some squabbles on the Internet that suggest that it is not possible to relinquish code into the public domain. There are some very large projects using BSD-style licenses which don't raise these sorts of legal concerns. Given that both fill the same role from a layman's perspective, it makes sense to take the path that has more consensus from a legal perspective.
Alternatively, Microsoft and Apple would have both spent more money to avoid using GPL-"tainted" code, and we would still be left with fragmented socket implementations. Choosing a software license is essentially placing a bet on the behavior and needs of potential downstream developers. In cases like this (BSD sockets, MySQL dual-licensing, Oracle's rebranded RedHat, what-have-you) even hindsight isn't 20/20.
The problem is that the restriction was applied based on equipment. If you had a nice camera, you were assumed to be a professional taking a for-profit picture. That was the problem: enforcement of the copyright should have been done at profit level (find and shut down offenders), not at the photographing level (alienate tourists).
IIRC, in my state I can use deadly force in my "castle" if I believe I am in imminent danger or if I believe a felony action is imminent. I don't have my list of felonies memorized, but it appears that this offers quite a bit of leeway.
I imagine more engineers than lawyers value indentation, curly braces, and text-based version control. In my experience legal text reads just like any other algorithm, but the implementation language is terribly suited!
Sometimes you just want to watch players who are good and enjoy the game vicariously through them. Playing competitive (ladder) Starcraft—while very fun—is mentally draining for me, and I regularly get my ass kicked. Watching the best players in the world test their skill against each other is always exciting, but still lets me unwind at the end of the day.
I've seen plenty of Starcraft games where a better player lost due to luck. Maybe the scouted areas in the wrong order, or maybe they just baaaarely missed spotting a drop heading towards their new expansion. A good RTS requires economizing the player's actions and making decisions based on imperfect information, which introduces luck into the equation.
I can't tell if that's a typo for whining or winning, or if you're really talking about drinking wine in bed. I think all three sound about right, depending on your perspective.
6000 years ago, when God created building codes and civil engineers.
Rebuilt from the ground up in the latter half of September 2001 by Paul Revere himself. We will never forget.
I would have complained to you about failing to hyperlink the referenced document, but then I realized that I have the XKCD URL format memorized. Thanks!
It's a complex earthquake. Just because you can't see it in three dimensions doesn't mean its location doesn't project to a real point in the sky.
In fairness to them, you would feel pretty stupid if you were the only guy in Jersey to miss a Gundam hopping around the rooftops!
Surely you've seen this before.
A dev shop full of people with this attitude will discover that this problem is self-fulfilling and ultimately self-destructive. Managers will never give time to refactor if they don't even know what it is or why it matters.