Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Esther Schindler writes "Do you use SOAP, CORBA or EJBs? You might want to take a look at Etch, writes James Turner for CIO.com. It's language-, platform- and transport-agnostic, and Cisco is planning to release it as open source. Certainly, it offers some technical benefits: 'In addition to a simplified configuration, Etch also promises less overhead over the wire, compared to SOAP. In a testbed environment where SOAP was managing around 900 calls a second, Etch generated more than 50,000 messages in a one-way mode, and 15,000 transactions with a full round-trip, company officials stated.' And the open source part? Cisco is in the process of deciding what license to use. 'The intent is to use a less restrictive license than GPL, perhaps Apache or Mozilla. This is to allow commercial developers to incorporate Etch into products without licensing issues. A final announcement on the licensing decision will be available in the next month.'"

The intent is to use a less restrictive license than GPL, perhaps Apache or Mozilla. This is to allow commercial developers to incorporate Etch into products without licensing issues.

Which also makes it incompatible with the GPL, I think.

I figure, if you're going less restrictive than GPL, do it with a license that's compatible with the GPL. Otherwise, GPL or LGPL will allow open source developers to integrate it into (GPL'd) products without licensing issues.

Glad to see more and more companies moving away from GPL, understanding that it will only limit the potential adoption. As a highly respected registered member of the Slashdot community, I'm posting as AC as this post will very likely be modded troll.

No, but it does make it traceable, a tenant of accountable. You may not know the person, but after a period of time you can get whether they are consistent in their posting. Are they informative, does other research into the issue back up their voiced opinion, are they logical, and do they seem to have an agenda?

The meme "What a bunch of group-think sheep." is becoming a indication of a group-thinker (a misnomer if there ever was). Just because a group of people think similarly, that makes them guilty o

Sorry to feed the troll, but the point of the GPL is not to increase adoption. Your absolutely right to say that other licenses will lead to greater adoption- but this is adoption by people who may take, take, take and not give back.
Besides, it sounds like LGPL is what's needed in this case, anyhow.

Sorry to feed the troll, but the point of the GPL is not to increase adoption. Your absolutely right to say that other licenses will lead to greater adoption- but this is adoption by people who may take, take, take and not give back.

The company I work for sells closed source software. We also use some open source software (not GPL) in the product.

We contribute back to the open source we use because it's more sensible. Adding the same features back in again and again would be counterproductive. We'd rather they get added to the open source project permanently.

We have a blanket ban on using GPL'd source, though. We can't afford to GPL our entire 20 million line software stack, which would be the result of using even a tiny bit of GPL code.

Try to understand that not everyone loves the GPL and not everyone that doesn't love the GPL is a troll.

Now it's my turn to get modded into oblivion for not being fond of the GPL. Sigh.

We contribute back to the open source we use because it's more sensible.

Well, the positive side is that you're contributing something. But I'd rather say that as "We contribute back to the open source we use only when it's more sensible". That means trivial fixes, basic features and other things that doesn't threaten your business and is cheaper to "outsource" the maintenance on. Any time it's major features, more specific layers to the business you're in that could make it easier to produce a software stack like yours, most decide to pile it up on their 20 MLOC proprietary pi

So what we(end users) need is a compromise between BSD and GPL. Perhaps a time/version-delayed source release? After x years, or y iterations, the entire source must be released publicly. The creater is not responsible for use, bugs or any other miscellaneous claims. Thus, proprietory creators could still pimp their 'better' version and maintain in house benefits, while end users would enjoy the 4 freedoms and perhaps even be able to predict the likely cause (and thus a remedy) of their bugged experience.

Such a license would be extremely difficult, if not impossible to enforce.A compromise already exists in the form of the LGPL, which retains the restrictiveness of the GPL, but also allows closed-source code to link to it.

Personally, I feel that LGPL should be the default license, rather than vice versa, given what a headache the linking cause can cause to commercial developers.

This even causes problems for non-technology businesses who need to run proprietary software internally as a function of their busi

It would be very difficult for enforcement of every project, but the truly successful benefiting projects that don't comply would eventually be compelled to just because of the outcry. If some niche market projects get by without being too obnoxious making a reasonable living, well, who cares? But when successful projects are being obnoxious as in the case of Apple to BSD... (speculation warning on both sides of the parenthesis!) if everyone was being told that Apple was ripping off poor little BSD, the upr

I only use BSD or similarly licensed software in my offerings as well. And generally I do give back all improvements to BSD that *make sense*. For example, a niche modification that only applies to my software doesn't really make sense to "give back" because no one wants it. But general bug fixes or features do make sense to give back.BSD hasn't improved as fast as GPL because when someone takes bits of BSD and uses it in their software, the BSD bits are NOT their core offering. This is completely opposite

Sorry to feed the troll, but the point of the GPL is not to increase adoption. Your absolutely right to say that other licenses will lead to greater adoption- but this is adoption by people who may take, take, take and not give back.

The company I work for sells closed source software. We also use some open source software (not GPL) in the product.

We contribute back to the open source we use because it's more sensible. Adding the same features back in again and again would be counterproductive. We'd rather they get added to the open source project permanently.

We have a blanket ban on using GPL'd source, though. We can't afford to GPL our entire 20 million line software stack, which would be the result of using even a tiny bit of GPL code.

Try to understand that not everyone loves the GPL and not everyone that doesn't love the GPL is a troll.

Now it's my turn to get modded into oblivion for not being fond of the GPL. Sigh.

Is that really so? I thought the GPL only "infected" if you had to link against the GPL'ed code. Or is your codebase that... interconnected? And what about LGPL? Inquiring minds want to know!

I do not like companies like yours at all. I've worked in a couple, and the culture of them tends to be trying to put down any Open Source competitors and somehow claim your product is better when it isn't.

One of these companies was basically a one-trick-pony that had one really neat technology and a bunch of non-GPL Open Source around it. They consistently bastardized the non-GPL Open Source and knowingly added huge security vulnerabilities for the sake of expediency and being able to have their feature

We can't afford to GPL our entire 20 million line software stack, which would be the result of using even a tiny bit of GPL code.

So don't use it! I doubt the people who released it under the GPL care. If they had wanted you to be able to use this "community" source code in your closed-source product they would have released it under the LGPL.

I've never met a GPL code developer who released his code under GPL because he was forced.

I support GPL because I believe if something is important it should be codified and that if you develop something for the community you should protect it for the community. But that doesn't mean that releasing something under an FOSS license without a "recontribute/openness" clause doesn't mean that there won't be active community development. Something built on and from sharing will always foster more sharing, it's an issue of principal.

That's because you've only met people similar to you. It's pretty normal to mostly encounter others of a like nature.

However, there are plenty of groups out there who would quite happily take GPL code and add it to a closed source app, if the licence allowed them (and some that will do so even against the licence). Just because you haven't personally met them, doesn't mean they don't exist.

OpenBSD doesn't want to take GPL'ed code. They can, but they don't want to.They are perfectly fine to include it (and they do include GCC, for instance), and even link to it (but then the derived work will have to be GPL'ed and they don't want that).

And some projects have the problem in the inverse direction. Linux can't benefit from dtrace except in design principles.

Or even the fantastic ZFS.

Oh well, I guess it's all down to the same premise: if you don't want/can't use it, then stop bitching and go write

Except that giving a "BSD exception" to the GPL would make the point of the GPL kind of moot.

The GNU GPL is there to make sure every single user of GPL'ed code has the 4 software freedoms.

The BSD's only make sure for the first recipient.

I'm not claiming the first is better than the second (although I believe so), just that their purposes are different enough to make it a childish request instead of coding your own version like a real man.

A BSD exception to the GPL would look something like "must share under the GPL, unless the recipient project is licensed under: CDDL, BSD, APL, MPL, MIT,... " meaning the whole project would have to be under that license, and only the BSD bits could be integrated in to closed source stuff ( the GPL drivers, whatever would have to be omitted from the closed integration )

Under such a scenario, when the majority of source files in a BSD project contain a snippet of GPL code, and that project can no longer build without those GPL snippets, then the project is effectively GPL since the GPL code has become inseparable from the BSD code.Or else the exemption allows the code to become relicensed as BSD when included in a BSD project - then I can start a "GNU/Linux/BSD" project which is simply a repackaging of regular GNU/Linux under a BSD license.

More and more companies moving away from GPL? That's a strange conclusion, considering that it's probably had the fastest growing mindshare an uptake of any software license, ever, and that GPLv3 is proving very popular already with new projects and migrations.There's absolutely no ethical reason to choose a less restrictive license over the GPL. The only thing the GPL restricts is the ability to restrict others. THAT is possibly a reason to avoid it, since, for example, I would like to prevent military

There's absolutely no ethical reason to choose a less restrictive license over the GPL.

That depends on who you ask.

The only thing the GPL restricts is the ability to restrict others.

Funny thing is, it isn't possible anyway to "restrict others" in that fashion without their cooperation (buying/downloading your software). It restricts the choices available to the end user by causing certain products to not exist.

There's absolutely no ethical reason to choose a less restrictive license over the GPL.

I'm not so sure about that. They may just not want to force other people to release their source code.

But I would definitely say that if you want to release something like this to the open source community, then there is no justifiable reason not to at least use the LGPL. That would achieve the best of both worlds! It would ensure the source code remained community source code, whilst also allowing it to be used in proprietary, closed-source products without forcing those products to adopt an open source l

Glad to see more and more companies moving away from GPL, understanding that it will only limit the potential adoption. As a highly respected registered member of the Slashdot community, I'm posting as AC as this post will very likely be modded troll.

Don't exaggerate.

Sometimes the GPL is the right license, sometimes it isn't. Sometimes it increases adoption (Linux kernel), sometimes it doesn't.

In this case, a messaging protocol, the natural license is indeed not the GPL. Better ideas are Apache, BSD, LGPL, etc.

Sometimes it increases adoption (Linux kernel), sometimes it doesn't."
Actually I'd argue that Linuxes adoption is despite the GPL, not because of it. Linux was at the right place ( free, on commodity hardware ) at the right time ( BSD being sued by AT&T , commercial UNIX licensing fees skyrocketting to a ridiculous level ) and that's it.

Both those protocols suffer from 1 problem: bloat. The reason they're bloated and inefficient is because a committee decided how and what to add to the protocol once it was initiated, and we all know how well that works out.

SOAP was a 'quick and dirty solution (by Don Box IIRC) to (apart from getting a job at MS:) ) transfer COM calls over a http tunnel instead of the usual DCE-RPC tunnel, and it worked well when you only wanted to send a request to an object. Obviously, it has to have a webserver on the other end which slows it down tremendously, and then they added support for all kinds of complex types and a large schema as well. I'm surprised it works at all after seeing the raw WSDL code!

CORBA... designed by committee to do everything including transport kitchen sinks.

Since I've been working in the industry there is a tendency for supposedly bright people to take something simple and 'make it a general purpose solution' or 'implement some framework features' which nearly always breaks it into a bloated POS far removed from the original, simple, easy to use, and effective solution.

I welcome Cisco's new protocol, I don't care if it doesn't do everything I might possibly ever want to do, as long as it does the majority of my work quickly and simply. I can work around the edge cases myself, possibly even (gosh!) redesigning the way those edge cases work.

It'll be interesting to compare Etch to ICE [zeroc.com], which is a GPL'd open-source, cross-language RPC toolkit (you can buy commerical licenses too). It's quite widely used by banks and is generally reckoned to be speedy.

Their standard quoted price is $10K for unlimited royalty-free distribution, but they are *VERY* willing to work with you to price the product correctly for your product. Don't discount that number if you have a commercial application. Negotiating a percentage of sales opposed to writing your own communications subsystem is really a no-brainer.

looking at the widthof the column in thearticle, and cio.comwonders why nobodyvisits their siteand so they have topimp their ad-ladensite on Slashdot ina sure sign of des-peration. Click nextto continue.

Or you release the specs with code that people can't just do what they want with, and then the only people that use it are you, and the people that pay you for your reference implementation, like NFS ( which is just terrible on linux, doesn't exist on windows, and only really works on the commercial UNIXes that paid Sun for their code )

