![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to patent.doc CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GPL Stacker compression] / dmsdos / doc|
Return to patent.doc CVS log | Up to [GPL Stacker compression] / dmsdos / doc |
1.1 root 1:
2: Concerning the relationship between dmsdos and patents I keep receiving mail
3: like this one...
4:
5: > In article <[email protected]> you wrote:
6: > : dmsdos 0.9.0 has just been released. It supports read and write access to
7: > : compressed dos filesystems [...]
8: >
9: > I think you should make sure no patents are violated. I am afraid that you
10: > MUST get permission to distribute your code. I wish it was impossible
11: > to get a software patent, but unfortunately companies do receive these
12: > patents. There are many patents in encryption and compression technology!
13: > [...]
14: > Again, I wish it was possible/legal to write a free variant for every
15: > existing commercial variant. Unfortunately it is not always possible.
16:
17: Let me say some gereral things about this. The patent problem is indeed as
18: old as the first dmsdos version, which was released approximately three
19: years ago.
20:
21: First, please allow me to correct some statements that are not litterally
22: written above, but that sound like a misunderstanding. Dmsdos is not a
23: "free variant" of an "existing commercial variant". Even both "free" and
24: "variant" are wrong. Dmsdos is not free, but copyrighted and distributed
25: under the GPL.
26:
27: Dmsdos also is not a "variant" of some commercially available software
28: package. It is just a tool that makes it possible to read from and write
29: to some variants of compressed dos filesystems. Dmsdos is surely not a
30: filesystem compression software package like stacker and doublespace, as
31: such a package needs a lot of more software e.g. all kinds of creation and
32: maintainance tools. I know it would be nice to have them under Linux, but
33: I won't write them for well known reasons.
34:
35: If you follow the dmsdos history, i.e. the dmsdos documentation of older
36: releases, there have always been some comments on the possibility of patent
37: problems mentioned in the documentation, and thus some features users liked
38: to have in dmsdos were not implemented. Not because I knew they are
39: forbidden by patent but because I thought they *might* be covered by a
40: patent.
41:
42: Yes, I did contact the respective companies (no need to say which ones :) )
43: for legal issues and, of course, I asked whether they were willing to help
44: developing the code by providing documentation about their filesystem.
45: So what? When I really had luck and got an answer, it was of no value. A
46: stripped down version of one answer was published once in the dmsdos
47: documentation. I removed the name of the company and the name of the person
48: since I didn't want to blame one person. But I wanted to show the level
49: of interest of these companies - on the one hand in support and cooperation,
50: and on the other hand in a Linux version of their code. It was absolutely
51: zero.
52:
53: So I did my own research. It was surely not exhaustive. Patents are things
54: for lawyers, but I'm not a lawyer myself and I don't have the money to
55: get a bunch of lawyers study all the software patents concerning data
56: compression. Furthermore, I don't earn any penny with dmsdos.
57:
58: It lead to the result that there are a lot of patented compression
59: algorithms. Also the compression algorithms that the original dos software
60: uses for filesystem compression are covered by patents. So what. Dmsdos
61: doesn't use them. Dmsdos was developed without official documentation, and
62: it turned out that its compression algorithm even reached a higher
63: compression ratio (but was much slower).
64:
65: I still tried to contact the companies, rarely, but it became more and more
66: boring. I must admit that I gave it up some time ago. I also must admit
67: that I didn't add all the patent problem related stuff to the dmsdos
68: documentation when I rewrote it some day. I considered it simply dead.
69: This implies that some features are still missing in dmsdos and will
70: probably never be added because I don't just want to be exposed to the
71: risk of violating a software patent and provoking a company owning it.
72: The community of dmsdos users on the net seem to have accepted this.
73:
74: I also must say that dmsdos is not at all fully my own work. I just happen
75: to maintain the code currently, and I'm not doing this on my own. The
76: documentation used to implement dmsdos came from a lot of people on the
77: net and even from a previous sample implementation(*) that was released under
78: the GPL. If you know the GPL you also know that it has a very restrictive
79: patent section, so I considered this quite safe.
80:
81: In fact, the compression and decompression routines in dmsdos are something
82: like a collection of parts of free or GPL'd software. Most of them have
83: meanwhile been rewritten from scratch for better performance. They use very
84: common compression techniques. And you don't receive a patent for something
85: that is well known. You can receive a patent, e.g. for a special, highly
86: optimized algorithm, but, let me repeat this, dmsdos does not use any
87: patented compression algorithms.
88:
89: So what can I do? Just throw away the dmsdos code and remove it from
90: the servers? This is like a snail going back into its house and staying
91: there though nothing is happening outside. Just continue trying to contact
92: the companies? I'm bored by their answers if I happen to get one. Sorry.
93: Just giving dmsdos maintainance into the hand of someone else? Heh. That
94: would solve the problem probably for me, but not for others.
95:
96: If you just happen to know more about the patent situation than me, please
97: let me know.
98:
99:
100: (*) ftp://sunsite.unc.edu/pub/Linux/system/Filesystems/dosfs/thsfs.tgz
101: written 1994 by Thomas Scheuermann (current email address unknown)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.