yang686526

volunteer wanted to write linux viewer
volunteer wanted to write linux viewer
there is no really good free linux-based dwg viewer. and i think this is a problem.
one reason why this hasn't happened is that the oda's libraries, including dwgdirect, are distributed subject to a membership agreement that works really well for commercial applications and freeware, but that isn't very compatible with typical open source licenses, such as gpl and lgpl. ( the reason for this is that our libraries are not open source. whether they should be is another conversation, for another time.)
another reason is that it's not a trivial bit of coding to create a really good dwg viewer.
there is a linux-based viewer, called lx-viewer, that uses our libraries -- but, if anyone wants to use it, they have to come to us, join as an associate member, get the libraries, and build the viewer. when they get all done, unfortunately, what they end up with is not really a "commercial" quality product.
it's not a great situation.
i'm looking for a volunteer to write a really good linux-based dwg viewer, which can be distributed as open source (without dwgdirect) under the mit (or a similar) license, and as an executable under a shareware/personal-use/no-commercial-redistribution license.
why doesn't the oda do this itself? because we don't compete with our members. we're not in the application software business, and are careful to stick to supplying libraries to people and companies who are in that business. (it's part of being a good, ethical, non-profit organization.)
so, we'd like to work with someone who'd be interested in making a really good free (non-crippleware) linux viewer.
if you think you're up to the task, send me an email, and let's talk about it. there's no money involved, but maybe a little fame. my email is
evan:
i don't have time to this this right now.
but i do have several comments and a question.
first, the ,chm documentation is an awful format, especially for a linux developer. this is, by itself, a barrier.
second, as an occasional developer, who only works with the opendesign libraries when we upgrade versions of acad: it is much harder to understand the dwgdirect libraries than the old viewkit. this is not a complaint, dwgdirect does far more than the viewkit did. but is is orders of magnitude larger and orders of magnitude more complex. witness the perpetual viewport questions, but in general, vectorization is more opaque than it was in the viewkit due to the sheer number of abstractions required.
finally, although the linux desktop is becoming more important, it would be at least as valuable to have open-source conversion filters as a viewer. i suspect that there are more people who need to convert a drawing on-the-fly for presentation on a website or for printing than there are who need a commercial quality viewer.
question: licensing. do you plan to allow linking against dwgdirect and redistribution for a single application, or will the linking and redistribution be available in general? what does personal-use mean? could this be used at a commercial site, or would that be forbidden by the opendesign license? what does commerical-redistribution entail? could the viewer appear on a debian cdrom? what about an ubuntu cdrom? and what about redhat? [actually, i can say what the debian reaction would be: they would not allow this even in non-free, for fear that anyone who sold a copy of their collection could be sued.]
- what format would you like the documentation in?
- the complexity comes from arx compatibility. i don't know that it can be made particularly simpler. (i do think we can do a better job with sample code, though.)
- what formats of conversion filters would be most important?
- we can't do "open source" per se, because of the complexities of licensing. we can, however, do freeware executiables.
- the problem we have is that we're funded by the dues paid by commericial software developers. if we release a freeware package, and commercial developers use it as an end-around-run, to avoid joining the oda, it just messes up our ability to fund continuing development.
documentation. the most neutral format might be pdf. the next most neutral might be openoffice. there is no really good chm viewer for linux. besides,
"microsoft announced some security risks associated with the .chm format, as well as some security bulletins and patches [1]. they have since announced their intentions not to develop the .chm format further, and will be moving to a new generation of windows help in the windows vista operating system."
complexity -- like i said, not a complaint. but it means that the casual developer has a far harder time picking it up.
conversion filters: only two or three matter. postscript, gif or png, and as a remote third svg. although the printing summit announced pdf as the future, postscript can be converted to pdf easily. gif and png are pretty interconvertible. svg gives more functionality, but is not well supported.
licensing -- i understand your problem. i'm pointing out the counter-problem. even if someone writes a (mit/3-clause bsd) viewer, the combination of licensing restrictions that you propose are problematic. debian would not consider this combination a free license -- confilicts with freedom of purpose,
so can't go in contrib. they would read no commerical redistribution as saying that any cdrom on which this tool was placed could not be sold, which may place others in jeopardy, so they would not allow it even in non-free. while other distributions are not as purist, this may be scary enough that even commerical linux distributions might refuse to pick it up.
this pretty much leaves you, or the developer, as the sole distributor. this is hardly better then the lx-viewer situation.
i really understand, and sympathize with your problem. reverse engineering and developing the library has to be a time-consuming and expensive task. but, no open-source true-believer is going to be able to abide by these terms. and without money, i don't really see why any "pragmatist" is going to leap into the breach, particularly not for something this is probably going to require long-term commitment (for support and future versions).
that is, i really don't see how you are going to attract someone to write a complex product using a complex library when the result is so hard to distribute that there is not even much fame to be had.
the only way out i can see is to separate read/vectorize and write capabilities in the libraries, and lessen the licensing terms for the read/vectorize version. perhaps it is still enough value to your financial contributors to support writing.
thinking about license problems.
i think that you really have three very distinct auidences.
one audience is interested only in vectorization. they might be writing filters to graphics formats, or postscript, or they might be writing viewers. in any case, they don't need to know anything at all about the internal structure of the drawing. they just want to know what to draw in some viewport.
a second audience does care about the internal structure of the drawing. they might be writing a cad program, which they would like to be able to read .dwg files and convert to their own internal format; or they might be writing filters that take acad format and convert it to another. this audience cares about the internal structure of the information. for example, a dimension line should be identifiable as such, and often should be treated differently than an edge line.
[a large difference between the first and second audience is the desire for preservation of semantic information. the first audience not only does not care about the semantic carried with a line, they often actively want the semantic information to be lost. for example, they may be willing to give a customer a .gif file precisely because there is some work involved in recreating the file into a cad format; thus the loss of information is actually a positive result to the first audience.]
the third audience wants to write acad files as well as read them.
dwgdirect currently tries to serve all three audiences with a single product and a single license. the first group is actually better served by a different library that is more tightly focussed only on vectorization. and i doubt that there are very many of your commercial members who would have interest in a vectorization-only library.
and, if they have no interest in using such a library, then you would have more freedom to license it in such a way that the resultant combination could be freely redistributed.
and of course, to prove that i am a complete fraud, there are two pieces of semantic information i do care about.
the first is what layer the object being vectorized is in. i need to be able to completely suppress drawing some layers for some users.
the second is textual information. i need to be able to examine and filter text before it is vectorized. by corporate fiat, i am not allowed to show numeric information to some users.