And as I mentioned in my original post, I'm using one.
A point, I confess, which utterly escaped me last time. Perhaps we're talking somewhat at cross purposes in which case?
I think you are overestimating my aversion to BSD code.
I didn't think of you as particularly averse - although I can see how it might have come over that way. You strike
me as someone who has investigated several alternatives and chosen sensibly based on the findings. I confess, I thought your
legal scenario a little over-cautious, but then since have a perfectly good public domain package to use, the question doesn't
really arise.
Also, if our project had already incorporated some BSD code and therefore had precedent (approval from management/legal, a CREDITS file or equivalent to put the attribution in) I would be more comfortable.
And that's the point, I suppose. Management are going to need to evolve procedures to handle the use of FOSS in the workplace, whether it be
development packages, or just office apps.
A lot of it is just a question of awareness, of course. There's probably a lucrative course of seminars
there if anyone wanted to start teaching them.
Actually I have reported 3 distinct problems with OO Calc (based on about an hour's usage).
Yes, yes. I understand that you don't like it, and I understand that it doesn't suit your needs particularly well at this time. Moving on...
And I can't help but wonder how many more nasty problems there are lurking given how quickly I found these 3.
And as it turns out, you have a point. There are code quality issues with the graphing package, and the graphing section is being re-written from the ground up, this time as a separate package. So it seems your concerns are
already being addressed.
I suspect that the entire code base may be beyond repair given this kind of serious bug discovery rate on a supposedly "mature" application.
Another overly broad generalisation, I think. Just because one module is overdue for some refactoring, that doesn't mean the entire codebase is beyond redemption. In fact from the number of using OOo every day, I'd suspect that the graphing code is an anomaly rather than the rule. Otherwise I'd be using AbiWord and Gnumeric (which apparently has excellent graphing capabilities) for my day to day needs rather than OOo. And a lot of others like me too, I suspect.
Perhaps it is OK for poor college students, or for high school students (though the student edition of Office is only $149), but for business people who depend on their office tools, I think the $75 per seat license fee (according to the OP) is money well spent.
mmm... but I think that in these days of shrinking budgets, that proposition might become an increasingly hard sell to the CEOs and CIOs of this world. Especially when they see their competitors increasingly evading the Microsoft Tax by going open. Doubly so if they find there's an office package that works for 90-95% of the workforce.
Still, best of luck and all that...
What, pray tell, do you envision usurping Office? Surely not OO, which is just a poor imitation. Perhaps Google Office will bump Microsoft off
You don't get it. It's not about which application gets to be the next king of the castle. ODF is going to blow Microsoft's office monopoly wide open. You'll have a choice of a couple of dozen apps, all of them with different interfaces, all optimised for different tasks, many of them free. Open Office is the vanguard, and by far the most visible, but what you're looking at here is a paradigm shift.
You left out the part where they fire me for exposing them to liability.
So let's get this straight: Hypothetically, you use BSD code on an internal project. You clearly document the licence and the obligations that it imposes should the code be distributed externally. Someone else distributes the code without observing those obligations, and they fire you for exposing them to liability. As opposed to, say, the miserable tosser who put the code out there without bothering to look at the documentation or do basic due diligence before distributing.
That seems a little harsh to me. Probably good grounds for a wrongful dismissal suit too, or whatever they call it in your part of world,
And also the fact that I am not the kind of person who thinks violating the BSD license is fine just because there are no consequences.
Of course you're not, and it was never my intention to imply otherwise. I apologise if I came across that way. But you know, using it on an internal project and making sure you comply with the licence internally, and making sure the potential obligations are well documented - I wouldn't have called that a
particularly cavalier attitude, myself.
And you must admit that it's possible things could get uglier. For example, an IP holding company could buy the copyright to the code and start suing.
I'll grant that's far-fetched, but stranger things have happened.
It does seem a bit of a stretch. I suppose it all depends on what you consider acceptable risk or not. I mean if don't do anything that could conceivably result in being sued, no one would ever do anything at all. Like
Bruce Schneier keeps saying -
you can construct a movie plot scenario to justify almost any course of action or inaction - sensible or otherwise.
I'm not going to go around copy-and-pasting such code willy-nilly.
Of course not, and I wouldn't suggest that you should. On the other hand, if you track back a few messages, we were talking about the use of Flex. Flex doesn't involve you cutting and pasting anything at all. What it does is generate code, and there are some standard chunks of code distributed as part of that package which get inserted into all of its output. So we're talking about using certain clearly defined chunks of code in a precise manner, and one which quite clearly falls within the intended use of the package. About as far from willy-nilly cut-and-paste as you can get,
And if you've ever done any compiler writing, you'll probably appreciate that, yes, a good lexical analyser generation package can indeed save months of work,
If anyone forgets to copy all the correct attributions when moving the code around, all of a sudden bam! You're illegal.
What's the worst case? The FOSS devs say "excuse me, you need to acknowledge us in your package", and your company says "oops, sorry. administrative oversight".
Everybody friends again.
It's not like you're going to going to lose your IP for missing out a CREDITS file. And from what I've seen from lurking on Groklaw (IANAL) I doubt that a judge would look kindly upon a suit for damages when the clear intent of the software licence was that it be used freely, and where the company had already
take action to place themselves in compliance with the licence.
As long as you make sure the requirement is documented in the project metadata, what's the problem?
[ That's not a dig - I just want to understand your position ]
Yours is an interesting supposition, but I think you are the one with flawed logic. First of all, I have not talked about menus and user interface differences at all
I think my logic was sound enough, given the assumptions in your post. If you want to introduce new elements for consideration, then the conclusion I draw amy
have to change, but that doesn't invalidate my earlier logic:)
My two complaints regarding OO Calc are that the syntax of the formulas is different, and the graphing performance is pathetic.
And to that extent, (and apart perhaps from the needless note of derision) I don't have any argument with you.
Clearly you don't like the way OO Calc does things, and I'll take your word for it regarding the graphing performance.
Therefore it's probably not a good choice for your at the moment. If the graphing problem is a common one, I expect it will
be addressed before too much longer; FOSS development cycles tend to be faster than proprietary ones. On the other hand
I don't suppose that Calc's formula syntax is ever going to be to your liking, so by all means stick with Excel.
The important thing is that you have a choice.
However, from there you seem to be arguing that
since OO Calc doesn't suit your needs, it therefore doesn't suit anyone else's need
almost everyone already uses Excel, therefore no one is going to want to switch
But really the only reason you've given me not to migrate my business to OO is that, if everyone else joins me, it might make your graphs run slower.
Amy while I sympathise, I don't find your argument particularly compelling.
if Word didn't support, or offered a lousy implementation of, some common word processing functions (like underlining, automatic TOC creation, etc), then Word would not have usurped Word Perfect.
Which is, in fact, the case. At the time
Wordperfect
was in the same position as MS Office is now - a de facto industry standard, MS Word ignored many WP conventions, most notably perhaps was WP's code-based format which offered many clear advantages over MS style based approach. Migrating to Word broke a lot of software
that was designed to take advantage of WP's codes features and if you do a quick Google you can still find
HOWTOs
for converting one format to the other, and even
advocacy pieces explaining why MS Word is not yet ready for X - although I'll grant that none of them cite speed in rendering graphs as a problem.
So the switch-over was nowhere near as easy as you suggest - and yet still it happened. And what happened once can happen again.
Personally, I think it will. If we price MS Office at 200 bucks a seat, then a company with 5000 office could sponsor a team of developer for e year
to fix the graphing problem, save 90% of that year's IT budget, and still have the work done inside their migration timetable. I don't think you can argue against numbers like that.
So, the fact that Word supplanted Word Perfect, and Excel usurped 123 are both, in my view, supportive of my logic.
I suppose that all depends on the conclusion you're trying to support. If your point is "Microsoft are the best" then fair enough - although in that case there are a few other points I might like introduce into the argument. If your point is that "open office is a toy", then no, your logic doesn't support that proposition at all. For anything else, I think you need to state your point more clearly.
At the end of the day, however, your complaints with OO Calc sound a lot like the advocacy pieces from those WP diehards who were so opposed to MS Word. I can sympathise, but I believe the fin
Given that Office is predominantly a business application, and given that Excel is the primary component for business users, I think this means that Open Office is simply unsuited for business users.
By which logic, MS Word never took off and everyone is still using
Word Perfect.
The fact that it doesn't seem to have worked that way suggests there may be a flaw in your logic
No FOSS tool that I know of limits what you can do with its output.
One category of programs that may cause such issues are lexical and syntactical analyzers (also known as lexer and parser generators), since they often include parts of themselves in their output.
Got any examples?
The most common lex and yacc tools distributed with Linux are
Flex and Bison - or at least they were when last I had occasion to use such things. It's not true in either of those cases.
Flex, if you look at its
sourceforge page
is distributed under the BSD licence. So there are no problems with flex.
Bison is more problematical, since it's released under the full GPL. The problem is
acknowledged by the FSF
Some programs copy parts of themselves into the output for technical reasons--for example, Bison copies a standard parser program into its output file. In such cases, the copied text in the output is covered by the same license that covers it in the source code. Meanwhile, the part of the output which is derived from the program's input inherits the copyright status of the input.
However the same FAQ entry continues:
As it happens, Bison can also be used to develop non-free programs. This is because we decided to explicitly permit the use of the Bison standard parser program in Bison output files without restriction.
So Bison isn't a threat either.
Which tools were you thinking of, specifically? I'm sure the authors of such tools don't intend to lay traps for proprietary developers, and I expect they'd be happy to make the relevant changes if it meant wider use of their tools.
Failing that, it would be a worthwhile exercise to publicise any such tools that are incompatible with proprietary development processes.
As opposed to just going "Open Source! Be Very Afraid!" which doesn't seem to contribute anything of value to the debate
Microsoft won't have any problems getting support from various free market enthusiasts -- for free.
Interesting. Because it seems to me that any free market enthusiast worth his salt ought to be supporting
Linux. Can't compete with zero price? Tough shit, that's just the way the market works. Can't write a better OS than
a bunch of amateur enthusiasts? Well then you've got no business being in the market. Survival of the fittest, baby!
I think we may have been pitching this on the wrong level in certain quarters. Thank you for that.
There's your problem right there: it won't garner nearly enough attention.
Well, that remains to be seen. I certainly don't see how the community's best interests are served by silence. On the other hand a well reasoned and carefully supported rebuttal can only help our cause.
Speed cameras aren't just put up as a revenue earner, or to piss you off
I'm guessing you don't drive in the UK. Some of them are quite definitely put up for no reason
other than as revenue earners. I can think of one road near where I live that's 40mph one side
of a roundabout, and then 30mph on the other. No good reason for it. It's a nice wide road on
both sides, no new hazards to justify the change in speed limit.
But they have speed cams, and that earns revenue. You'd almost think they were deliberately trying to catch motorists out,
wouldn't you?
But the thing that really gripes me about that particular case is that it introduces an
unnecessary hazard. If a motorist is caught out by the speed change, and he's expecting the car in front
to accelerate to 40 then he could go right into the back of the guy in front. And while it's still
his responsibility to keep his eyes open, I'd argue that the highest aim of good road design is
road safety, and that doesn't seem to be the case in this instance.
That's not to support the use of explosives, just so we're clear. But to say that there is
no financial motivation behind some speed camera placements doesn't tally with my experience at all.
Donations - Yeah, right, if you can't get someone to contribute to an OSS project, what makes you think you'll get enough donations
What makes me think that? Well for a start I read TFA. More to the point, in paragraph one of the Ars the linked to
this rather neat piece of debunking from Bruno Giussani.
Key Points:
Florence Devouard was apparently misquoted: the word "disappear" was never used, according to Giussani.In fact, he quotes Devourard as saying "I don't worry for the future". Note the "don't".
The Mediamedia Foundation has projected bandwidth costs of 60,000 to 100,000 USD for 2007.
The Mediamedia Foundation is currently receiving donations of between 30,000 and 40,000 USD each week
The Mediamedia Foundation has upwards of a million dollars in the bank, courtesy of their last fundraiser.
So, the foundation is already getting making between 90% and 120% of it's projected bandwidth costs,
and that's based on the worst case scenario. The have enough cash in hand to cover three months unsupported
operations, so if there's a slump in donations, they have reserves to ride it out.
Giussani also quoted from the Wikimedia Foundations financial statements over the last three years
which show that revenue and cash in hand have risen in line with costs over that period.
So that's what makes me think they'll get enough donations - the fact that they already are.
Why can't there be a "show relevant ads" button down at the bottom, at least!?
When I'm going to buy a $2500 piece of equipment, that click is worth a *lot* of money.
Certainly more than I'm willing to donate that often.
Let's try a hypothetical situation: Suppose they did this and
they were getting a lot of hits from a major vendor of routers
and hardware firewalls - let's call 'em "BizCo" since I don't
really have any axe to grind against any router manufacturer
Now, under normal circumstances, BizCo make a lot of sales
via their wikipedia page, and that generates a lot of cash
for wikimedia and for BizCo both. A win win scenario.
But suppose someone finds a backdoor in BizCo routers?
If wikipedia discusses the exploit, they may hurt BizCo
sales, and cost themselves money in the process.
Supposing it's just FUD spread by a competitor? How can
you trust wikipedia's writeup knowing that they make a
significant portion of their operating capital from
BizCo referrals?
Here's another one: supposing BizCo have a competing startup called
"GnuCo": free hardware, GPL software, exemplary secuirity. On the down
side, their advertising budget is near almost zero, and they've
survived this far mainly on word of mouth recommendations.
They have a superior product, but a click on them
earns wikipedia nothing. So what do you do?
Do you supply the link anyway, knowing that
each click on GnuCo costs wikipedia money, or do you just tweak the
seaching algorithms to start shuffling the less lucrative pages down
the search order. Bury them on page five or so and most people will
never see them.
Or maybe you give them a "related commerical links" page,
but the only link there goes to BizCo. Maybe you start to
subtly slant the articles against GnuCo - just to preserve
cashflow, you understand.
For that matter, what about the non-commercial pages? The ones that
cost so much to serve, and which return so little revenue. If you just
shuffle them down the search listings, just a little, you could
do so much more.... Which is the line of thinking that probably transformed
Yahoo! from the Google of its day into the ad-drenched pap-portal we find
today.
I'm not saying any of this is an inevitable consequence of
taking adverts. But there's no doubt in my mind that advertising
would add a whole new set of pressures on a project that already
has to work very hard to maintain a neutral point of view.
Personally, and maybe I'm being unduly pessimistic, but personally
I think it would be a disaster.
Also, I've been thinking about how people could cache Wikipedia, or
something, to help bandwidth costs. Like coral cache, but signed like
bit-torrent. I currently use less than 1% of the bandwidth I pay for,
the other 1.5 TB is available for something like this. Not much alone,
but I doubt I'm the only one willing to help.
I like this idea a lot better. I've thought for a while
that a lot of the bandwidth problems of popular sites would go away
if we used torrent style architecture, and signed packets
would make sure that what you got was the same as what was originally
sent.
I don't know of anything that does this specifically, but
something like Freenet
might be a good place to start. Certainly
the "internet-within-an-internet" model.
If they are using Google ads, then advertisers have no idea whether they are advertising on Wikipedia or not. Care to explain Google ads will compromise independence?
That's a big "if". Care to point out where it says they'd only consider Google? Not in TFA, I know that much
But even if so, they'd still be compromised. If nothing else, Google would be in a position to apply pressure. And we shouldn't count on Google always being under the same leadership as it is now. For that matter Google could be subject to pressure themselves. Or Google might make a plausible case for wikimedia bundling Google tracking googies or web-bugs out of the box. I'm sure Google would love to get their hands on all the profiling information Wikipedia could generate, and they'd probably be willing to give a better deal on adsense rates if they got it.
But even if not... it's still the thin end of the wedge. Once the project starts earning money and paying its editors, I think it's bound to change the character of the project. And personally, I don't think Wikipedia is broken.
There is always ad-blocking tools around. So what's the matter?
Apart from the ethics of the matter? How about introducing a conflict of interest?
At the moment the wikipedia core editors are free to strive for a neutral point of view.
But if they have paid editors funded by advertising revenue, then commercial concerns
can apply pressure by threatening to withdraw their support.
Vulnerable as Wikipedia is now to various private agenda, it's possible it could get a lot worse once there was an effective means of putting pressure on the editors
It's a community project. If wikipedia pisses off too many of its contributors, the project will die. Some people would see that as a bad thing.
These people need to grow up, ether support your precious community so it can remain the way it is or move on and let someone who can take your place.
Do they?
For one thing. the allegation that wikipedia is failing is far from proven; there may not be a problem to fix. For another, the wikipedians opposed to advertising are probably not the ones voicing doubts about the project's long term viability.
It's also worth pointing out that the author of TFA seems to define failing as not achieving excellence as fast as he or she would like. So there doesn't seem to be any terribly compelling reason to make an unpopular change, while there are good reasons for leaving it as it is. "If it ain't broke..."
Besides ads on Wikipedia, given the usual high search results on Google, would be worth quite a bit of money so I doubt they would even need to put up that many.
In which case, I'd expect answers.com to be making Google scale money. They're keeping awfully quiet about it if they are.
Also linus doesn't seem to really care about novel becoming friends with microsoft.
Nor should he. But this isn't about Microsoft and Novell holding hands; it's about Microsoft's implied threat to sue anyone who doesn't give Novell money.
And the seems to be mostly a FSF problems. It is as if they are on recess in third grade and looked at novel and microsoft playing and said "wha wha what! I thought we were friends, You cannot be friends with microsoft and us at the same time. So we don't like you anymore if your going to hang out with Microsoft. Whats it going to be novel, Us or them". It is sad really.
Nope. It's about downstream rights. Let me explain:
Novell are saying if you buy this software from us, you get extra rights - in this case the right not to be sued my Microsoft for alleged patent violations. Which would still be OK, except that the rights thus granted can't be passed on. If I buy a copy of SUSE and then give it to you, you don't get the anti-barratry coverage - you have to give money to Novell for that.
See, one of the obvious attacks against the GPL has always been patents. You put code in a project for which you hold a patent, and then say "you can read the source code all you like, but if you want to run the program you also need to licence my patent". In which case you could charge exorbitant fees and try and kill a project dead, or charge just enough to stop the non-commercial distros packaging it, or just pick and choose who you allowed to use the package. Add a dozen more such contributions from other developers, and enough submarine patents that removing the code becomes non-trivial, and you can kill any open source project dead like this.
So, to guard against this happening, the GPLv2 stipulates that by distributing software under that licence, you also licence any applicable patents you may hold, and that like the copyright licence, the patent licence is automatically sub-licenced should any downstream recipient of the software distribute it themselves.
Now the Microsoft-Novell agreement sidesteps this neatly. And it's a loophole we really need to close. Let's try an example
Suppose I have NickFortune OpenCode Inc, and I write software. To attract developers I release the code under the GPL, and bundle support into the sales agreement. Pretty conventional - no harm there. Even if I take out a patent on the core ideas, still no problem.
But let's suppose that I have a second company NickFortune Patents Inc. Then I can grant the patent to NF:PI; NF:OCI still distribute the code, but can't grant patent rights because they do not control them. NF:PI make a binding agreement not to sue customers of NF:OCI, but the agreement doesn't apply to anyone to whom my customers might distribute the software.
So in that scenario, we're back where we were with GPLv2, sans patent clause. It's a loophole and it needs to be plugged. At core, that's what the fuss is about.
The chance of the kernel going GPLv3 is still 0% - it never included the "newer version" provision that some use with the GPLv2.
That's a serious obstacle, but I don't think it's necessarily a show-stopper.
What you'd need is consensus among the majority of active devs, and the willingness to audit the code and work out which bits they owned free and clear. Then it's a recode operation for areas that are either of unknown provenance, or for which the submitter refuses to adopt GPLv3.
It would be an utter pain, and I'd guess it would set kernel development back by a year or so. On the other hand, it would be a good chance to clean out some hoary old cruft from the darker corners of the kernel, and it would help lay to rest SCO style FUD once and for all. To say nothing of putting an end to Novell's playground bully tactics.
Personally I think Linus' stand on DRM is more likely to be the insurmountable obstacle.
The problrem is that the Linux kernel isn't going GPL3 any time soon. Elements of the Kernel can dual license but then the GPL2 licenes negates anything
in the GPL3 as far as futher restrictions.
Well, that remains to be seen. Certainly I think the odds of a GPLv3 kernel are a hell of a lot higher than they were before the Novell-Microsoft patent agreement.
So, even with GPL3, it isn't going to be hard for novel to stay in comliance, all they have to do is fork all GPL3 only code or sit back and watch the linux kernel lose all the FSF code that goes GPL3 only.
That's taking quite a lot for granted as well. Even if there is a kernel fork, and I think that is probably inevitable now, the deciding factor will be which fork attracts the developers. Given that on the one hand we "free as in freedom", while on the other we have "give us your lunch money and my big friend promises not to beat you up", I think the v3 fork may well emerge as the main line. In which case Novell have to either strike out on their own, or else pay a lot of people to keep re-inventing wheels.
Beside that, I'm going to asume that novel would challenge the GPL3 in court. It is incompatible with GPL2 in both the spirit of GPL2 and the license it's self.
I've been thinking about that. It's not like anyone's going to be forced to licence new code under GPLv3, and the only ones who can change the licence of a GPLv2 codebase to add additional restrictions would be the copyright holder - creating in effect a new fork released under a new licence.
So I can't see most use cases having a problem. I can imagine that some of the devs who signed over their copyright over to the FSF might make a case similar to the one you describe, but that isn't going to break GPLv3, although it might result in a few FSF packages being forced to remain under v2
while the Foundation chase up some hackers for a recode-from-scratch effort.
The mioght even succesfully claim the the GPL3 ins't compatible with the GPL3.
Go on then, how's that going to work? I could do with a good laugh.
I mean, come on, this is a corporation, and you're complaining about ethics?
Well... yes. It's one thing to acknowledge the ethical bankruptcy of most modern corporations. That doesn't mean we can not or should not complain. In fact it's hard to see how this behaviour (which you concede is despicable) is ever going to be changed if we don't complain.
It is unclear why, in all situations, a blanket policy of honesty would be expected to maximize profits for corporations.
And do you mean to suggest that our only grounds for complaint against Microsoft should be financial?
Microsoft's goal is not to make you like them; it is to make lots of money
Frankly I couldn't care less about Microsoft want. It's what they do>/b> that bothers me.
let's be clear that they're all doing exactly what they're "supposed" to.
Supposed to according to whom and by what criteria? If turning a profit by whatever means is the only consideration, we should legalise
armed robbery and slave labour. Otherwise let's be clear that that Microsoft frequently attempt to fulfil an arguably legitimate imperative using methods that are undesirable and antisocial. Otherwise you're just framing the argument in such a way that Microsoft can never be criticised, and that's just silly.
That said... you might have posted this intending to make an oblique and ironic comment about Microsoft astroturfing, and how it gets everywhere. Perhaps someone would like to mod the parent funny?
There was no confusion in what I said. I referred to it a MSFT HTTP hack, and you named it.
Uh-huh.The AC you're defending with such vigour said there was an AJAX protocol. There isn't. You suggested
He's supposed to refer to AJAX as "use of a non-standard MSFT HTTP hack eventually picked up by the other browsers" instead of "protocol"?
So if you knew that XMLHttpRequest was no better in context than protocol, then why bother raising the subject? You could have said something like he's supposed to call AJAX "a catch all phrase for a collection of web development techniques centred around asynchronous HTTP and usually including client side scripting, dynamic HTML, CSS and XML data formats". That way you'd have kept the snide tone, but at the same time we'd have to accept that you know what you're talking about. As it is, you come across as just as ignorant and opinionated as the AC that started the whole mess.
Plenty of people call it a protocol
Lots of people think the Earth is flat. Good luck citing them as an authority on Slashdot.
his authority was real life experience
Allegedly. There's not much evidence of that in his posts however. Not only was confusion on the subject of protocols, the AC also cheerfully conflated AJAX with programming languages, and still doesn't seem to appreciate the difference.
he was a lot more patient responding to you than most people would, like me for example
Didn't come across that way to me. Maybe it's just that I tend to interpret rebuttals that start with "Excuse me?" as being overly aggressive.
All the same, if he'd either been technically correct, or if he hadn't claimed authority based on personal experience, I'd probably not have bothered.
What a bunch of nit picking bs. He's supposed to refer to AJAX as "use of a non-standard MSFT HTTP hack eventually picked up by the other browsers" instead of "protocol"? Spare me.
You seem to be referring to the XMLHttpRequest object. XMLHttpRequest is central to AJAX programming, however it isn't the same thing as AJAX either. AJAX is a loose collection of web development techniques usually including Asynchronous HTTP JavaScript, CSS, Dynamic HTML and XML. To confuse any one of these with AJAX itself suggests a fundamental ignorance of the subject.
He's supposed to refer to AJAX as "use of a non-standard MSFT HTTP hack eventually picked up by the other browsers" instead of "protocol"?
Well, he could refer to the XMLHttpRequest object, if that was what he meant. Then at least we'd be clear as to what he meant.
Spare me.
The poster you're so keen to defend didn't understand the difference between a AJAX and a protocol. You don't seem to understand the difference between AJAX and a JavaScript object. Still, at least you're not claiming to be 11% of 95 years of web development experience. If your AC friend, if he's going to be so snotty in his replies he'd be best advised to get his facts straight. Doubly so if he intends to claim to be an authority on the subject.
One is implemented as a number of Perl-based CGI scripts. The other is written using AJAX.
You are aware that AJAX is not a programming language, I take it?
Let's compare apples to apples. On the one hand you have a server side webmail system implemented using Perl,
and I assume the tried and tested CPAN CGI modules. On the other hand you had an AJAX backend written in what
language and implemented using what (if any) third party components?
If you want to be taken seriously, you need to provide this information.
Otherwise a lot of people are going to conclude that you're just blowing FUD
Slashdot Mirror
Fair enough, then. In which case, given the tone of my reply, thank you for the civil response.
A point, I confess, which utterly escaped me last time. Perhaps we're talking somewhat at cross purposes in which case?
I didn't think of you as particularly averse - although I can see how it might have come over that way. You strike me as someone who has investigated several alternatives and chosen sensibly based on the findings. I confess, I thought your legal scenario a little over-cautious, but then since have a perfectly good public domain package to use, the question doesn't really arise.
And that's the point, I suppose. Management are going to need to evolve procedures to handle the use of FOSS in the workplace, whether it be development packages, or just office apps.
A lot of it is just a question of awareness, of course. There's probably a lucrative course of seminars there if anyone wanted to start teaching them.
Yes, yes. I understand that you don't like it, and I understand that it doesn't suit your needs particularly well at this time. Moving on...
And as it turns out, you have a point. There are code quality issues with the graphing package, and the graphing section is being re-written from the ground up, this time as a separate package. So it seems your concerns are already being addressed.
Another overly broad generalisation, I think. Just because one module is overdue for some refactoring, that doesn't mean the entire codebase is beyond redemption. In fact from the number of using OOo every day, I'd suspect that the graphing code is an anomaly rather than the rule. Otherwise I'd be using AbiWord and Gnumeric (which apparently has excellent graphing capabilities) for my day to day needs rather than OOo. And a lot of others like me too, I suspect.
mmm... but I think that in these days of shrinking budgets, that proposition might become an increasingly hard sell to the CEOs and CIOs of this world. Especially when they see their competitors increasingly evading the Microsoft Tax by going open. Doubly so if they find there's an office package that works for 90-95% of the workforce. Still, best of luck and all that...
What, pray tell, do you envision usurping Office? Surely not OO, which is just a poor imitation. Perhaps Google Office will bump Microsoft off
You don't get it. It's not about which application gets to be the next king of the castle. ODF is going to blow Microsoft's office monopoly wide open. You'll have a choice of a couple of dozen apps, all of them with different interfaces, all optimised for different tasks, many of them free. Open Office is the vanguard, and by far the most visible, but what you're looking at here is a paradigm shift.
You never know, you might even like it.
So let's get this straight: Hypothetically, you use BSD code on an internal project. You clearly document the licence and the obligations that it imposes should the code be distributed externally. Someone else distributes the code without observing those obligations, and they fire you for exposing them to liability. As opposed to, say, the miserable tosser who put the code out there without bothering to look at the documentation or do basic due diligence before distributing.
That seems a little harsh to me. Probably good grounds for a wrongful dismissal suit too, or whatever they call it in your part of world,
Of course you're not, and it was never my intention to imply otherwise. I apologise if I came across that way. But you know, using it on an internal project and making sure you comply with the licence internally, and making sure the potential obligations are well documented - I wouldn't have called that a particularly cavalier attitude, myself.
It does seem a bit of a stretch. I suppose it all depends on what you consider acceptable risk or not. I mean if don't do anything that could conceivably result in being sued, no one would ever do anything at all. Like Bruce Schneier keeps saying - you can construct a movie plot scenario to justify almost any course of action or inaction - sensible or otherwise.
Of course not, and I wouldn't suggest that you should. On the other hand, if you track back a few messages, we were talking about the use of Flex. Flex doesn't involve you cutting and pasting anything at all. What it does is generate code, and there are some standard chunks of code distributed as part of that package which get inserted into all of its output. So we're talking about using certain clearly defined chunks of code in a precise manner, and one which quite clearly falls within the intended use of the package. About as far from willy-nilly cut-and-paste as you can get,
And if you've ever done any compiler writing, you'll probably appreciate that, yes, a good lexical analyser generation package can indeed save months of work,
What's the worst case? The FOSS devs say "excuse me, you need to acknowledge us in your package", and your company says "oops, sorry. administrative oversight". Everybody friends again.
It's not like you're going to going to lose your IP for missing out a CREDITS file. And from what I've seen from lurking on Groklaw (IANAL) I doubt that a judge would look kindly upon a suit for damages when the clear intent of the software licence was that it be used freely, and where the company had already take action to place themselves in compliance with the licence.
As long as you make sure the requirement is documented in the project metadata, what's the problem?
[ That's not a dig - I just want to understand your position ]
I think my logic was sound enough, given the assumptions in your post. If you want to introduce new elements for consideration, then the conclusion I draw amy have to change, but that doesn't invalidate my earlier logic :)
And to that extent, (and apart perhaps from the needless note of derision) I don't have any argument with you. Clearly you don't like the way OO Calc does things, and I'll take your word for it regarding the graphing performance. Therefore it's probably not a good choice for your at the moment. If the graphing problem is a common one, I expect it will be addressed before too much longer; FOSS development cycles tend to be faster than proprietary ones. On the other hand I don't suppose that Calc's formula syntax is ever going to be to your liking, so by all means stick with Excel. The important thing is that you have a choice.
However, from there you seem to be arguing that
But really the only reason you've given me not to migrate my business to OO is that, if everyone else joins me, it might make your graphs run slower. Amy while I sympathise, I don't find your argument particularly compelling.
Which is, in fact, the case. At the time Wordperfect was in the same position as MS Office is now - a de facto industry standard, MS Word ignored many WP conventions, most notably perhaps was WP's code-based format which offered many clear advantages over MS style based approach. Migrating to Word broke a lot of software that was designed to take advantage of WP's codes features and if you do a quick Google you can still find HOWTOs for converting one format to the other, and even advocacy pieces explaining why MS Word is not yet ready for X - although I'll grant that none of them cite speed in rendering graphs as a problem. So the switch-over was nowhere near as easy as you suggest - and yet still it happened. And what happened once can happen again.
Personally, I think it will. If we price MS Office at 200 bucks a seat, then a company with 5000 office could sponsor a team of developer for e year to fix the graphing problem, save 90% of that year's IT budget, and still have the work done inside their migration timetable. I don't think you can argue against numbers like that.
I suppose that all depends on the conclusion you're trying to support. If your point is "Microsoft are the best" then fair enough - although in that case there are a few other points I might like introduce into the argument. If your point is that "open office is a toy", then no, your logic doesn't support that proposition at all. For anything else, I think you need to state your point more clearly.
At the end of the day, however, your complaints with OO Calc sound a lot like the advocacy pieces from those WP diehards who were so opposed to MS Word. I can sympathise, but I believe the fin
By which logic, MS Word never took off and everyone is still using Word Perfect.
The fact that it doesn't seem to have worked that way suggests there may be a flaw in your logic
Got any examples?
The most common lex and yacc tools distributed with Linux are Flex and Bison - or at least they were when last I had occasion to use such things. It's not true in either of those cases.
Flex, if you look at its sourceforge page is distributed under the BSD licence. So there are no problems with flex.
Bison is more problematical, since it's released under the full GPL. The problem is acknowledged by the FSF
However the same FAQ entry continues:
So Bison isn't a threat either.
Which tools were you thinking of, specifically? I'm sure the authors of such tools don't intend to lay traps for proprietary developers, and I expect they'd be happy to make the relevant changes if it meant wider use of their tools.
Failing that, it would be a worthwhile exercise to publicise any such tools that are incompatible with proprietary development processes. As opposed to just going "Open Source! Be Very Afraid!" which doesn't seem to contribute anything of value to the debate
Interesting. Because it seems to me that any free market enthusiast worth his salt ought to be supporting Linux. Can't compete with zero price? Tough shit, that's just the way the market works. Can't write a better OS than a bunch of amateur enthusiasts? Well then you've got no business being in the market. Survival of the fittest, baby!
I think we may have been pitching this on the wrong level in certain quarters. Thank you for that.
Well, that remains to be seen. I certainly don't see how the community's best interests are served by silence. On the other hand a well reasoned and carefully supported rebuttal can only help our cause.
I'm guessing you don't drive in the UK. Some of them are quite definitely put up for no reason other than as revenue earners. I can think of one road near where I live that's 40mph one side of a roundabout, and then 30mph on the other. No good reason for it. It's a nice wide road on both sides, no new hazards to justify the change in speed limit.
But they have speed cams, and that earns revenue. You'd almost think they were deliberately trying to catch motorists out, wouldn't you?
But the thing that really gripes me about that particular case is that it introduces an unnecessary hazard. If a motorist is caught out by the speed change, and he's expecting the car in front to accelerate to 40 then he could go right into the back of the guy in front. And while it's still his responsibility to keep his eyes open, I'd argue that the highest aim of good road design is road safety, and that doesn't seem to be the case in this instance.
That's not to support the use of explosives, just so we're clear. But to say that there is no financial motivation behind some speed camera placements doesn't tally with my experience at all.
What makes me think that? Well for a start I read TFA. More to the point, in paragraph one of the Ars the linked to this rather neat piece of debunking from Bruno Giussani.
Key Points:
So, the foundation is already getting making between 90% and 120% of it's projected bandwidth costs, and that's based on the worst case scenario. The have enough cash in hand to cover three months unsupported operations, so if there's a slump in donations, they have reserves to ride it out.
Giussani also quoted from the Wikimedia Foundations financial statements over the last three years which show that revenue and cash in hand have risen in line with costs over that period.
So that's what makes me think they'll get enough donations - the fact that they already are.
Why do you assume otherwise?
Let's try a hypothetical situation: Suppose they did this and they were getting a lot of hits from a major vendor of routers and hardware firewalls - let's call 'em "BizCo" since I don't really have any axe to grind against any router manufacturer
Now, under normal circumstances, BizCo make a lot of sales via their wikipedia page, and that generates a lot of cash for wikimedia and for BizCo both. A win win scenario.
But suppose someone finds a backdoor in BizCo routers? If wikipedia discusses the exploit, they may hurt BizCo sales, and cost themselves money in the process. Supposing it's just FUD spread by a competitor? How can you trust wikipedia's writeup knowing that they make a significant portion of their operating capital from BizCo referrals?
Here's another one: supposing BizCo have a competing startup called "GnuCo": free hardware, GPL software, exemplary secuirity. On the down side, their advertising budget is near almost zero, and they've survived this far mainly on word of mouth recommendations. They have a superior product, but a click on them earns wikipedia nothing. So what do you do?
Do you supply the link anyway, knowing that each click on GnuCo costs wikipedia money, or do you just tweak the seaching algorithms to start shuffling the less lucrative pages down the search order. Bury them on page five or so and most people will never see them.
Or maybe you give them a "related commerical links" page, but the only link there goes to BizCo. Maybe you start to subtly slant the articles against GnuCo - just to preserve cashflow, you understand.
For that matter, what about the non-commercial pages? The ones that cost so much to serve, and which return so little revenue. If you just shuffle them down the search listings, just a little, you could do so much more.... Which is the line of thinking that probably transformed Yahoo! from the Google of its day into the ad-drenched pap-portal we find today.
I'm not saying any of this is an inevitable consequence of taking adverts. But there's no doubt in my mind that advertising would add a whole new set of pressures on a project that already has to work very hard to maintain a neutral point of view. Personally, and maybe I'm being unduly pessimistic, but personally I think it would be a disaster.
I like this idea a lot better. I've thought for a while that a lot of the bandwidth problems of popular sites would go away if we used torrent style architecture, and signed packets would make sure that what you got was the same as what was originally sent.
I don't know of anything that does this specifically, but something like Freenet might be a good place to start. Certainly the "internet-within-an-internet" model.
That's a big "if". Care to point out where it says they'd only consider Google? Not in TFA, I know that much
But even if so, they'd still be compromised. If nothing else, Google would be in a position to apply pressure. And we shouldn't count on Google always being under the same leadership as it is now. For that matter Google could be subject to pressure themselves. Or Google might make a plausible case for wikimedia bundling Google tracking googies or web-bugs out of the box. I'm sure Google would love to get their hands on all the profiling information Wikipedia could generate, and they'd probably be willing to give a better deal on adsense rates if they got it.
But even if not... it's still the thin end of the wedge. Once the project starts earning money and paying its editors, I think it's bound to change the character of the project. And personally, I don't think Wikipedia is broken.
Apart from the ethics of the matter? How about introducing a conflict of interest?
At the moment the wikipedia core editors are free to strive for a neutral point of view. But if they have paid editors funded by advertising revenue, then commercial concerns can apply pressure by threatening to withdraw their support.
Vulnerable as Wikipedia is now to various private agenda, it's possible it could get a lot worse once there was an effective means of putting pressure on the editors
It's a community project. If wikipedia pisses off too many of its contributors, the project will die. Some people would see that as a bad thing.
Do they?
For one thing. the allegation that wikipedia is failing is far from proven; there may not be a problem to fix. For another, the wikipedians opposed to advertising are probably not the ones voicing doubts about the project's long term viability.
It's also worth pointing out that the author of TFA seems to define failing as not achieving excellence as fast as he or she would like. So there doesn't seem to be any terribly compelling reason to make an unpopular change, while there are good reasons for leaving it as it is. "If it ain't broke..."
In which case, I'd expect answers.com to be making Google scale money. They're keeping awfully quiet about it if they are.
Nor should he. But this isn't about Microsoft and Novell holding hands; it's about Microsoft's implied threat to sue anyone who doesn't give Novell money.
Nope. It's about downstream rights. Let me explain:
Novell are saying if you buy this software from us, you get extra rights - in this case the right not to be sued my Microsoft for alleged patent violations. Which would still be OK, except that the rights thus granted can't be passed on. If I buy a copy of SUSE and then give it to you, you don't get the anti-barratry coverage - you have to give money to Novell for that.
See, one of the obvious attacks against the GPL has always been patents. You put code in a project for which you hold a patent, and then say "you can read the source code all you like, but if you want to run the program you also need to licence my patent". In which case you could charge exorbitant fees and try and kill a project dead, or charge just enough to stop the non-commercial distros packaging it, or just pick and choose who you allowed to use the package. Add a dozen more such contributions from other developers, and enough submarine patents that removing the code becomes non-trivial, and you can kill any open source project dead like this.
So, to guard against this happening, the GPLv2 stipulates that by distributing software under that licence, you also licence any applicable patents you may hold, and that like the copyright licence, the patent licence is automatically sub-licenced should any downstream recipient of the software distribute it themselves.
Now the Microsoft-Novell agreement sidesteps this neatly. And it's a loophole we really need to close. Let's try an example
Suppose I have NickFortune OpenCode Inc, and I write software. To attract developers I release the code under the GPL, and bundle support into the sales agreement. Pretty conventional - no harm there. Even if I take out a patent on the core ideas, still no problem.
But let's suppose that I have a second company NickFortune Patents Inc. Then I can grant the patent to NF:PI; NF:OCI still distribute the code, but can't grant patent rights because they do not control them. NF:PI make a binding agreement not to sue customers of NF:OCI, but the agreement doesn't apply to anyone to whom my customers might distribute the software.
So in that scenario, we're back where we were with GPLv2, sans patent clause. It's a loophole and it needs to be plugged. At core, that's what the fuss is about.
That's a serious obstacle, but I don't think it's necessarily a show-stopper.
What you'd need is consensus among the majority of active devs, and the willingness to audit the code and work out which bits they owned free and clear. Then it's a recode operation for areas that are either of unknown provenance, or for which the submitter refuses to adopt GPLv3.
It would be an utter pain, and I'd guess it would set kernel development back by a year or so. On the other hand, it would be a good chance to clean out some hoary old cruft from the darker corners of the kernel, and it would help lay to rest SCO style FUD once and for all. To say nothing of putting an end to Novell's playground bully tactics.
Personally I think Linus' stand on DRM is more likely to be the insurmountable obstacle.
Well, that remains to be seen. Certainly I think the odds of a GPLv3 kernel are a hell of a lot higher than they were before the Novell-Microsoft patent agreement.
That's taking quite a lot for granted as well. Even if there is a kernel fork, and I think that is probably inevitable now, the deciding factor will be which fork attracts the developers. Given that on the one hand we "free as in freedom", while on the other we have "give us your lunch money and my big friend promises not to beat you up", I think the v3 fork may well emerge as the main line. In which case Novell have to either strike out on their own, or else pay a lot of people to keep re-inventing wheels.
I've been thinking about that. It's not like anyone's going to be forced to licence new code under GPLv3, and the only ones who can change the licence of a GPLv2 codebase to add additional restrictions would be the copyright holder - creating in effect a new fork released under a new licence.
So I can't see most use cases having a problem. I can imagine that some of the devs who signed over their copyright over to the FSF might make a case similar to the one you describe, but that isn't going to break GPLv3, although it might result in a few FSF packages being forced to remain under v2 while the Foundation chase up some hackers for a recode-from-scratch effort.
Go on then, how's that going to work? I could do with a good laugh.
Well... yes. It's one thing to acknowledge the ethical bankruptcy of most modern corporations. That doesn't mean we can not or should not complain. In fact it's hard to see how this behaviour (which you concede is despicable) is ever going to be changed if we don't complain.
And do you mean to suggest that our only grounds for complaint against Microsoft should be financial?
Frankly I couldn't care less about Microsoft want. It's what they do>/b> that bothers me.
Supposed to according to whom and by what criteria? If turning a profit by whatever means is the only consideration, we should legalise armed robbery and slave labour. Otherwise let's be clear that that Microsoft frequently attempt to fulfil an arguably legitimate imperative using methods that are undesirable and antisocial. Otherwise you're just framing the argument in such a way that Microsoft can never be criticised, and that's just silly.
... you might have posted this intending to make an oblique and ironic comment about Microsoft astroturfing, and how it gets everywhere. Perhaps someone would like to mod the parent funny?
That said
Present tense: if Linux is just as good as (I assume you're referring to) Vista
Future tense: then Linux is going to make a bigger impact on (I presume) the OS market
Past tense: than Linux already has
So in other words if Linux is desktop ready now, then we can expect Linux deployment to skyrocket.
I find myself agreeing with what you said, but not with what I think you you meant. How odd.
Uh-huh.The AC you're defending with such vigour said there was an AJAX protocol. There isn't. You suggested
So if you knew that XMLHttpRequest was no better in context than protocol, then why bother raising the subject? You could have said something like he's supposed to call AJAX "a catch all phrase for a collection of web development techniques centred around asynchronous HTTP and usually including client side scripting, dynamic HTML, CSS and XML data formats". That way you'd have kept the snide tone, but at the same time we'd have to accept that you know what you're talking about. As it is, you come across as just as ignorant and opinionated as the AC that started the whole mess.
Lots of people think the Earth is flat. Good luck citing them as an authority on Slashdot.
Allegedly. There's not much evidence of that in his posts however. Not only was confusion on the subject of protocols, the AC also cheerfully conflated AJAX with programming languages, and still doesn't seem to appreciate the difference. Didn't come across that way to me. Maybe it's just that I tend to interpret rebuttals that start with "Excuse me?" as being overly aggressive.All the same, if he'd either been technically correct, or if he hadn't claimed authority based on personal experience, I'd probably not have bothered.
You seem to be referring to the XMLHttpRequest object. XMLHttpRequest is central to AJAX programming, however it isn't the same thing as AJAX either. AJAX is a loose collection of web development techniques usually including Asynchronous HTTP JavaScript, CSS, Dynamic HTML and XML. To confuse any one of these with AJAX itself suggests a fundamental ignorance of the subject.
Well, he could refer to the XMLHttpRequest object, if that was what he meant. Then at least we'd be clear as to what he meant.The poster you're so keen to defend didn't understand the difference between a AJAX and a protocol. You don't seem to understand the difference between AJAX and a JavaScript object. Still, at least you're not claiming to be 11% of 95 years of web development experience. If your AC friend, if he's going to be so snotty in his replies he'd be best advised to get his facts straight. Doubly so if he intends to claim to be an authority on the subject.
You are aware that AJAX is not a programming language, I take it?
Let's compare apples to apples. On the one hand you have a server side webmail system implemented using Perl, and I assume the tried and tested CPAN CGI modules. On the other hand you had an AJAX backend written in what language and implemented using what (if any) third party components?
If you want to be taken seriously, you need to provide this information. Otherwise a lot of people are going to conclude that you're just blowing FUD