All of these distributed technologies have been shit. CORBA was absolutely hell to develop with. Besides the runtime performance problems, development was always a huge hassle. It rarely just worked. J

Java's RMI was slightly better. But again, the development overhead was huge. Generating proxy and stub classes becomes a chore really quickly, and debugging becomes a real challenge.

SOAP was a little bit better than CORBA and Java RMI. At least writing the object layer code is a far more reasonable task. The performance, though, was complete shit compared to Java RMI and Corba. Whatever development time you saved initially in writing the SOAP interfacing code was instead spent trying to optimize what you had so that it wouldn't perform so fucking horribly.

In some ways, I hope that Cisco can do better. But I really don't know if that's possible. It may just be the nature of the beast that these sort of technologies perform poorly, are slow to develop, and are often nothing more than a huge hassle.

I think the problem with all of these is that they consist of too much hype and too little sense. Also, a lot of them are horribly over-engineered.Taking SOAP as an example, because that's the one I know best. What you need is some way to communicate data to another party. What you get is something that does that, but in about the most verbose and latency-sensitive way imaginable. Yes, it's standards-based, which is a Good Thing, and it's human-readable, which is also advantageous.

Just what the world needs! Another remote procedure protocol!
Maybe Unix RPC, Corba, XML-RPC, SOAP, DCOM, DCOP and XPCOM were not enough already?
Seriously, the problem in this space is that:

