Slashdot Mirror
What to Protect in Open Source Software
eldavojohn writes "I found a brief blog by Marc Fleury on something that seems to almost be an oxymoron — what you need to legally protect in Open Source Software. The short of it is that you should trademark your name and brand it. Which might explain Xen's stance on the use of the brand 'Xen'. Another short blog notes that you should also maintain control of your distribution channels. Fleury also states this interesting tidbit on protecting intellectual property in OSS, 'Short of filing patents, there isn't much you can do in OSS. Let's face it the IP is there for everyone to see. If you are in a mode where a lot of the value is the code itself then open sourcing under GPL or equivalent reciprocal license may be a good choice for you. At least you will make sure that ISV's that re-use your license get in contact with you and many of them will pursue dual-licensing, a strategy that is known to work to monetize an OSS user base (mySQL).' Is there anything else you should take measures to protect in open source software? Is it possible to maintain control of a project under the GPL or are you constantly faced with forks?"
Didn't Red Hat already demonstrate this principle, years ago? Hopefully for his sake, they didn't trademark it too, pfft...
pb Reply or e-mail; don't vaguely moderate.
being GPL means, most of all, that there is no protection against forks. after all, GPL _is_ the ability to fork (ignore RMS's politics and all the other noise.)
how do you avoid forks? by being on the right side - everyone pulls in slightly different directions, and any project would be a mess if it accepted all of them. it's also not just a matter of choosing - ideally, if a fork is threatened, the mainstream would trump the fork. that is, instead of some little feature X, develop a bigger, more general thing that is a superset of X. turn the fork into a trivial an unappealing, limited special case. I'm not advocating hyper-featurism, but to embrace big-picture generalizations.
A useful software product needs no "user support". If the user has to call for help, the product is incomprehensible or it fails when the user needs it the most.
Some very complicated products require training (e.g., Oracle) to use properly. However, once trained nothing further is required other than using the product.
The reason they're rightfully afraid of forks is that most of those trying to make a business selling service and support get the majority of service and support because they're the company behind the product. Red Hat gets RHEL support because they're Red Hat and not someone else. If someone forked it off and made a better $foo-Linux, then company $foo would get the service and support. Same goes for those in it for recognition, being the guy "who made some software which another company took over and now everyone associates with them" obviously has a lot less in it than *being* the personified leader, like Linus is to Linux. But yeah, if you're completely neutral towards your baby project, you've got nothing to fear...
Live today, because you never know what tomorrow brings
Novell did the same and went one step further. If you want to make a distribution based on openSUSE, all you need to do is remove the trademarks and such. Now how do you do that? Novell has kindly made rembrand which removes the branding.
That way it is fairly easy to make your own distribution. No need to recompile, unless you want to. If you so desire, you CAN recompile everything and then use makeSUSEdvd to make your ISO.
All the rest of the packages has their own licences and regulations.
Don't fight for your country, if your country does not fight for you.
Your mistake is assuming all users have the interest and are qualified or with short-term training can become qualified to install, maintain or extend this "useful software product." Quite often this is simply not the case. For the vast majority of businesses, IT is a cost center, not a profit center. Businesses will look outside their company for support rather than build up the expertise inside the company. That's why selling support around most any software product above a certain level of complexity, however well designed, can be successful. -- John.
The next level of support means fixing bugs. Perfect software has no bugs, but almost no software is perfect (some is designed using formal methods, but it costs a few orders of magnitude more and so is very rare). Ideally, however, software should contain very few bugs and so fixing them for money is not a viable revenute stream (and if it is, your customers are likely to leave quickly).
The top level of support means adding features. This is where an open source company is best able to make money. They employ the people most familiar with the code and so they have the lowest costs to make changes to it. Very few software packages do exactly what the customer wants out of the box; this is why even closed things like Microsoft Office include scripting languages to add some of the missing features. The kind of support that people are thinking of when they say 'selling support' for Free Software is answering in the phone to people who say 'We are using this program, but we need it to be able to do x, y and z. How much will that cost and how soon can it be done?'
I am TheRaven on Soylent News
Wow. Such nonsense. Let's deal with you:
1) Yum is a single point of failure for RHEL? Your flagrant abuse of IT vocabulary is a single point of failure for your career. The use, or lack of use, of yum will not break a RHEL server -- thus disproving that yum is a single point of failure.
2) multiple CDS/merging? RHEL5 has a DVD ISO available.
3) Lack of NTFS drivers? Why should Red Hat risk incurring copyright/patent issues? To satisfy your need to read from inferior filesystems? I'm glad they don't.
4) Lengthy release time? That's a *FEATURE*, you moron. It's called stability. Real IT shops don't like upgrading their servers every six months, ala Fedora. Real IT shops with hundreds or thousands of servers need stability. They need time to plan their upgrades. Only gurlie men with 3 servers in a bathroom rack want distros released every month. Also, RHEL is supported for SEVEN FREAKING YEARS after release. That's the result of the stability and "lengthy" release time you bitch about.
5) Horrible RHN v/s yum? You just slandered yum by calling it up2date in drag and now you praise it? Make up your mind.
In closing, enjoy your 3 server shop and your CentOS. Keep suckling off the Red Hat teet. Real companies with real business needs will keep Red Hat and indirectly supporting your pathetic career.