Lutris, Close Source, And The Open Source Community

sohp writes "Back in mid-September Slashdot ran the story "Lutris Closes Enhydra Source" regarding that company's decision to retract its open source licensing terms. Now George C. Hawkins has reconstructed the pre-closed source reality and discusses it at How Lutris betrayed the Open Source Community . Short summary: blaming Sun was a smokescreen. Interesting use of web archive sites, too." There's definitely a lot of strong feelings against Lutris in the linked piece, but there's also a lot of validity as well.

Comments

Another IANAL but :)

[augustz]

But I'd say in all honesty that folks can distribute InstantDB free of charge. If someone tells you something in a form that can be verified somehow, and you base decisions on that in good faith, then there it's not as easy for the company to balk out as it might like to think.

That said, a concerted effort should be made to unsupport InstantDB. Contacting their customers directly can be usefull. I've already started with those that I could identify in a few seconds, and will be making the rounds when I get more info.

These are companies doing business with lutris and folks may want to be cautious doing business with them if they are working with what appears to be a con artist:

room33
indiqu
gravityrock.com
paremus
rarefire technologies
i-engineering.com
inet6/inetsys
mobiltee
eApps
eSavio

Lutris is also laying off employee's, sending the following email:

I am disappointed to inform you that you will be in the group of 35 employees being laid off
tomorrow. Sometime in the next half hour, a company executive will bring you a packet of
information for you to read this evening. Once you have received this packet, please take
the remainder of the day off. You must leave your computer here in your cubicle at Lutris.
--

Great to see someone pull together some pretty weasily threads, in the real world these folks would be scum. If someone could list the names of the folks on these threads that were in the weasel dept I'd appreciate that for future reference, you never know where they will turn up again, these scum have a nasty tendency to jump the ships they sink.

Please rember that the above is a rather uninformed opinion based on the information I read on the net, Do your own DD before basing decisions on it of course...

no reason to get upset

[mj6798]

If the open source development was carried out under a reasonable open source license, like BSD, GPL, or LGPL, it doesn't matter if the company wants to take further development private: the open source version continues to be open source, and any enhancements made to the open source version, through feedback or contributions, will continue to be open source.

Furthermore, nobody can make source "closed source" if they don't own it. So, if the open source community made valuable contributions and those became a key part of this software, the company can't make it closed source. The fact that they can suggests to me that few such contributions have come in.

Friends can betray you. But in business, and open source is part of the business world, what matters is contracts and licenses. If business partners violate contracts, you take them to court. Otherwise, if you don't like the license under which a piece of open source software is delivered or accepts contributions, don't use it and don't contribute to it. And if there is a possibility that some open source software with an otherwise OK license goes "closed source", you should keep frequent public mirrors of the open source versions so that open source development can continue when the need arises.

There are plenty of pieces of software that are semi-open where I have said "no thanks" (I won't name names, but I have complained about them enough on /.). I suggest others pay a little more attention to licenses as well before investing their time and effort in using or enhancing other people's software.

Can someone explain the dependence on Sun code?

[The Pim]

Plenty of free software implements proprietary standards (Mesa, Lesstif, all the *nix utilities in GNU, really). This has typically not been a legal problem, so I don't understand why implementing J2EE might be a legal problem. Perhaps someone can enlighten me.

My understanding is that J2EE comes from Sun in basicall three parts: specification and other documentation in natural language; the Java API; and a sample implementation. I think these parts are fairly distinct. I want to know which of these is the "problem".

Obviously, every implementor must make use of the documentation. Normally, this does not taint an implementation, but Lutris claims that "reading the specification for J2EE forces the reader to agree to the SCSL". The J2EE specification license I can find doesn't say that. Though it is fairly restrictive, it doesn't seem to prohibit a free implementation. So is the specification a problem or not?

The JBoss response says that JBoss uses "seven jars" from Sun. I'm guessing these jars define the API, ie, they consist entirely of interfaces, abstract classes, and (maybe) trivial classes. Is this necessary? Most free implementations of proprietary API's include their own header files as free software. Does Sun claim a copyright on the API itself? What is the legal status of such claims, since there is basically only one way to express an API? Or did JBoss simply choose not to write their own versions?

Finally, does Enterprise Enhydra use essentially the same Sun classes as JBoss, or do they borrow some of the sample implementation as well? Do they claim that their commercial nature, or some pre-existing agreement with Sun, makes their situation different?

Thanks if you can untangle this.

JBoss won

[protected]

I've been using JBoss for over a year now. It's full featured, is very fast, has a small footprint, and is just generally a brilliant piece of work. Enhydra Enterprise was a long-term vaporware effort -- at least until recently. There were alphas and betas for over a year, but it just never seemed to become ready.

In addition, JBoss is elegant. It is modular and based on JMX. You can plug in new modules and your own code ridiculously easily. JBoss also requires no assembly/deployment phase for EJBs. It's just brilliant.

JBoss has a very active, dedicated bunch of J2EE gurus building it and answering questions in its forums and on mailing lists. The development activity on JBoss seems very high, and the users and developers are very accessible. Enhydra's forums always seemed stale and not very helpful. To me, it has always looked like all of the best people were working on JBoss while Enhydra was just sort of sitting there.

We use JBoss as our main J2EE development platform and deploy either on JBoss or one of the commercial J2EE servers. JBoss starts up fast, hot deploys web applications, EJBs, and connector resources with lightning speed. It comes with standard, easy integration to Tomcat. We're very happy with it.

I think JBoss just won. I also happen to think it would be a great addition to any standard Linux distribution... but that might be offtopic.