Since we incorporated some text from the GNOME Documentation Style Guide (GDSG), we need to update our Doc Guide to attribute the included content covered under the GFDL.
Then we need to decide if we're forking. I think we are. We will have to manually include patches from GDSG. The diff between the two guides will be too great, and will go over time.
However, we need to capture immediately the bug fixes we made so we can get them upstream, before they get lost and our reasoning gets stale. Paul, can you dig out from SVN what you did previously? We'll add that to the fixes I made and you made in cvs.fedora and split up the list to file bug reports.
Now, on to the fun stuff ...
Today I read the GFDL again, read some opinions from debian-legal, and did some thinking. Here is what I have so far.
http://www.gnu.org/licenses/fdl.txt
## We need to take an action to comply with this:
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
## We need to create/modify History, with that title :/
I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
## After some digging, here is one of those canonical pages:
http://developer.gnome.org/documents/style-guide/titlepage.html
## The whole thing with "Exactly Named Pages" is a little strange. The ## GDSG doesn't have a link from the ToC on index.html to ## titlepage.html.
## The following action is to make sure there is a page, on or linked ## from the "History" page, that tells how to get the source for the ## document.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
## We need to redo the organization a bit, I think we all like the way ## GNOME doc prefaces are laid out. We can start by creating a History ## etc. to fulfill licensing agreements.
K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
## Beginning to wonder if we need an appendix to cover some of this ## stuff ...
## Here is an important part that tells us exactly what we need to do in ## combining the documents, which is arguably what we did:
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".
####################
One problem I am hearing about occurs if we include the "Acknowledgements" or "Dedication" section, we may greatly reduce the freedom of our document. In this matter I defer to the debian-legal list for all the reasoning. Here is a page that appears to cover all the details:
http://people.debian.org/~srivasta/Position_Statement.html
Because the GDSG doesn't include any Invariants or other immutable content, we are fully free to use it. Similarly, our GFDL is nicely fully free.
Anyway, I don't want to seek legal advice unless we can't find a clear precedent of how to act. It's seeming clear, so far.
cheers - Karsten
Karsten Wade wrote:
One problem I am hearing about occurs if we include the "Acknowledgements" or "Dedication" section, we may greatly reduce the freedom of our document. In this matter I defer to the debian-legal list for all the reasoning. Here is a page that appears to cover all the details:
http://people.debian.org/~srivasta/Position_Statement.html
Because the GDSG doesn't include any Invariants or other immutable content, we are fully free to use it. Similarly, our GFDL is nicely fully free.
Anyway, I don't want to seek legal advice unless we can't find a clear precedent of how to act. It's seeming clear, so far.
cheers - Karsten
Whew!! Boy, that sounds like fun. ;)
So should we be referring to the LDP Author Guide as the preferred document model? At least in the context of new releases.
i.e. "expected" hierarchical structure
http://tldp.org/LDP/LDP-Author-Guide/html/index.html
This guide already provides for compliance with the GFDL, and has been verified by the FSF.
Within section A.1 of the above resource, there are numerous templates for various documentation structures that the editorial team can review for application in fedora-docs.
Thomas
Hi
http://tldp.org/LDP/LDP-Author-Guide/html/index.html
This guide already provides for compliance with the GFDL, and has been verified by the FSF.
Do you mean that the guide itself has been verified by the FSF ?. I dont think so
regards Rahul
Rahul Sundaram wrote:
Hi
http://tldp.org/LDP/LDP-Author-Guide/html/index.html
This guide already provides for compliance with the GFDL, and has been verified by the FSF.
Do you mean that the guide itself has been verified by the FSF ?. I dont think so
regards Rahul
Derivative instances of documentation that follow and/or utilize the standardized document format as provided by the templates in section A.1 of the above stated guide.
Many of the LDP authors are also key individuals of the FSF. If you review the list of authors you will probably notice a few Open Source advocates associated with or recognized representatives of the FSF.
The guide in itself is a mood point(although it probably is itself a derivative of the accepted procedures and/or content from the FSF representatives).
Hi
The guide in itself is a mood point(although it probably is itself a derivative of the accepted procedures and/or content from the FSF representatives).
Emma is the only person actively maintaining the LDP authors guide and is not linked with FSF. In fact, the LDP manifesto doesnt specify modifiability of documents as a license requirement and documents a broad range of non-free software and would likely fail to meet FSF criterias
regards Rahul
Rahul Sundaram wrote:
Hi
The guide in itself is a mood point(although it probably is itself a derivative of the accepted procedures and/or content from the FSF representatives).
Emma is the only person actively maintaining the LDP authors guide and is not linked with FSF. In fact, the LDP manifesto doesnt specify modifiability of documents as a license requirement and documents a broad range of non-free software and would likely fail to meet FSF criterias
regards Rahul
OK .. I had meant the listing of LDP authors located at the following address: http://www.tldp.org/contrib.html
But that matters not. The original point was that the documents currently being developed in the LDP project are highly scrutenized(spelling?) for legal requirements. Thus my point that it may be a good idea to utilize currently existing resources.
From the LDP website: To be accepted into The Linux Documentation Project the document has to be licensed according to either GFDL, Creating Commons or TLDP copyright, for more information please look at the licensing section http://tldp.org/LDP/LDP-Author-Guide/html/doc-licensing.html of the Author Guide.
From section 6.2(licensing section http://tldp.org/LDP/LDP-Author-Guide/html/doc-licensing.html) of LDP Author Guide: We recommend using the GNU Free Documentation License (GFDL) http://www.gnu.org/copyleft/fdl.html, one of the Creative Commons Licenses http://www.creativecommons.org/license, or the LDP license (currently under review).
I don't claim to know the legal ramblings of such. In fact, I feel sorry for Karsten --- that little bit of content posted gave me a headache. ;)
All I know is they have representatives such as ESR reviewing the legal aspects of the document structures being derived from the guide.
That's good enough for me.
If you know of some loophole because of the manifesto; you may want to forward that to ESR or another representative of FSF. I am sure they'd be interested to know of your findings.
Cheers, Thomas
Hi
But that matters not. The original point was that the documents currently being developed in the LDP project are highly scrutenized(spelling?) for legal requirements. Thus my point that it may be a good idea to utilize currently existing resources.
I am the review coordinator for LDP currently and I am pretty sure that these documents are NOT scrutenised at all legally and hence it is a bad idea to follow it. For document authoring and review processes I would completely agree with you
From the LDP website: To be accepted into The Linux Documentation Project the document has to be licensed according to either GFDL, Creating Commons or TLDP copyright, for more information please look at the licensing section http://tldp.org/LDP/LDP-Author-Guide/html/doc-licensing.html of the Author Guide.
From section 6.2(licensing section http://tldp.org/LDP/LDP-Author-Guide/html/doc-licensing.html) of LDP Author Guide: We recommend using the GNU Free Documentation License (GFDL) http://www.gnu.org/copyleft/fdl.html, one of the Creative Commons Licenses http://www.creativecommons.org/license, or the LDP license (currently under review).
The authors guide only suggests these licenses and does not require them. The licensing requirement is specified by the LDP manifesto http://tldp.org/manifesto.html which states that you can create custom licenses and also does not mandate modifiability of documents. The LDP license was also edited in place previously.
All I know is they have representatives such as ESR reviewing the legal aspects of the document structures being derived from the guide.
I am not sure why you believe ESR is involved with the authors guide at all
regards Rahul
Rahul Sundaram wrote:
Hi
But that matters not. The original point was that the documents currently being developed in the LDP project are highly scrutenized(spelling?) for legal requirements. Thus my point that it may be a good idea to utilize currently existing resources.
I am the review coordinator for LDP currently and I am pretty sure that these documents are NOT scrutenised at all legally and hence it is a bad idea to follow it. For document authoring and review processes I would completely agree with you
I am not sure what you mean here. Isn't document authoring using the templates the topic at hand? So new documents are not authored according to the templates?
I was just trying to save everyone alot of legal leg-work and research by utilizing pre-existing accepted templates.
From the LDP website: To be accepted into The Linux Documentation Project the document has to be licensed according to either GFDL, Creating Commons or TLDP copyright, for more information please look at the licensing section http://tldp.org/LDP/LDP-Author-Guide/html/doc-licensing.html of the Author Guide.
From section 6.2(licensing section http://tldp.org/LDP/LDP-Author-Guide/html/doc-licensing.html) of LDP Author Guide: We recommend using the GNU Free Documentation License (GFDL) http://www.gnu.org/copyleft/fdl.html, one of the Creative Commons Licenses http://www.creativecommons.org/license, or the LDP license (currently under review).
The authors guide only suggests these licenses and does not require them. The licensing requirement is specified by the LDP manifesto http://tldp.org/manifesto.html which states that you can create custom licenses and also does not mandate modifiability of documents. The LDP license was also edited in place previously.
Yes, I did notice that it was a recommendation. However, as noted before; LDP states that "The Linux Documentation Project the document has to be licensed according to either GFDL" etc..etc...
So you are saying that the staple linux documentation entity --- LDP ---- is improperly recommending use of the GFDL for documentation authored from their guides templates? If the guides templates do not conform then why do they recommend utilization of the GFDL license? If the templates do conform, which it should given they are recommending utilization of the GFDL; then why not use the templates?
All I know is they have representatives such as ESR reviewing the legal aspects of the document structures being derived from the guide.
I am not sure why you believe ESR is involved with the authors guide at all
regards Rahul
I never meant ESR authored the guides templates, simply that himself and/or others from FSF surely reviewed the derivative documentation of the guide as being in conformance.
Are you saying that they haven't? I was a former adminstrator of linux-howtos before the LDP was formed, and have seen the many legal issues come to light since the LDP was formed. Even when I administered the howtos, legality was an issue. I don't have first-hand knowledge but can only assume that they have done so.
Cheers, Thomas
Hi
I am not sure what you mean here. Isn't document authoring using the templates the topic at hand? So new documents are not authored according to the templates?
Not always. It can save the authors some work by using pre existing templates but its not mandatory
So you are saying that the staple linux documentation entity --- LDP ---- is improperly recommending use of the GFDL for documentation authored from their guides templates?
No. I am saying that the authors guide only recommends these licenses and the LDP manifesto does not mandate them and hence authors can come up with their own custom licenses and using the templates is not required either. There is no technical reason LDP would reject any custom licenses as long as it falls under the licensing requirements specified by the manifesto which is lax
I never meant ESR authored the guides templates, simply that himself and/or others from FSF surely reviewed the derivative documentation of the guide as being in conformance.
I am not aware of this. Any further information regarding this would be appreciated. If a guide has been determined to be in conformance with any license, all subsequent revisions would have to reviewed to make sure of this. I dont think that has happened in LDP
regards Rahul
On Thu, 2005-05-05 at 03:03 -0500, Thomas Jones wrote:
I am not sure what you mean here. Isn't document authoring using the templates the topic at hand? So new documents are not authored according to the templates?
I was just trying to save everyone alot of legal leg-work and research by utilizing pre-existing accepted templates.
I think the difference is that the templates are vetted for clarity in authoring and following the LDP process. This is a vetting that the writers and editors of LDP can do themselves.
It does not sound as if those templates are vetted for legal anything. They probably followed the formula laid out in the GFDL for compliance. It's not that hard, I'm pretty sure I know what we need to do ... okay, well, that's a lie, it's obscure to me what to do, but I'm confident we can figure this out.
Yes, I did notice that it was a recommendation. However, as noted before; LDP states that "The Linux Documentation Project the document has to be licensed according to either GFDL" etc..etc...
I'm just guessing here, but I reckon the FSF would not agree that the CC or incomplete LDP license is equivalent in stature to the GFDL. The fact that they offer three different licenses shows to me a lack of confidence in any one, single license.
So you are saying that the staple linux documentation entity --- LDP ---- is improperly recommending use of the GFDL for documentation authored from their guides templates? If the guides templates do not conform then why do they recommend utilization of the GFDL license? If the templates do conform, which it should given they are recommending utilization of the GFDL; then why not use the templates?
I think we are mixing up fruit here (to mix up metaphors).
It sounds as if the templates conform only to LDP standard of layout and associated licensing. They happen to be covered by the GFDL, but by their own rules, they could change the Author Guide to use the CC or the new LDP license and _still_be_in_conformance_.
Regardless, I think the point is no longer moot. Our docs and procedures are well derived from the giants who have stood here before. The major differences are in the stylesheets. We are already using the LDP format, in general.
<snip from another email>
If you know of some loophole because of the manifesto; you may want to forward that to ESR or another representative of FSF. I am sure they'd be interested to know of your findings.
This one seems to have been well-beaten by Debian. AIUI, docs that use the GFDL and have Invariant Sections or other immutable-by-license content are considered non-free by Debian. The discussions were hot in the middle of 2003 and early in 2004 on debian-legal. I'm only reading about them now. I'm sure the FSF has heard all about it.
- Karsten
Karsten Wade wrote:
On Thu, 2005-05-05 at 03:03 -0500, Thomas Jones wrote:
<snip>
This one seems to have been well-beaten by Debian. AIUI, docs that use the GFDL and have Invariant Sections or other immutable-by-license content are considered non-free by Debian. The discussions were hot in the middle of 2003 and early in 2004 on debian-legal. I'm only reading about them now. I'm sure the FSF has heard all about it.
- Karsten
I digress back to my quiet and unassuming role within the fedora-docs community.
;) Thomas
On Thu, 2005-05-05 at 09:17 -0500, Thomas Jones wrote:
I digress back to my quiet and unassuming role within the fedora-docs community.
Ha! I'll believe that when I see it. :)
Seriously, your input is appreciated. This was why I posted my research, I'm new to the debate around the GFDL. We need to work this out together, so we are comfortable with our approach.
- Karsten
On Wed, 2005-05-04 at 21:54 -0500, Thomas Jones wrote:
So should we be referring to the LDP Author Guide as the preferred document model? At least in the context of new releases.
i.e. "expected" hierarchical structure
Most of these guidelines have been hashed out on fedora-docs-list since 2003, so we do have our own "template." Although not every document we've produced follows the guidelines strictly (thus "guidelines" and not "rules"), every new document has been increasingly compliant. Our Documentation Guide and the new example tutorial will cover our guidelines in exhaustive detail, perhaps even elevating some to the "rule" level, but those have yet to be completed. If you have questions about the document model, for now I'd encourage ou to ask them here on the list, or refer to some of the examples in CVS.
[...snip...]
Within section A.1 of the above resource, there are numerous templates for various documentation structures that the editorial team can review for application in fedora-docs.
The article format has been pretty much beaten into shape, and that provides for (I would guess) over 90% of our projected documents. Certainly for any other formats, I would think the project is open to looking at any existing templates and evaluating how we can make use of them here.