Hi all, IANAL, I understand the GFDL has controversal issues http://people.debian.org/~srivasta/Position_Statement.html but also see some uses for carefuly applied invariant sections that should not prevent forking, like the list of conributors, or see below.
And isn't verbatim quoting a different matter, not subject to the explicit licence? Is quoting the spec-doc in other documents or source comments an issue? The copyright conclusions I drew for now: For standards the copyright of the specification document, of the reference implementation, and any usage restrictions of the spec (patents) are all different decisions: I would guess you don't want to restrict the use of your spec by claiming patents. (Others may be able to claim some anyway as long as patents are not considered illegal.) A free standard should include a free reference implementation. The question is if the effort should be a give-away for plunder. By choosing that the reference implementation not only is free, but also stays free (copyleft), it could contribute to and be part of comunity efforts, and, at the same time, serve as a reference for proprietary "software products". This way proprietary and free business models compete on their own terms, with the advantage to the propritary software vendor with open access to specs and reference source code without a price tag for artificial scarcity. For the specification document though, you don't need nor want to put it in the public domain just yet. You do not want to grant a oportunity to have the standard picked up, made proprietary, buffed up with some obscure patented extensions, etc. that easily. Share the copyright with those that respect the same. Allow the freedom to code their own or to collaborate to all. Deny enclosing for all. Copyleft immunizes your work, and the work from those that chose to collaborated work. It does not infect others. It gives you you the same handle when you encounter ungranted uses like enclosing your work, that proprietray vendors use to ensure their artifical monopoly to distribute their software. With the LGPL you prepare your work to also be a free meal proprietary software vendors/competitors can have as lunch. This may make sense in some circumstances, i.e. to gain momentum where proprietary solutions are already wide spread and/or available low priced, or in cases like libc. For most projects and new specs though, the GPL seems a sound choice: Consider a GFDL spec document that invariantly points to a GPLed reference implementation. Everybody is allowed to check out the docs and code reference. Any distributed enhancement to the published spec has to be submitted again to change the official spec. And the enhancement will need to be available in the free reference implementation to realy resemble the spec. Free projects can link the reference implementation. Proprietary software vendors would actually need to write their proprietary code themselves, with freebe reference though. By implementing proprietary extensions it is not possible to change the official spec nor to officially use official reference. A LGPL reference would allow proprietary vendors to advertise using the official reference and at the same time introduce incompatible proprietary extensions. With an official GPL reference, proprietary software can to claim to adhere to the open and free spec-document, change it... decently free of course, or start from scratch and enclose it from scratch, just as everybody else. :) Regards, Christian _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
