On Fri, 2005-10-14 at 19:55 +0100, Charles Moir wrote:
I don't think even most current developers could claim copyright to large sections on Inkscape. I wouldn't even want to try and figure out all the copyright issues in Inkscape.
Ah well that could be a more serious issue. We can't, any more than anyone can really, accept contributions if the copyright is not clear. Too dangerous.
The copyright situation isn't unclear in the sense that we don't have an audit trail of who contributed what in CVS, but it is icky in the sense that most files are a mixture of work by, say, eight or nine individual contributors.
Especially given we don't have current contact information for all of them, and one of the most significant authors is openly hostile to Inkscape, I don't think (for most parts of the Inkscape codebase) any sort of relicensing or dual-licensing of Inkscape code would be possible.
What Bryce meant is that, in the absence of unanimous developer consent, in most cases it would be impossible to usefully extract the work of only the consenting developers.
I think this is the core point, and very well put. It's hugely difficult to see how this can be done. The best I can suggest (and I'm not the first to suggest this) is that we find ways to create shared libraries, tools, palettes, add-ons, whatever.
Yes... I think the key is to focus on developing and improving a common substrate on which Xara and Inkscape both build (and contribute to). Trading code horizontally between the two apps directly is probably not a viable model.
Along those lines...
So why doesn't someone do a sort of Ultra-draw wrapper super-API library thing that we can both use. i.e. it provide one super-set rendering API that itself calls down to XaraDraw, Cairo, Quartz depending on user or program preferences. And then we'd both use this ultra-draw and both gain the desired benefits. Quartz, Cairo and XaraDraw are similar enough to make this not too huge a job I would guess.
I would be reluctant to introduce yet another new API. I've been peripherally involved in the Cairo effort, and have learned that good API design is VERY hard in this area.
However, I suspect XaraDraw doesn't owe its speed so much to the specific rasterization backend as to a "retained-mode" layer which can do caching and optimization of drawing calls?
Cairo pretty much only does rasterization; it provides no retained-mode layer of its own. Inkscape has a retained-mode layer, but it is extremely dumb, and asks the rasterization backend do much more work than it needs to. It's also worth noting that (if I remember correctly) a quartz backend for Cairo exists, used by the OS X port of GTK.
My own feeling is that it would be most beneficial to take Xara's retained-mode layer, target it to Cairo, and then write a new Cairo backend using XaraDraw's lower-level layers (in the long-term, we would also want to investigate merging what we could of the "XaraDraw" Cairo backend into Cairo's normal software backend, assuming you folks were comfortable with relicensing those bits accordingly).
In case Cairo's generic API proved insufficiently rich for everything required by Xara, note that Cairo does allow for backend-specific API extensions. We could simply employ those in the short-term, and it is likely that many could be incorporated into the generic API over time.
Both Inkscape and Xara could then use Xara's retained-mode layer, and both could use Cairo underneath while still taking advantage of Xara's optimized rasterization routines. In the long run all Cairo-based applications (e.g. all GTK and wxGTK applications) would potentially benefit, and Xara could benefit from future third-party improvements to Cairo directly.
That approach would let us stick with two already well-refined APIs, and take advantage of the principle that a rising tide lifts all boats.
-mental