[Sussex] Distros
Geoffrey J. Teale
gteale at cmedltd.com
Tue Apr 5 10:43:45 UTC 2005
Paul Tansom <paul at aptanet.com> writes:
> I thought that was precisely in the spirit of the GPL. The GPL provides
> the ability to take and modify a piece of software to suit your purposes
> should it not already do so - so long as you share your modifications
> with everyone in the same manner. Thus if an application has features
> you don't need and lacks some you do causing you to modify it, it is in
> the spirit of the GPL (and the letter) for you to share that work (I
> believe that for your own use and nobody others you may stick within the
> letter to keep it to yourself, but that is clearly not within the
> spirit). Should you wish to continue to maintain your work then there
> will be future updates that also need to be published - either mirroring
> changes within the original work, taking updates of the original work
> and re-applying your changes, or updates directly of your own. Trying to
> do this from within the original project that did not require or want
> the changes in the first place is not practical and likely to cause
> aggravation, so publishing independently is the only option. Should the
> modified version be a significant modification it is likely to take a
> new name for clarity rather than play on the name of the original
> project unfairly. At no point in this process have I advocated
> deliberately taking the work and creating a new project for the sake of
> it, or failing to credit the original project and authors.
But this is exactly what you suggested with regard to the GFDL. The
invariant sections of a GFDL document are not just anything they are
key points about the legal use of the software and the documentation.
> OK, I think I'm going to have to go back and read some of the thread
> again and/or the GFDL specification itself.
Please do read the GFDL, it isn't very long. You can find it here:
http://www.fsf.org/licensing/licenses/fdl.html/view?searchterm=GFDL
---%<-----
>
> OK, that bit I've obviously missed, so the resulting project could have
> a cover with the invariant cover text:
>
> "This is the documentation for Project A"
>
> and a new invariant section:
>
> "This is not in fact the documentation for Project A as stated below,
> but for Project B which is a derivative work."
Yes.. or something even better. They key is that it only requires
that someones original material be represented as such. Prose is a
much harder content to legally quantify than code is, this is
a very important condition of the GFDL legally speaking.
> and if they were being really bl**dy minded about licensing:
>
> "The reason for the confusing claim that this is documentation for
> Project A is the fact that the original documentation was published
> under the GFDL and we cannot change the title to something like 'This is
> the documentation for Project B, which is a derivative work of Project
> A' because they put the title in as an invariant section."
>
> OK, being really awkward there, I would hope that people would see sense
> and keep the invariant sections to things like credits and the like, but
> the GFDL does seem flexible enough to create problems, but not flexible
> enough to correct them. That said I think I'm warming to it slightly.
> Originally I could see only commercial uses for it. Still yet to be
> fully convinced though!
See my post to Steve just now. What you can make invariant is very limited.
> Hmm, loosing me again, notable with the section "as long as they
> preserve the title of the Document". I'm back towards the view that this
> is a good document for published works about free software, but not
> suitable for documentation of free software. This should be more closely
> aligned to the license it is published under (taking this to be the GPL
> for arguments sake). Should somebody wish to take GFDL'd documentation
> and use sections of it within the inline documentation for a project you
> run into license clashes and the requirement to get the documentation
> authors approval to do so (hopefully not too difficult since they should
> be closely related to the project).
It seems odd that you would insert long sections of prose into
software, but yes this is an issue.
> My intention was not to describe the GFDL as proprietary, but to compare
> some of its restrictions as heading down the path towards some of the
> limitations of a proprietary license.
Yup. But the GPL can be compared to the BSD license in this way as well.
--
Geoff Teale
CMed Technology - gteale at cmedresearch.com
Free Software Foundation - tealeg at member.fsf.org
/^\v/^\v/^\v/^\v/^\v/^\v/^\v/^\v/^\v/^\v/^\v/^\v/^\v/
More information about the Sussex
mailing list