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?"

Comments

The same as with anything

[andy666]

You protect anything that is truly new and creative. Which is rare in most technology.

Err, what?

[Penguinisto]

By the by - RedHat has had the same stance: you trademark the name and logos, no problem. That protects your name.

Otherwise... protect it from what? If somebody swipes the code and locks it down under proprietary license, you can go after them for violating copyright terms. Otherwise, the whole stinkin' point of Open Source is to share the code. Can the author of TFA say "duh" for us?

If what you're licensing as open source code is covered by software patents (blecch), then it's already covered under patent law.

If you're that worried about distribution, do what RH and nearly every other distro maker does - have official mirrors. Anything outside of that and you don't have to take responsibility for it.

Otherwise, unless you fully grok what it is you're getting into by doing so, maybe you shouldn't open the license on your source code? This ain't rocket science here...

/P

Re:Err, what?

[webmaster404]

Exactly, and if they are so worried about forking, make the code good in the first place. Other then ports and the like, most forks are caused by bad leadership or poor maintenance of the code. And also, a word to all potential "open source" businesses, if your code is open and not-proprietary and you let the community contribute and such you will succeed, if your just trying to make a Windows-like OS and sell it for $45 at a retailer with some proprietary things mixed in, chances are your going to fail. Only the truly open companies that are in Open Source will triumph otherwise, the hobbyists who collaborate will be better.

Re:Err, what?

[djikster]

RHEL, the major source of income for RedHat, has been distributed for free under the CentOS name. They simply take the RHEL source repository, and build everything, and create a "new" distro. Of course, most of the work is done by RHEL, and they're losing revenue because people don't buy RHEL due to the fact that they can get it for free as CentOS. However, RedHat does not seem to be doing too poorly recently, so I assume most of the money they make comes from support, which is odd, since AFAIK the level of support they give can easily be bypassed by a competent sysadmin.

Re:Err, what?

[Penguinisto]

Of course, most of the work is done by RHEL, and they're losing revenue because people don't buy RHEL due to the fact that they can get it for free as CentOS.

You oughta talk to a CIO some time...

SysAdmin: "Sir, We don't need to buy RHEL subs. We can just use CentOS instead."
CIO: "Okay, and what happens a couple years down the road if the CentOS project goes 'splat' and all our mission-critical stuff is still on it? And how do we know it's exact RHEL code? And what about the apps and bits that only RedHat makes (like certificate tools for instance)? What happens when you're out on vacation or leave for another job, and we gotta get tech support on this thing?"
SysAdmin: "Umm, err, umm..."
CIO: "Who do we rely on if something isn't quite working on the hardware side? You do know that Dell and HP won't even touch an OS or software issue if you're not using an OS that they support, right? And if our Oracle RAC servers starts goofing up, how do we explain to their tech support that we're using an RHEL variant that they simply don't support?"
Sysadmin: " ... "

...you get the idea. It isn't for lack of tech know-how to run the day-to-day stuff that keeps most corporations buying RHEL in spite of CentOS, it's all those nasty little side issues that keep cropping up.

Sure, with a bit of forethought, you can actually get around all the hypotheticals I put up there. Problem is, it'll eat more time and energy to do so than to simply use something that the hardware and app makers support - and invalidating support (either by warranty or contract) is going to be seen as wasteful by the PHB's - cost savings in subs-not-bought be damned.

Personally and professionally, I like CentOS. I squeeze it in wherever there's a need for a non-mission-critical Linux server, and the hardware isn't still under warranty or service contract. This way I save the beancounters some dough but still fill the needs as they arise.

OTOH, there are perfectly real reasons why RH makes so much dough off of RHEL (same with SuSE).

/P

Re:Err, what?

[dbIII]

I squeeze it in wherever there's a need for a non-mission-critical Linux server

Personally I prefer not to have mission critical servers if I can help it. If you have a few machines for some other purpose, have the software installed so things can switch roles and enough disk capacity for copies on different servers then losing any single server doesn't slow you down much.

Re:Err, what?

[allcar]

Also, Red Hat has by allowing Cent OS has gained much more respect as a business
I'm not sure what you mean by "allowing". The license allows Cent OS to do what they do, not Red Hat. This is a triumph for the whole OS system, not one particular company.

Why "protect" it?

[webmaster404]

