But the GPL is a hack. Stallman has always described it as such. It was created as an attempt to reconstruct the optimal mechanisms by which a robust body of public knowledge SHOULD build upon itself within a legal framework which interferes with this by creating too many artificial barriers to information sharing.
Technically the GPL doesn't give you any right to control me, either. The Government does that. Without Copyright law, the only way you'd be able to control your ideas at all would be by keeping them a closely guarded secret. And then who'd benefit from them? Because of Copyright law, you CAN enter into contracts which require licensees of your "intellectual property" to abide certain restrictions for the use those ideas. But the contract isn't the final limiter of your licensee's actions. Threat of governmental force is.
Copyright is purely artificial, and based on nothing more natural than the threat of force if I don't comply with the principle. Despite the language I use to describe this system, I'm not convinced it's entirely without merit. Obviously, I wouldn't claim that the people who benefit society by expanding our collective knowledge and capabilities should not be rewarded for such, but maintaining a balance between that reward and the societal benefits obtained, with consideration of the potential harms to both the benefactor and society at large by any legal framework to assure such rewards is important.
Nothing in the world can force you to share your ideas with other people. You are absolutely correct about that. The work you put into developing your thoughts into a creative software solution to a problem definitely gives you the right to decide whether or not you share that software with anyone else.
Even Richard Stallman would agree with that.
But that's not what he's arguing at all. That's not what the real issue is.
The issue is once you DO make the decision to share your software with me, what gives you the right to control what I do with it? How can you naturally justify forbidding me from tinkering with it? What intrinsic mechanism of the natural world makes the act of me further sharing the ideas you have given me with someone else? How am I robbing you by doing so? Does that deprive you the advantage of your thinking? No, you still possess your software. You still have full knowledge of it's development process, and a great understanding of the mechanisms it uses to solve the problem you were working on. But how does this labor allow you to prevent me from also benefiting from the power of the ideas you have shared with me, especially as I bend them slightly to apply to similar problems, in slightly new, and possibly improved ways? That act embodies the process of invention and development. It is the model by which we progress in science and the useful arts. What gives you the power to halt this progress at your invention, denying all who come after you the right to steward those discoveries in the service of mankind. Why would you even want to deny yourself the opportunity to learn from those who would re-work your thinking, as they have learned from you re-working the prinicples you have acquired over the course of years into the functional algorithms you have so thoughtfully put to the compile?
These are the arguments Mr. Stallman makes for Free Software, and you are free to refute them. But the hard labor is yours, as you will find that the nature of man is to share, and the nature of thought is to spread. To contain an idea is very difficult, especially the more widely it spreads. The more people you decide to share your software with, the more difficult it will be to assert the control over it you seem to want.
For some moral support, a few laughs, and generally practical wisdom, read this article from CIO magazine.
Migrating 50 users, while no walk in the park, shouldn't really be that hard. You can feasibly handle this project a few users at a time, especially if you handle it right. You'll want to start by understanding the needs and tasks of your various users. Make a note of the applications/features they use, and research alternatives in the Free Software world. You'll want to test these applications out, play around, and get comfortable with them, so you'll be able to install and configure them to be useable for your users, and help them out with simple problems as they make the transition.
As you go forward, you'll want to group people who work together or trade files a lot to upgrade them together or very close to each other, so you don't run into too much trouble with compatibility problems. You'll probably want to go with StarOffice, and keep with the Microsoft file formats for a while, at least until everyone is done.
Make sure your finance people understand that this won't be free, and will take time and expenditures, but work with them to try and manage this transition within what they would have otherwise considered a fair budget for the next upgrade cycle. Schedule a generous time-frame for yourself as well, and explain that on this particular round you'll probably consume the license savings in labor costs, but for future upgrades and maintenance, this won't be the case, and the license savings will be there.
Move carefully, but confidently. Help your users become confident with the alternatives. Encourage them to suggest that outside communications with the company be formatted in non Microsoft file types (for instance, ask the hiring manager(s) to request that resume submissions be in plain text, or RTF format, with a simple instruction on the job description of how to save in this format from most word processors (Click File, Save As, and choose the Plain Text option under file format)).
I highly suggest in a business environment you go with a distribution that supports automatic installation of a custom configuration (like Red Hat's kickstart). You can set up a system to meet the specifications you need, with all the software configured just the way you and your users want it, and then take a snapshot which can be easily installed on other systems, regardless of hardware configuration (bypassing the weaknesses of Ghost and the like), freeing you to devote your time to user orientation and training, as well as building a common sandbox environment that you'll be able to play in, and easily keep organized in the future.
If you're not too scared, and you schmooze the right way, you should be able to accomplish the migration in reasonable time and without (too much) trouble.
Also the same "HP Way" that dictates the workers on it's cash-cow production lines should labor in nearly sweat-shop conditions at subsidiary manufacturing plants (where's its shielded from ownership or employer responsibility) for barely a living wage, and works very hard to break up any attempts to unionize by targeting the squeaky wheels for layoffs.
Doing this would imply that the lights are receiving within the allotted spectrum, which capability would necessarily disqualify them for Part 18 status.
In an attempt to reconstruct my late music collection (well over 150 discs, which I still possess the jewel-boxes for, but the actual media for which were stolen in an unfortunate house-burglary which claimed my CD-binder), I've TRIED to download a few albumns in their entirety. For instance, Beck's Mutations consisted almost entirely of good tracks I loved to groove to, and almost every Future Sound of London LP reaches an entire new level of transcendence when listened to holistically, as opposed to a few individual tracks (not that I don't occasionally throw Papua New Guinea or Dead Cities into a mix of singles).
Unfortunately, it's very difficult to re-construct an albumn in this fashion. You end up with a hodge-podge of varying bit-rates, cut off songs, different versions or mixes which may or may not be better (or worse) than the one's you wanted, etc. With the FSOL case, different encoders meant that cutovers between tracks weren't as smooth as in the original albumns. Occasionally, I used to find individuals who encoded an entire albumn on Napster, but since that went away, it's gotten harder (can't search individuals' libraries in Gnutella, for instance).
I've gone back and re-aquired some of my late CDs, generally used from various swap-shops or sites like half.com. I certainly resent paying full price for albumns I already purchased merely because mine were stolen from me. Anyway, the point is, downloading whole albumns isn't rare only because people aren't as interested in doing it...it's also rare because it's a lot harder.
Of course, if you're willing to slow down a bit, it'll run 50 hours at 5 kts (250 nauticle miles), or 140 hours at 2.5 kts (350). Still not a bad range, and the surface range (3500 nauticle miles), is plenty for a transatlantic cruise. Nothing in the rules saying you gotta spend all your time underwater.
The EXACT same thing happened to me...I was trying to unselect a package I mistakenly selected or something, and then it says "You're all finished!" and gives me a login prompt.
Whoopie.
That, and auto-detection of hardware...Red Hat and Mandrake have auto-detected every piece of hardware in my system and installed correct kernel components for years. I understand that this is supposed to be better in the testing branch of Debian, and reading about this PGI thing makes me want to take another stab at it, but now I gotta find some way to make a PGI installer disk, and also boot to it, since my CD-Rom ain't bootable (grrr)
I really want to get Debian running on my pc so I can play around with it...from what I've seen and read it's rad once it's up and running...getting it up and running though has largely been a run up a steep, greasy hill for me...and I've been using Linux for years!
Maybe I'm just stupid (or more accurately, too heavily indoctrinated in my twisted Red Hat and Solaris methods)
No, because if only Copyrights applied, one engineer could document a useful piece of software as a series of requirements, and another engineer could re-implement it in a clean room with fresh code. Ideally, before reimplementation, the two (or a whole team), could discuss the design, fueled by the initial engineer's (or team's) impressions of using the software, and make tweaks resulting in a better re-implementation.
There's no real cost to innovating in music or art. It doesn't take ten years and three billion dollars to come up with a new melody. So there's little barrier to innovation in music. Anybody can do it, and many people do.
No, innovating in music isn't expensive...but innovating profitably requires an extensive marketing effort to get other people to appreciate that innovation so you can make money off of it. You have to test-market your ideas, modify and refine them, record it, promote it, adverties, and work very hard to perform it. There is a huge barrier to entry into the mainstream music market because of the expense required to gather a critical mass of admirers which really insert your innovations into the modern musical language, and others build upon them.
Pure engineering likewise isn't expensive at all. Anyone can have an interesting idea, and many people do. The expense is in building test-models to support your idea, refining and modifying it until it works optimally, coming up with a way to efficiently manufacture it, raising the capital to set up manufacturing operations, and then promoting and selling the final product. That's the real expense in engineering, and while the actual process is no more difficult (intellectually speaking) than innovating in music, it requires significantly more capital, because of the need to physically produce something.
But-- to take a counter-example-- consider engines. We've been using internal combustion engines for a long time. To come up with a better engine-- one that runs on water, or chained hamsters, or the moral power of virginity-- would be a huge effort. Ten years and three billion dollars. Why bother doing it? Because you can patent your invention, and for a period of time you can have the exclusive right to build it, or you can collect royalties from other folks who build it. Without patent protection (so the theory goes) nobody would bother building new kinds of engines.
Assuming this is true, why isn't anyone building new kinds of engines? Check the patent files...several highly fuel-efficient and/or electrical engine designs have been invented (and subsequently patented). Interestingly, a lot of these patents are held by companies who either have a lot of money already invested in the equipment used to build current engine designs, or earn a lot of their income from selling fuel (that is, companies who have a vested interest in NOT seeing new, more efficient engine designs come to market).
So how exactly are these patents encouraging innovation? It would appear that patents are frequently being used specifically to discourage innovation. Patents rarely protect innovators (at least not in the way patent proponents suggest). What patents protect is manufacturers of popular prodcuts, and individuals/institutions with large hordes of patents.
So ask yourself: is software more like music or more like engineering? It certainly has elements of both: one person, working alone, can churn out page after page of software, just like music. Ninety percent of software is crap, just like music.;-)
90% of everything is crap. Big deal. The fact of the matter is, innovating software is more like innovating in music than innovating in engineering. You have an idea, you record it, test it, modify and refine it, record it again, and then market it. There is no capital needed to create complicated manufacturing systems, as the final product (as in music) is information (I know I'm simplifying by ignoring the need for a computer to test the software on, and the possible need to print media/packaging/documentation for the software, but those same costs exist for recording equipment and media/packaging/performance equipment for music, so the level of capital needed is the same, and when compared to the immense capital needed to build a factory for producing engines, is negligible).
Furthermore, like in music, software innovation is largely derivative. Innovative music uses the same notes, chords, and often-times similar melodic sequences, in novel new combinations, frequently combined with compelling poetry which uses words, themes, ideas, and even rhythm structures, quotes, and phrases which are put together in new ways than previous music did. Sometimes the result is nice to listen to. Sometimes the result is extremely derivative, and sometimes it is quite wild and fresh.
Similarly, Designing software involves using the same commands, mathematical concepts, and often-times standard library functions and previously designed and optimized algorithms, put together to accomplish a specific purpose. Sometimes two people might design slightly different software that does the same thing, just like two different bands might create similar songs about the same topics within the same musical genre (we don't grant monopolies on angry chick-rock songs about ex-boyfriends, or poppy boy-band ballads to the first band who performs one, why do we give patents to the first company to release a software product that can compress data, do public-key encryption, or let you buy something with one click, preventing anyone else from designing a different program that might do the same thing).
But analogies and anectdotes aside, why not focus on the actual results. Are the patents encouraging progress, innovation, and the spread of knowledge? Before patents on software processes were widely granted, there would frequently be articles in technical journals detailing processes and design ideas for software to accomplish different goals. The source code itself may have been kept secret, but the algorithms were freely shared. Patents are supposed to be a tool to encourage the sharing of ideas. They are really only needed if there is a problem of ideas not being shared, in as much as they will help spread knowledge around. But what we see today is companies releasing fewer and fewer design ideas for software, in addition to keeping their code secret. As people have turned to patenting software and releasing meager details in incomprehensible legal documents, actual engineers are sharing less and less of the basic knowledge of programming, software algorithms and design with each other.
Why, when you can point out the almost obvious fact that a good portion of your monthly cable (or satellite) bill goes straight to Disney in the form of carry-fees. Successfully boycotting means sticking to antennas or pirating satellite, and never watching any Disney-owned channels.
The amount spent on audio-engineering, choreography, songwriters, laser-light shows, payola for placement in the WB prime-time lineup and on MTV's TRL, TV commercials, In-store displays, posters, "Airtime consultants" (more payola), Movie soundtrack placement, etc. are the Music production-inflation equivalent of "gold rims" on every car.
It's probably late to be commenting on this, but Brittney WAS "already famous" (to Disney Channel subscribers in the days before Disney threatened to withdraw ABC licenses to cable companies who didn't offer the Disney Channel for free, anyway), and there ARE fans who remember her days as a Mouseketeer, and bought her first offerings based on that existing fanship.
Disney may offer benefits to gay folks, but they have more than their share of employee abuses. For instance, this fall, thousands of Disney employees in the Orlando area had their workweek cut significantly short, and had their pay reduced to match. Middle management and the labor force have routinely been screwed over the years since Eisner took over, while the share price has gone through the roof, and Eisner has pulled hundreds of millions a year in bonuses and option compensation.
Disney is one of the most piggish and corrupt corporations around these days, and like you said, they are EXTREMELY hard to boycott. To do so effectively, one would have to avoid all of its business outlets (including possibly all advertisers on its media outlets)
For instance, In addition to the Disney-labeled media outlets, Disney owns over 19 TV networks including ESPN, A&E, the History Channel, Lifetime, E! and Fox Family; 6 magazines like US Weekly and Discover; 6 movie studios including Touchstone Pictures, Hollywood Pictures, Miramax, Dimension and Buena Vista International; 50 Radio stations; 9 resorts; 5 book publishers, including Hyperion, Talk Miramax, and ABC Daytime Press; 2 sports teams (Anaheim Mighty Ducks and Anaheim Angels); and lots of other businesses, including 4 large theatrical productions, a Broadway theatre, 741 Disney Stores and the Disney catalogue, tons of licensing deals of characters for clothes, toys, teaching aides and videos/films for schools...as well as stakes in NFL.com and Movies.com and the 4900-acre town of Celebration, Florida.
Oh, that's just it's media holdings. Who knows what else they've got investments in.
Even if you successfully avoid exposure to Disney-sponsored entertainment (a herculean task), it's nearly impossible to get widespread success with this, and you'll still be buying products from companies that advertise through Disney.
Basically, it goes like this:
Disney: I OWN J00
You: WHAT YOU SAY!
Disney: T4KE 1T!
Re:I think something is being overlooked.
on
Abusing the GPL?
·
· Score: 1
They will then GPL the obfuscated gobbledygook, which isn't much more useful to anyone than reverse-engineered bytecode would be...
Woops...looks like I missed this part...So you are going to release the obfuscated source...
So I have to ask...what is to be gained by this? Since you're releasing machine-readable code that compiles into the finished product under the GPL, anyone can compile and or redistribute that code (or the compiled bytecode) for free anyway, so this project probably won't make a ton of money, especially if people go out of their way to redistribute your product as freeware (which they can do, since you're GPL'ing it). Someone will come around and clean up the code, and find ways to take advantage of your changes, eventually...
Meanwhile, you stand to lose a lot of good-will and potentially development support, code/patch submissions, and intangible stuff like that simply because you're doing something perceived as mean. I don't see how you can make a business case to do this...where's the upside?
I think something is being overlooked.
on
Abusing the GPL?
·
· Score: 1
If I'm reading the post correctly, the company in question doesn't intend to distribute source AT ALL. The plan as I see it is:
1. Take source tree from GPL project. 2. Make changes to source tree. 3. Obfuscate code and remove comments 4. Compile Obfuscated code and sell it as a product. 5. "We're not selling code from this GPL project, we're selling the compiled version of THIS" 6. Profit!
(I know I forgot the step about collecting underpants)
If the company's intent IS to distribute the Obfuscated source, they will have to put a notice in each altered file stating that it was changed, and the date of the changes, and release the changed code under the GPL. If the finished altered project is useful, somebody will come along and clean up the code, and very likely re-integrate it into the original project. A big pain in the ass, possibly giving the company in question a window of opportunity to sell their product (unless savvy ppl just recompile the obfuscated source and distribute binaries as freeware), but no big deal, although I think this may cause the company to lose a good deal of money (not to mention reputation), so I don't believe that's what the agenda is.
As I understand it though, there are no plans to distribute the source. The company plans to compile only their obfuscated version of the code, and claim they are not distributing a derivative work. If this project is owned/maintained by a small individual with no legal resources, they might even get away with it, as reprehensible and illegal as it may be. Of course, that individual could always just assign their copyright to the FSF, which has the expertise and the tenaciousness to defend the code, and this company will most likely be forced to capitulate and release their modified source, or at the very least discontinue distribution of the finished product. Either way, it represents a huge potential loss of investment if this one lawyer's legal opinion is flawed.
If I were the management of this company, I'd get a new lawyer, because the guy giving this advice is going to get them in trouble. If I were a shareholder of this company and I got wind of this plan, I'd divest before I lost all my money. If I were a shareholder of this company, and the plan got implemented without notifying anyone, and I ended up losing a bunch of money because of it, I'd sue management. If I were an employee of this company, and assigned to this project or one related to it, I'd do what I was told, while updating my resume and looking for other jobs, because most likely when the legal hammer comes down, that job isn't going to be there much longer (besides, who wants to work for a company with an ethical culture like this). While doing what I was told, I'd keep documentation on all potentially illegal activities I was involved with. Upon finding another job, I'd forward copies of that documentation to the owner of the original software, the FSF and the EFF. The two larger groups could then forward some legal advice to the owner, who can decide whether and how to pursue the matter.
Meanwhile, before this project really gets rolling, and management has committed a bunch of money to it, you should sit down with your immediate supervisor, specify your legal concerns, explain that obfuscating your modified source before compiling it doesn't make your product any less of a "derivative work" in technical terms, and that, if taken to court over it, a judge would most likely rule in the owner's favor, as this clearly violates the spirit of the license, even if it attempts to wiggle through a loophole. Explain also that even though the GPL has never been tested in court, it's been violated several times, and every time, the violating party has settled and come into compliance after being confronted with it, because they really didn't have much of a chance in court. Finally, explain that even if there is a slim possibility of wiggling through a tiny loophole, the company should abandon this strategy on purely ethical grounds. It's just wrong, and there are many better alternatives, which don't risk legal backlashes and turning your business into an industry pariah. At the very least, this idea should be shopped around to several good copyright and intellectual property lawyers, preferrably with experience in software copyright cases, and if possible, cases involving the GPL. Failure to get supporting legal opinions from several sources could easily be considered negligent assumption of risk and could expose management to a nasty shareholder lawsuit if this strategy backfires, not to mention the cost of losing intellectual property investments and reputation in the industry. Depending on the size of your company and its resources, this could even mean the company goes tits-up, or the relevent company division being dissolved. At any rate, a lot of you (including bosses) could lose jobs, and that's really not a good ting.
For instance, you could contact the owner of the code, and discuss purchasing the source tree under a different license. It wouldn't be free, but it still might be a lot cheaper than designing the project from scratch. Or you can do as another poster suggested, analyze the code and rewrite it, following the same basic design. The design engineers can study the source and draw out a design flowchart based on how the program works, which could be filled in with code by the programmers. This would at least keep you out of legal trouble. Alternatively, you could consider working with the GPL'ed project, releasing your modifications under the same license, and angling your business around integration and support contracts for the code, which your company would develop significant expertise in (depending on the type and complexity of the software in question, this may or may not be a good idea).
...but in some cases the bugs are actually glaringly obvious shortcomings in the basic product design.
There was a huge outcry in the technical community when Outlook was released with the capability to execute scripted content with no interaction by default. There were comments all over the internet about the huge can of worms this could open. Sure enough, Melissa, and later ILUVYOU caused billions of dollars worth of damage. Because some product manager at Microsoft thought it would be cool for users and businesses to be able to send each other interactive email if they really wanted to, but (rightly) figured they wouldn't be savvy enough to turn this feature on for themselves in order to display it correctly.
The question then is, if the program was designed to be able to execute code attached to emails, should Microsoft have been reasonably aware that particularly anti-social code could be executed that could potentially cause a lot of havoc? If they were so aware, should they be liable for releasing such a faulty product to such an (unnaturally) large user-base?
Slashdot Mirror
Touche...well kinda.
But the GPL is a hack. Stallman has always described it as such. It was created as an attempt to reconstruct the optimal mechanisms by which a robust body of public knowledge SHOULD build upon itself within a legal framework which interferes with this by creating too many artificial barriers to information sharing.
Technically the GPL doesn't give you any right to control me, either. The Government does that. Without Copyright law, the only way you'd be able to control your ideas at all would be by keeping them a closely guarded secret. And then who'd benefit from them? Because of Copyright law, you CAN enter into contracts which require licensees of your "intellectual property" to abide certain restrictions for the use those ideas. But the contract isn't the final limiter of your licensee's actions. Threat of governmental force is.
Copyright is purely artificial, and based on nothing more natural than the threat of force if I don't comply with the principle. Despite the language I use to describe this system, I'm not convinced it's entirely without merit. Obviously, I wouldn't claim that the people who benefit society by expanding our collective knowledge and capabilities should not be rewarded for such, but maintaining a balance between that reward and the societal benefits obtained, with consideration of the potential harms to both the benefactor and society at large by any legal framework to assure such rewards is important.
Nothing in the world can force you to share your ideas with other people. You are absolutely correct about that. The work you put into developing your thoughts into a creative software solution to a problem definitely gives you the right to decide whether or not you share that software with anyone else.
Even Richard Stallman would agree with that.
But that's not what he's arguing at all. That's not what the real issue is.
The issue is once you DO make the decision to share your software with me, what gives you the right to control what I do with it? How can you naturally justify forbidding me from tinkering with it? What intrinsic mechanism of the natural world makes the act of me further sharing the ideas you have given me with someone else? How am I robbing you by doing so? Does that deprive you the advantage of your thinking? No, you still possess your software. You still have full knowledge of it's development process, and a great understanding of the mechanisms it uses to solve the problem you were working on. But how does this labor allow you to prevent me from also benefiting from the power of the ideas you have shared with me, especially as I bend them slightly to apply to similar problems, in slightly new, and possibly improved ways? That act embodies the process of invention and development. It is the model by which we progress in science and the useful arts. What gives you the power to halt this progress at your invention, denying all who come after you the right to steward those discoveries in the service of mankind. Why would you even want to deny yourself the opportunity to learn from those who would re-work your thinking, as they have learned from you re-working the prinicples you have acquired over the course of years into the functional algorithms you have so thoughtfully put to the compile?
These are the arguments Mr. Stallman makes for Free Software, and you are free to refute them. But the hard labor is yours, as you will find that the nature of man is to share, and the nature of thought is to spread. To contain an idea is very difficult, especially the more widely it spreads. The more people you decide to share your software with, the more difficult it will be to assert the control over it you seem to want.
For some moral support, a few laughs, and generally practical wisdom, read this article from CIO magazine.
Migrating 50 users, while no walk in the park, shouldn't really be that hard. You can feasibly handle this project a few users at a time, especially if you handle it right. You'll want to start by understanding the needs and tasks of your various users. Make a note of the applications/features they use, and research alternatives in the Free Software world. You'll want to test these applications out, play around, and get comfortable with them, so you'll be able to install and configure them to be useable for your users, and help them out with simple problems as they make the transition.
As you go forward, you'll want to group people who work together or trade files a lot to upgrade them together or very close to each other, so you don't run into too much trouble with compatibility problems. You'll probably want to go with StarOffice, and keep with the Microsoft file formats for a while, at least until everyone is done.
Make sure your finance people understand that this won't be free, and will take time and expenditures, but work with them to try and manage this transition within what they would have otherwise considered a fair budget for the next upgrade cycle. Schedule a generous time-frame for yourself as well, and explain that on this particular round you'll probably consume the license savings in labor costs, but for future upgrades and maintenance, this won't be the case, and the license savings will be there.
Move carefully, but confidently. Help your users become confident with the alternatives. Encourage them to suggest that outside communications with the company be formatted in non Microsoft file types (for instance, ask the hiring manager(s) to request that resume submissions be in plain text, or RTF format, with a simple instruction on the job description of how to save in this format from most word processors (Click File, Save As, and choose the Plain Text option under file format)).
I highly suggest in a business environment you go with a distribution that supports automatic installation of a custom configuration (like Red Hat's kickstart). You can set up a system to meet the specifications you need, with all the software configured just the way you and your users want it, and then take a snapshot which can be easily installed on other systems, regardless of hardware configuration (bypassing the weaknesses of Ghost and the like), freeing you to devote your time to user orientation and training, as well as building a common sandbox environment that you'll be able to play in, and easily keep organized in the future.
If you're not too scared, and you schmooze the right way, you should be able to accomplish the migration in reasonable time and without (too much) trouble.
Good luck!
I know people who leave their phone on silent and vibrate for an entirely different reason....
Also the same "HP Way" that dictates the workers on it's cash-cow production lines should labor in nearly sweat-shop conditions at subsidiary manufacturing plants (where's its shielded from ownership or employer responsibility) for barely a living wage, and works very hard to break up any attempts to unionize by targeting the squeaky wheels for layoffs.
Doing this would imply that the lights are receiving within the allotted spectrum, which capability would necessarily disqualify them for Part 18 status.
That as I read this article, I was staring at a huge advertisement for Dell.
Please paypal me some of those "peanuts".
In an attempt to reconstruct my late music collection (well over 150 discs, which I still possess the jewel-boxes for, but the actual media for which were stolen in an unfortunate house-burglary which claimed my CD-binder), I've TRIED to download a few albumns in their entirety. For instance, Beck's Mutations consisted almost entirely of good tracks I loved to groove to, and almost every Future Sound of London LP reaches an entire new level of transcendence when listened to holistically, as opposed to a few individual tracks (not that I don't occasionally throw Papua New Guinea or Dead Cities into a mix of singles).
Unfortunately, it's very difficult to re-construct an albumn in this fashion. You end up with a hodge-podge of varying bit-rates, cut off songs, different versions or mixes which may or may not be better (or worse) than the one's you wanted, etc. With the FSOL case, different encoders meant that cutovers between tracks weren't as smooth as in the original albumns. Occasionally, I used to find individuals who encoded an entire albumn on Napster, but since that went away, it's gotten harder (can't search individuals' libraries in Gnutella, for instance).
I've gone back and re-aquired some of my late CDs, generally used from various swap-shops or sites like half.com. I certainly resent paying full price for albumns I already purchased merely because mine were stolen from me. Anyway, the point is, downloading whole albumns isn't rare only because people aren't as interested in doing it...it's also rare because it's a lot harder.
...are over 8" thick. They're probably more durable than steel.
6 x 10 = 60.
Of course, if you're willing to slow down a bit, it'll run 50 hours at 5 kts (250 nauticle miles), or 140 hours at 2.5 kts (350). Still not a bad range, and the surface range (3500 nauticle miles), is plenty for a transatlantic cruise. Nothing in the rules saying you gotta spend all your time underwater.
Testify!
The EXACT same thing happened to me...I was trying to unselect a package I mistakenly selected or something, and then it says "You're all finished!" and gives me a login prompt.
Whoopie.
That, and auto-detection of hardware...Red Hat and Mandrake have auto-detected every piece of hardware in my system and installed correct kernel components for years. I understand that this is supposed to be better in the testing branch of Debian, and reading about this PGI thing makes me want to take another stab at it, but now I gotta find some way to make a PGI installer disk, and also boot to it, since my CD-Rom ain't bootable (grrr)
I really want to get Debian running on my pc so I can play around with it...from what I've seen and read it's rad once it's up and running...getting it up and running though has largely been a run up a steep, greasy hill for me...and I've been using Linux for years!
Maybe I'm just stupid (or more accurately, too heavily indoctrinated in my twisted Red Hat and Solaris methods)
No, because if only Copyrights applied, one engineer could document a useful piece of software as a series of requirements, and another engineer could re-implement it in a clean room with fresh code. Ideally, before reimplementation, the two (or a whole team), could discuss the design, fueled by the initial engineer's (or team's) impressions of using the software, and make tweaks resulting in a better re-implementation.
No, innovating in music isn't expensive...but innovating profitably requires an extensive marketing effort to get other people to appreciate that innovation so you can make money off of it. You have to test-market your ideas, modify and refine them, record it, promote it, adverties, and work very hard to perform it. There is a huge barrier to entry into the mainstream music market because of the expense required to gather a critical mass of admirers which really insert your innovations into the modern musical language, and others build upon them.
Pure engineering likewise isn't expensive at all. Anyone can have an interesting idea, and many people do. The expense is in building test-models to support your idea, refining and modifying it until it works optimally, coming up with a way to efficiently manufacture it, raising the capital to set up manufacturing operations, and then promoting and selling the final product. That's the real expense in engineering, and while the actual process is no more difficult (intellectually speaking) than innovating in music, it requires significantly more capital, because of the need to physically produce something.
But-- to take a counter-example-- consider engines. We've been using internal combustion engines for a long time. To come up with a better engine-- one that runs on water, or chained hamsters, or the moral power of virginity-- would be a huge effort. Ten years and three billion dollars. Why bother doing it? Because you can patent your invention, and for a period of time you can have the exclusive right to build it, or you can collect royalties from other folks who build it. Without patent protection (so the theory goes) nobody would bother building new kinds of engines.
Assuming this is true, why isn't anyone building new kinds of engines? Check the patent files...several highly fuel-efficient and/or electrical engine designs have been invented (and subsequently patented). Interestingly, a lot of these patents are held by companies who either have a lot of money already invested in the equipment used to build current engine designs, or earn a lot of their income from selling fuel (that is, companies who have a vested interest in NOT seeing new, more efficient engine designs come to market).
So how exactly are these patents encouraging innovation? It would appear that patents are frequently being used specifically to discourage innovation. Patents rarely protect innovators (at least not in the way patent proponents suggest). What patents protect is manufacturers of popular prodcuts, and individuals/institutions with large hordes of patents.
So ask yourself: is software more like music or more like engineering? It certainly has elements of both: one person, working alone, can churn out page after page of software, just like music. Ninety percent of software is crap, just like music. ;-)
90% of everything is crap. Big deal. The fact of the matter is, innovating software is more like innovating in music than innovating in engineering. You have an idea, you record it, test it, modify and refine it, record it again, and then market it. There is no capital needed to create complicated manufacturing systems, as the final product (as in music) is information (I know I'm simplifying by ignoring the need for a computer to test the software on, and the possible need to print media/packaging/documentation for the software, but those same costs exist for recording equipment and media/packaging/performance equipment for music, so the level of capital needed is the same, and when compared to the immense capital needed to build a factory for producing engines, is negligible).
Furthermore, like in music, software innovation is largely derivative. Innovative music uses the same notes, chords, and often-times similar melodic sequences, in novel new combinations, frequently combined with compelling poetry which uses words, themes, ideas, and even rhythm structures, quotes, and phrases which are put together in new ways than previous music did. Sometimes the result is nice to listen to. Sometimes the result is extremely derivative, and sometimes it is quite wild and fresh.
Similarly, Designing software involves using the same commands, mathematical concepts, and often-times standard library functions and previously designed and optimized algorithms, put together to accomplish a specific purpose. Sometimes two people might design slightly different software that does the same thing, just like two different bands might create similar songs about the same topics within the same musical genre (we don't grant monopolies on angry chick-rock songs about ex-boyfriends, or poppy boy-band ballads to the first band who performs one, why do we give patents to the first company to release a software product that can compress data, do public-key encryption, or let you buy something with one click, preventing anyone else from designing a different program that might do the same thing).
But analogies and anectdotes aside, why not focus on the actual results. Are the patents encouraging progress, innovation, and the spread of knowledge? Before patents on software processes were widely granted, there would frequently be articles in technical journals detailing processes and design ideas for software to accomplish different goals. The source code itself may have been kept secret, but the algorithms were freely shared. Patents are supposed to be a tool to encourage the sharing of ideas. They are really only needed if there is a problem of ideas not being shared, in as much as they will help spread knowledge around. But what we see today is companies releasing fewer and fewer design ideas for software, in addition to keeping their code secret. As people have turned to patenting software and releasing meager details in incomprehensible legal documents, actual engineers are sharing less and less of the basic knowledge of programming, software algorithms and design with each other.
So where is that getting us?
Why, when you can point out the almost obvious fact that a good portion of your monthly cable (or satellite) bill goes straight to Disney in the form of carry-fees. Successfully boycotting means sticking to antennas or pirating satellite, and never watching any Disney-owned channels.
Actually, it begins to look somewhat like mealworms crawling all over the place.
The amount spent on audio-engineering, choreography, songwriters, laser-light shows, payola for placement in the WB prime-time lineup and on MTV's TRL, TV commercials, In-store displays, posters, "Airtime consultants" (more payola), Movie soundtrack placement, etc. are the Music production-inflation equivalent of "gold rims" on every car.
Why don't we just turn the rest of the stars on their flag black? After all, what's another half a $billion?
It's probably late to be commenting on this, but Brittney WAS "already famous" (to Disney Channel subscribers in the days before Disney threatened to withdraw ABC licenses to cable companies who didn't offer the Disney Channel for free, anyway), and there ARE fans who remember her days as a Mouseketeer, and bought her first offerings based on that existing fanship.
I also forgot to explicitly mention ABC, only one of the four largest TV networks in the country...but who's counting, right?
Disney may offer benefits to gay folks, but they have more than their share of employee abuses. For instance, this fall, thousands of Disney employees in the Orlando area had their workweek cut significantly short, and had their pay reduced to match. Middle management and the labor force have routinely been screwed over the years since Eisner took over, while the share price has gone through the roof, and Eisner has pulled hundreds of millions a year in bonuses and option compensation.
Disney is one of the most piggish and corrupt corporations around these days, and like you said, they are EXTREMELY hard to boycott. To do so effectively, one would have to avoid all of its business outlets (including possibly all advertisers on its media outlets)
For instance, In addition to the Disney-labeled media outlets, Disney owns over 19 TV networks including ESPN, A&E, the History Channel, Lifetime, E! and Fox Family; 6 magazines like US Weekly and Discover; 6 movie studios including Touchstone Pictures, Hollywood Pictures, Miramax, Dimension and Buena Vista International; 50 Radio stations; 9 resorts; 5 book publishers, including Hyperion, Talk Miramax, and ABC Daytime Press; 2 sports teams (Anaheim Mighty Ducks and Anaheim Angels); and lots of other businesses, including 4 large theatrical productions, a Broadway theatre, 741 Disney Stores and the Disney catalogue, tons of licensing deals of characters for clothes, toys, teaching aides and videos/films for schools...as well as stakes in NFL.com and Movies.com and the 4900-acre town of Celebration, Florida.
Oh, that's just it's media holdings. Who knows what else they've got investments in.
Even if you successfully avoid exposure to Disney-sponsored entertainment (a herculean task), it's nearly impossible to get widespread success with this, and you'll still be buying products from companies that advertise through Disney.
Basically, it goes like this:
Disney: I OWN J00
You: WHAT YOU SAY!
Disney: T4KE 1T!
Woops...looks like I missed this part...So you are going to release the obfuscated source...
So I have to ask...what is to be gained by this? Since you're releasing machine-readable code that compiles into the finished product under the GPL, anyone can compile and or redistribute that code (or the compiled bytecode) for free anyway, so this project probably won't make a ton of money, especially if people go out of their way to redistribute your product as freeware (which they can do, since you're GPL'ing it). Someone will come around and clean up the code, and find ways to take advantage of your changes, eventually...
Meanwhile, you stand to lose a lot of good-will and potentially development support, code/patch submissions, and intangible stuff like that simply because you're doing something perceived as mean. I don't see how you can make a business case to do this...where's the upside?
If I'm reading the post correctly, the company in question doesn't intend to distribute source AT ALL. The plan as I see it is:
1. Take source tree from GPL project.
2. Make changes to source tree.
3. Obfuscate code and remove comments
4. Compile Obfuscated code and sell it as a product.
5. "We're not selling code from this GPL project, we're selling the compiled version of THIS"
6. Profit!
(I know I forgot the step about collecting underpants)
If the company's intent IS to distribute the Obfuscated source, they will have to put a notice in each altered file stating that it was changed, and the date of the changes, and release the changed code under the GPL. If the finished altered project is useful, somebody will come along and clean up the code, and very likely re-integrate it into the original project. A big pain in the ass, possibly giving the company in question a window of opportunity to sell their product (unless savvy ppl just recompile the obfuscated source and distribute binaries as freeware), but no big deal, although I think this may cause the company to lose a good deal of money (not to mention reputation), so I don't believe that's what the agenda is.
As I understand it though, there are no plans to distribute the source. The company plans to compile only their obfuscated version of the code, and claim they are not distributing a derivative work. If this project is owned/maintained by a small individual with no legal resources, they might even get away with it, as reprehensible and illegal as it may be. Of course, that individual could always just assign their copyright to the FSF, which has the expertise and the tenaciousness to defend the code, and this company will most likely be forced to capitulate and release their modified source, or at the very least discontinue distribution of the finished product. Either way, it represents a huge potential loss of investment if this one lawyer's legal opinion is flawed.
If I were the management of this company, I'd get a new lawyer, because the guy giving this advice is going to get them in trouble. If I were a shareholder of this company and I got wind of this plan, I'd divest before I lost all my money. If I were a shareholder of this company, and the plan got implemented without notifying anyone, and I ended up losing a bunch of money because of it, I'd sue management. If I were an employee of this company, and assigned to this project or one related to it, I'd do what I was told, while updating my resume and looking for other jobs, because most likely when the legal hammer comes down, that job isn't going to be there much longer (besides, who wants to work for a company with an ethical culture like this). While doing what I was told, I'd keep documentation on all potentially illegal activities I was involved with. Upon finding another job, I'd forward copies of that documentation to the owner of the original software, the FSF and the EFF. The two larger groups could then forward some legal advice to the owner, who can decide whether and how to pursue the matter.
Meanwhile, before this project really gets rolling, and management has committed a bunch of money to it, you should sit down with your immediate supervisor, specify your legal concerns, explain that obfuscating your modified source before compiling it doesn't make your product any less of a "derivative work" in technical terms, and that, if taken to court over it, a judge would most likely rule in the owner's favor, as this clearly violates the spirit of the license, even if it attempts to wiggle through a loophole. Explain also that even though the GPL has never been tested in court, it's been violated several times, and every time, the violating party has settled and come into compliance after being confronted with it, because they really didn't have much of a chance in court. Finally, explain that even if there is a slim possibility of wiggling through a tiny loophole, the company should abandon this strategy on purely ethical grounds. It's just wrong, and there are many better alternatives, which don't risk legal backlashes and turning your business into an industry pariah. At the very least, this idea should be shopped around to several good copyright and intellectual property lawyers, preferrably with experience in software copyright cases, and if possible, cases involving the GPL. Failure to get supporting legal opinions from several sources could easily be considered negligent assumption of risk and could expose management to a nasty shareholder lawsuit if this strategy backfires, not to mention the cost of losing intellectual property investments and reputation in the industry. Depending on the size of your company and its resources, this could even mean the company goes tits-up, or the relevent company division being dissolved. At any rate, a lot of you (including bosses) could lose jobs, and that's really not a good ting.
For instance, you could contact the owner of the code, and discuss purchasing the source tree under a different license. It wouldn't be free, but it still might be a lot cheaper than designing the project from scratch. Or you can do as another poster suggested, analyze the code and rewrite it, following the same basic design. The design engineers can study the source and draw out a design flowchart based on how the program works, which could be filled in with code by the programmers. This would at least keep you out of legal trouble. Alternatively, you could consider working with the GPL'ed project, releasing your modifications under the same license, and angling your business around integration and support contracts for the code, which your company would develop significant expertise in (depending on the type and complexity of the software in question, this may or may not be a good idea).
remember the scenes showing Arnold's augmented-reality HUD?
I'm sure this idea was bandied about long before that even, it's just the earliest one I thought of off the top of my head.
...but in some cases the bugs are actually glaringly obvious shortcomings in the basic product design.
There was a huge outcry in the technical community when Outlook was released with the capability to execute scripted content with no interaction by default. There were comments all over the internet about the huge can of worms this could open. Sure enough, Melissa, and later ILUVYOU caused billions of dollars worth of damage. Because some product manager at Microsoft thought it would be cool for users and businesses to be able to send each other interactive email if they really wanted to, but (rightly) figured they wouldn't be savvy enough to turn this feature on for themselves in order to display it correctly.
The question then is, if the program was designed to be able to execute code attached to emails, should Microsoft have been reasonably aware that particularly anti-social code could be executed that could potentially cause a lot of havoc? If they were so aware, should they be liable for releasing such a faulty product to such an (unnaturally) large user-base?