Rather than working together on one RPC protocol that might not be 100% suitable for all uses, people just get the hump and start their own. Hello? These things are supposed to be interoperable! How does starting thousands of incompatible protocols achieve this?

Might be, but you are totally off-topic here. This article is about doing this [wikipedia.org] ober network, which has nothing to do with Instant Messaging, save for the fact that some information transfer is involved.
IIRC, there are things like XEP-0072, that allow for application data messaging over XMPP, but these are also not exactly of interest to most Jabber users, and if they require server extensions, well, you'll be out of luck with using "popular services" }the public ones?] to transfer such data.

Releasing the implementation library under a LGPL license will still allow for the functionality to be incorporated ( via dynamic linking ) into any proprietary product. The LGPL will insure the availability of the source code and downstream legal reuse rights of Cisco's implementation to downstream recipients.

The LGPL is the only license that will insure that at least that Cisco's implementation of the protocol can not be easily extended in an inoperative manner.

Given the timespan that Cisco expects the protocol to be in use, version 3 of the LGPL is the best option.

Sod the libraries, license them however you wish - give us full and unfettered access to the specifications so those of us that wish to produce a BSD licensed or Public Domain set of libraries can do so. Don't assume that any license you choose for the libraries today will be good enough for everyone tomorrow.

A purely public domain release of the specs will just lead to a repeat of the history of Kerberos. See Kerberos, PACs And Microsoft's Dirty Tricks [slashdot.org], along with almost every other protocol that Microsoft chooses to "extend" in an inoperable manner and lock out via both trade secret and incompatible patent licensing schemes.

