What to Protect in Open Source Software 96
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?"
The same as with anything (Score:5, Insightful)
protect the trademark and expect forks (Score:1)
I've been involved in more than one project where the original code w
Re: (Score:2)
Duh, (Score:5, Interesting)
Re: (Score:2)
That said, given the way Centos has been taking off lately, I'm pretty sure the value of a Brand for things people aren't paying for will be shown to be fairly low. Certainly, if you're reaching people who's only knowledge of the product is the name and image then a brand is a big deal... but in technical and/or OSS circles, not so much.
Re: (Score:1)
Re:Repeat After Me (Score:4, Funny)
Err, what? (Score:5, Insightful)
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...
Re:Err, what? (Score:5, Insightful)
Re: (Score:3, Insightful)
Re:Err, what? (Score:5, Insightful)
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: "
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).
Re: (Score:3, Insightful)
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: (Score:1)
Re: (Score:2)
I think the argument is that it's less likely that an established, profitable company will go splat than some hobbiest group will simply tire of the work and go and do something else instead.
Re: (Score:2, Interesting)
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)
Re: (Score:1)
Re: (Score:2)
Re: (Score:3, Insightful)
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.
Re: (Score:2)
There, fixed that for ya
-mcgrew
PS: Your sig- I'm so old I was a beta tester for dirt. They never did get all the bugs out.
Re: (Score:2)
Or sign your releases, like Debian does (not per-package signing, like RPM-based distros usually do).
Comment removed (Score:4, Interesting)
Re: (Score:2)
And remember, what's really being protected is the user's ability to differentiate your official product from other people's similar products. Trademarks are not at all counter to the goal of free software.
Why "protect" it? (Score:5, Insightful)
Re: (Score:2)
Personally I think that the best line of defense for any open source project is constant innovation and a good (nice & big) community.
Those will do the job of keeping your project alive, well and un-forked much better than any other measure you can think off.
Cheers,
Matt
Re: (Score:2)
I don't see that. OK, CentOS, white box linux from RHEL, but I can't call that a fork, which would imply taking the code in a new direction, not just stripping out some branding.
The only serious forks I've seen have been in the security space--vulnerability scanners and such. As a security guy, that hits close to home. But still, that's a very small piece of the puzzle, in the overall scheme of things. If you were to include innumerable small PH
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Fork... the nightmare of the OSS developer.. (Score:4, Insightful)
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
Re:Fork... the nightmare of the OSS developer.. (Score:4, Interesting)
Re: (Score:2)
It is interesting that you mention Apache when discussing the alleged fear of forks, as Apache is itself a fork of the NCSA httpd. The name Apache even stems from "A Patchy Server", in that Apache initially was distributed as a set of patches for the NCSA httpd.
Re: (Score:3, Interesting)
Forking is.... (Score:2)
LedgerSMB is a rare fork because we are still around 1+ years later. This occurred only because the community was, as a whole, dissatisfied with the way SQL
Re: (Score:1)
Freedom immigrants vs freedom natives (Score:5, Insightful)
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.
Re: (Score:3, Funny)
Re: (Score:2)
Your "freedom immigrants" sound like MySQL AB
Re: (Score:3, Interesting)
Some very complicated products require training (e.g., Oracle) to use properly. However, once trained nothing further is required other than using the product.
Re: (Score:3, Interesting)
Re: (Score:2)
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.
Great in theory, doesn't work in practice though. Any program that gets beyond very simple functionality needs support of one kind or another.
A shovel can work for decades without any servicing. But a digger needs a service every now and then, and active attention to lubricant levels and wear and tear on various components. Which would you prefer to use to dig the foundations of an office block with?
Re: (Score:2)
Re: (Score:3, Interesting)
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
Re: (Score:2)
no protection against forks except excellence (Score:4, Interesting)
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.
Re: (Score:3, Interesting)
Re: (Score:2)
That's one of Linus Torvalds strengths. He's a genuinely nice guy, but not a pushover, and he's got strong opinions and passions but (except for a few blind spots) is entirely able to keep them under control. So Linux is responsive but focussed, and thus doesn't get forked.
I would have to disagree that the way to trump a fork is always to do something bigger and better. Sometimes you may just need to find the 20% of the extra
That's really disgusting (Score:2)
In the ear. With a rake. Sideways.
Re: (Score:2)
Of course, when they get caught with their fingers in the cookie jar, as an OpenBSD got caught importing the GPL licensed Broadcom drivers and refused to cooperate with dual licensing, they can get quite upset about anyone *else* not simply handing over their toys to put in the
Why is that discusting? (Score:2)
Note that all my code is released FOSS, and I actively promote projects where my business is not the only vendor.
I do find the principle of one entity controlling development for financial gain to be distasteful. Hence the protection is to ensure that one has a broader core team which represents a more diverse set of interests.
No. (Score:5, Insightful)
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 (Score:3, Insightful)
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.
It's very important to protect... (Score:5, Funny)
Re: (Score:1)
Forks not neccesarily bad (Score:5, Insightful)
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.
Forks as negotiations... (Score:2)
Re: (Score:2)
Exactly. And I'd point to two of the more famous forks (or potential forks): the GCC/EGCS split, and the threatened XFree86 split resulting from the X11 license change. Both were the result of the project owners not doing what users wanted or needed, and both in the end resulted in changes on the part of the project owners that benefited the users.
Knife the Fork -- Listen to Users (Score:5, Insightful)
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: (Score:3, Insightful)
Re: (Score:2)
One thing I do disagree with, however is your contention that an ideal fork would be 50/50. In my world, the best split would be most of the developers in one fork (usually the original) while the ones for whom the new fork is compelling and who do development for the critical elements of the (new) fork go there. That way, you'd end up with maximum cohesiveness for the whole project, and enough people in the new project
Uh? (Score:1)
Re: (Score:2)
Childish? (Score:2)
Why is iceweasel bad?
Do you know the Matt Groening quote about iceweasels? (Have you been reading your
Where's the insult?
It's not schoolyard politics. Debian has a philosophy and criticising them for sticking to it is the childish thing.
Re: (Score:2)
to paraphrase "If we didn't review the code it doesn't get our logo" sounds fair enough to me and not the action of a weasel and does not merit calling people names in a schoolyard fashion.
Re: (Score:2)
Ah well.
Re: (Score:2)
Please. Go research what actually happened, then please tell us all what you think Debian's options were, realistically. The Mozilla Foundation was the one that suddenly said, "you can't use our trademarks anymore".
Re: (Score:2)
sounds like.... (Score:2)
Re: (Score:2)
Just to clear up any misunderstanding, here is the final paragraph from the boss of JBoss in response to the accusations.
"... As a company we are growing rapidly to meet the expert professional services needs of our customers and partners. We want to be role models for open source developers around the w
OSS developers really should secure patent rights (Score:3, Informative)
Maison Fleury glosses over patent protection too glibly. The Open Source Software community has been aware of the threats from software patents [mit.edu] for years, yet has done little more than argue that software should not be patentable. During this time, OSS developers have created countless innovations. Had some of these innovations been patented, software patents would not pose as much of a risk because the OSS community would have powerful leverage. Even the risk from patent trolls would be somewhat mitigated because OSS developers could withhold licenses for key innovations from potential licensors of the patent trolls' technologies, drying up all streams of revenue. OSS would also have greater political leverage because it would be easier for groups like the FSF and the OSI to point to the patents as evidence that OSS spurs innovation, not just high-quality craftsmanship.
Patent protection is known to be expensive. But, a lot of money has been invested in OSS. Some of that money could go to paying the costs of securing and maintaining patent rights for OSS innovations. Furthermore, many law firms encourage pro bono work. The OSS community could probably leverage those free legal hours as easily as it leverages developers' hours. The real obstacle to securing patent protection for OSS is political: OSS developers tend to boycott the entire patent system and hope that it will just go away. Unfortunately, ignoring the value of this form of intellectual property protection is a mistake.
Some of the rights that can be secured through software patents are much better suited to OSS goals than copyrights or trademarks. Some OSS developers try to bend copyright and trademark protection in ways that, if accepted, would be harmful to the OSS community, if not the entire software industry. For example, "[s]ome have claimed that an application program that needs a library for its operation is a derivative work of that library." [digital-law-online.info] This line of thinking would make Gimp for Windows a derivative work of the Win32 API, making Gimp a product that is ultimately owned by Microsoft. Using patent rights to exclude use of a library by non-OSS would produce the desired result of encouraging the development of OSS without distorting copyright law in such a self-destructive manner.
The GNU GPL actively prevents forks (Score:2)
What really prevents forks. (Score:2)
The point of forking is to deal with a project that is going a direction you don't like, or that has an absentee maintainer. The goal of a fork may be to become a new trunk, to create a new project with different goals, or to apply pressure to the trunk to become responsive to your goals. The GPL has little to do with this, and as evidence I'll note that GCC itself has had at least one major fork and a couple of minor ones.
Nobody forks the
giving it away may be better (Score:2)
Protection (Score:1)
Something I suspect Trolltech do with qt.. (Score:4, Insightful)
Litmus Test (Score:2)
Is it possible to maintain control of a project under the GPL or are you constantly faced with forks?
It isn't truly open source until it's been forked.
Mod parent up funny-but-true. (Score:2)
Re: (Score:2)
As far as going that far, that's why it's a litmus test. You might suspect it's testably open source. But a test will tell you if it's true and tested.
Why protect open source software? (Score:2)
If the project is truly open source, then there's nothing to protect it from.