Why even "protect" it? First off, the most you should do is trademark your name or possibly your logo, the problem is, if you have a large enough base of people using your software, and you go out of your way to make it "protected" chances are someone is going to fork it into a more free version such as what happed with Firefox and Debian. As for forks, very, very, very few people are going to fork your code unless either there is a leadership disagreement, your work is not free enough, there is serious problems with the code or it is unmaintained, those are just about the only cases where it actually "forks" now if it is big enough of a project, there is going to be forks, however probably 80% die out within the first year and the 20% that remains are either lagging behind the main version or have very limited appeal. People will be quick to point out such things such as Cent OS and Red Hat Linux, however Cent OS is aimed for hobbyists or small businesses who don't need commercial support. Red Hat sells support, not Red Hat Linux. So moral to this post is, don't over "protect" your work, its no big deal if someone forks it, in Open Source, may the best code win.

Fork... the nightmare of the OSS developer..

[xtracto]

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?"

FORK!! FORK!! there, run scared... haha

It is really funny how open source developers are so afraid of a fork. It seems that it would be the worst thing that can happen to their precious software/idea... imagine some forking Linux and making it so good that Linus does not matter any more? or what about apache, or any other project.

Recently, I was in a talk given by the founder of Moodle, and when asked which where the treats of his project, he named, maybe competitors, lack of interest and almost as if he did not want do acknowledge it, with a very weak voice, he said "forks".

Of course a fork would mean that the oh great lords and owners of the source (Linus, Theo, Miguel, etc...) would be put aside and they could end as simple coders...

Sorry for the flame :) have a nice day

Freedom immigrants vs freedom natives

[wikinerd]

Free/libre and open-source software is a product of freedom natives, people who regard freedom as a fundamental non-negotiable human value. Many freedom natives have been born in environments where they were in interaction with lots of other freedom natives.

A freedom native will make money with free software by offering great user support.

Now people who believe in control (control freaks) have learnt about the free software community and try to monetise by building upon its spectacular success. But being freedom immigrants, and keep being in interaction with other control freaks, they cannot comprehend how you can make money without using control. They think that the essence of capitalism is to squeeze the customer, lock users in proprietary platforms, etc. Thus, even though they adopt the free software insignia (they may use the GPL and place wikis on their sites), their mindset is still that of a control freak (they use their trademarks abusively, etc). They aren't true freedom natives.

So, a freedom immigrant will try to make money with free software by maintaining a dual-licensing scheme for corporate clients, by maximising as much as possible their grip on their trade marks, by making shadow deals with distributors, etc. And if they succeed to create a cash flow with these methods, their user support may suck.

When I evaluate a free software application for use in my personal and business machines, I try to understand whether it is made by a freedom native or a freedom immigrant. I prefer software written and supported by freedom natives, even if the freedom immigrants use the same licence.

No.

[WestCoastJTF]

Is it possible to maintain control of a project under the GPL or are you constantly faced with forks?

No. It is utterly impossible. That's why Linux and the GNU project had to close up shop.

I didn't see the second blog advocate control

[einhverfr]

over distribution.

However, I think that projects should try to position their official site as the primary point of distribution (i.e. have the project actually manage getting packages for main distros up), and control main distribution points through the project. This doesn't mean you can control secondary distribution points, but it does mean you should try to influence and coordinate the distribution channels so that new updates get pushed out fast.

This is a major issue with licenses like Mr Rosen's OSL and the AGPL. Forced distribution makes it more difficult to protect your trademark and ensure that people are getting the most secure versions from you.

Forks not neccesarily bad

[Todd Knarr]

One of the selling points of open source is, I'm afraid, precisely that the creator doesn't have final control over it. This is what gives users assurance that they'll be able to maintain the software even when the creator's interests diverge from theirs. If adding a particular feature or fixing a particular bug wouldn't be of any benefit to the creator, or worse might actually go counter to the creator's plans for the software, but would be of major benefit to me as a user it's a good thing for me when the creator can't assert control and prevent me from adding that feature or fixing that bug.

Knife the Fork -- Listen to Users

[darkonc]

The only real reason for successful forks is that you're not listening to the users and the developer community. If you're listening to the developers' comments, providing wanted changes and accepting good quality patches, then you're not going to face much in terms of parellel forks.

Ubuntu is an exception that proves the point. It went off in a very different direction than Debian. -- as such, I don't consider it as much a parallel fork as a symbiotic tangent.

Re:Knife the Fork -- Listen to Users

[houghi]

Ubuntu is not an exeption. It is how forks work. At a certain moment you have a large enough user base that different people will see things differently. At that moment one or the other will say, hey we will fork. In an ideal situation this would mean that 50% use the old version and 50%.

It is evolution, one could say. Not forking is the unnatural way. It would mean no diversity. I leave it to the reader as an excersise wether this is a good or bad thing.

A developers community can only listen to so many people at the same time. Some will have opposite interests and conflicting interests.

Something I suspect Trolltech do with qt..

[lpontiac]

Keep your test suites to yourself. That's a significant advantage over anyone else when it comes to maintenance of the codebase.