So? That's called 'Freedom'. I'd rather have too much of it than too little.

No you wouldn't. You really, really wouldn't. Too much freedom means a pointless, uninteresting existence in which nothing you do has any real meaning. Too much freedom means an endless cycle of asking yourself "So now what?", again and again until the end of your life. Too much freedom means nothing will ever get done, because everyone else is using their over-supply of freedom to do things their way and arguing with anyone who disagrees with their way of doing things (sound familiar? There's a lot

So, are you currently in a communist or extreme socialist country? If not, when are you planning to move? I personally disagree with your end statement. I'd rather have no idea of what to do with potential to do anything, than have someone limit what I can do based on their agendas and purposes.

A test suite wouldn't have helped. Win2k worked just fine with normal kerberos as a client and as a server [microsoft.com]. The problem was that if you wanted to deal with domain based groups you needed an extension, something that MSFT wasn't intrested in letting people have for free.

The LGPL is the only license that will insure that at least that Cisco's implementation of the protocol can not be easily extended in an [interoperable] manner.Given the timespan that Cisco expects the protocol to be in use, version 3 of the LGPL is the best option.

Actually I don't see how it will do any such thing. People who get the code are free to implement whatever non-interoperable extensions they want as long as they publish the code. And Cisco will almost certainly not choose v3 of the LGPL, consi

Other than license, how does this compare to ZeroCs Iceï¼Y Does anybody know? I've played with Ice before and it's very well done, although I remain to be convinced of the value of remote object references in a distributed system.

I bet the test transactions were trivial, so the performance numbers would be dominated by the speed of parsing, validating, and dispatching the message.Not saying that SOAP is the best solution. It is XML-based, which everyone realizes is a mixed bag. In particular, validating XML parsers have to be huge to cope with the specification bloat. But why should everyone rush to accept such a fundamental infrastructure piece from a single vendor? Any messaging scheme based on the old TLV (tag, length, value

Can someone explain how 900 calls generating 50,000 messages/15,000 transactions is better than what SOAP does? I'm not terribly familiar with how SOAP works, so please excuse my ignorance, but it seems to me that 2 messages per synchronous call and 1 for an async call would not only be ideal, but fairly straight-forward.

Way to go !Most people just don't RTFA, but you skipped a percentage of the words in the summary too !"In a testbed environment where SOAP was managing around 900 calls a second, Etch generated more than 50,000 messages in a one-way mode, and 15,000 transactions with a full round-trip"15000 > 900Now do you see ?

Most people just don't RTFA, but you skipped a percentage of the words in the summary too !"In a testbed environment where SOAP was managing around 900 calls a second, Etch generated more than 50,000 messages in a one-way mode, and 15,000 transactions with a full round-trip"

Flaming the GP isn't correct in this case, the summary is ambiguous. There is a difference between managing calls and generating messages, as a single call can generate multiple messages.

A correct summary would have been to compare the amount of calls a second both SOAP and Etch can handle, or the amount of messages/transactions required for a fixed number of calls. But I think the PR-drone that wrote up the article did so knowingly to put SOAP in a bad light.

Now do you see ?Actually, yes I do. It was, I suppose, the way it was worded, that made it confusing for me.

My mis-interpretation was that where SOAP was making 900 calls, etch was generating 50,000 messages or 15,000 transactions from those 900 calls. The comparison, unless you really understand the mechanics underneath and what transactions vs. messages vs. calls means, seems very apples and oranges...

I guess it would have made a lot more sense to say, "where SOAP was managing 900 calls a second, Etch wa

Indeed, I do not count the proprietary forks of pieces of open source software released on a not protective enough licence with "added closed and proprietary value" in them. The risk is to make the open source version crippled for proper use on purpose compared to proprietary forks.
The companies or people using such naughty tricks are not a issue with the enforcement of fairness through the GPL licence: if you use a GPL piece of software, the GPL guaranties that any modifications, if distributed, remains u

Unfortunately, (and even if this is not true, but perception makes it so) if you use some GPL code in your project, your project must be released under the GPL.So commercial projects do not use GPL code at all, never, ever ever. Which is a shame as some of it is very good:)

Now, if there was a licence that said "all the code in this package is GPL, if you use any of it you're bound to releases any changes you make to the code in this package only. Linked/compiled/merged/etc etc code that you add to it does

That is exactly what GPL intends to prevent - proprietary software companies making profit from code released as free software. If you want to profit from code, write your own instead of convincing others to let you profit from their code. Or you can use LGPL libraries so that you can still profit from your code, while others can also benefit from changes you made to their code.

That is exactly what GPL intends to prevent - proprietary software companies making profit from code released as free software.

No it isn't. The intent of the GPL is that the user of a piece of software should have the freedom to use, modify and/or redistribute it as he/she wants. Nothing stops you from charging money for - and making a profit from - GPL'd software. Red Hat - for example - make money every day from selling GPL'd code.

Is making money on GPL'd code perhaps *different* from making money of of

Now, if there was a licence that said "all the code in this package is GPL, if you use any of it you're bound to releases any changes you make to the code in this package only. Linked/compiled/merged/etc etc code that you add to it does not need to be re-released, only changes to the code you received", then you would see a huge uptake in OSS code in commercial projects, they'd be happy to use it, and you'd be happy to see improvements released back, and users would be happy because we'd be reusing tons of code.

Isn't that essentially what the LGPL is? As long as you leave some separate.so file that a user can build from some open source release and drop into your system, are your obligations to the LGPL not being met?

Otherwise no closed-source software for Linux would exist because you couldn't legally link to bloody printf, Mozilla, xanim, and several other seminal multimedia products for Linux would never have been, and we'd be no further along than the HURD.

Now, if there was a licence that said "all the code in this package is GPL, if you use any of it you're bound to releases any changes you make to the code in this package only. Linked/compiled/merged/etc etc code that you add to it does not need to be re-released, only changes to the code you received",

That's basically what the LGPL is about. If you want to add code but not release it you just make it a separate library.

Is for them to finally document the extensions that are using to IPSEC. If you don't have Windows and the Cisco router is using firewall requirements, then only MS-Windows is capable of connecting. This is not implemented for other platforms - at least this what I found with Linux and MacOS X. The guys working on vpnc [uni-kl.de] are almost doing a better job with their client, but they still need more information to add the firewall compatibility.

What is interesting is that there are many natural compounds available now. The drug companies spend a lot of money attempting to copy nature. They try to come up with a slight alteration that allows them to patent a "new" molecule that achieves the same effect as a natural compound.

Common sense would have us just use the natural compounds but the Medical Industry is not interested because of the low profit margins.

Here is a collection of easy to read technical articles and the related chemistry on a

I don't know about _anyone_ but it seems to be on right ballpark - measured! Also, the difference in memory usage seems to be huge - not as much but almost. And the code - using intelligent, configuration based build and delivery of messages only needs one common API to build a message, one common API to send a message and one event entry point to receive a message, always looks same, no playing with arguments, flags, whatever. And, of course, language, platform and communication/transport method agnostic,

Facebook has already done the initial work on Thrift, and lots of people are contributing. It's also already in the Apache Incubator on its was to becoming a full Apache project.
So, why would I want to use Cisco's solution over Thrift?