[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft Boilerplate License




On 3 Oct. Terry Dawson wrote:

David, I think the draft license allows a little too much freedom.

> On  2 Oct, David Lawyer wrote:

>> ***DRAFT*** BOILERPLATE LICENSE (by David Lawyer)
>> -----------------------start-of-draft-----------------------------------
>> 
>> LINUX DOCUMENTATION PROJECT (LDP) BOILERPLATE LICENSE:
>> v0.1, 2 October 1999
>> 
>> Please freely copy and distribute (sell or give away) this document.
>> For corrections and minor changes contact the maintainer.

> I suggest:

> "Forward corrections and minor changes to the document maintainer."
Good.

> I think "derivative work" needs a short explanation. I don't think my
> definition is tight enough, but here it is anyway:

> "A derivative work is one that uses content from this document without
> reference to this document."

"Derivative" is the term used in copyright law and the meaning of it
is in part what case law has "defined" it to mean.  It's not really
using the content in another work since facts are not copyrighted
(even in a copyrighted document with no license).  What is copyrighted
is the expression and organization of the "facts".  Thus one could
gather the facts from one or more copyrighted documents, reorganize
them and express them differently, and copyright law would not be
broken by publication of the new work.  If one used only one source
document for their "facts" they would need to do significant
reorganization (and interpretation) of them so as to keep the results
from being considered derivative.  If one just paraphrases sentences
in the original work (or worse, just copies the sentences) the results
would be a derived work.

It's just too complex to try to define "derivative" in a license.

>> You may create a derivative work and distribute it provided:

>> 1. For a translation, just let the maintainer know about it.

> Again, "translation" is a muddy term. Do you mean translation into
> another language or translation into, say, another format or media?

I mean into another language (and not a mark-up language).  The fix
might be "a translation into a foreign language" which means "foreign"
with respect to the language the doc is written in.  I would consider
a change in format or media to just be a copy since it has the same
content.

>> 2. For a non-translation, discuss it with the maintainer (if it is
>>  being maintained).  If after due deliberation no agreement with the
>>  maintainer can be reached, then you may proceed with the derivative 
>>  work without the maintainer's approval.

> This, I think is a little counter-intuitive. It says that you should
> contact the maintainer if you wish to produce a non-translation
> derivative work, and that if you don't reach agreement with them
> (presumably on the terms/nature of the derivative work) that you can go
> ahead and do it anyway? Why not just allow them without any need to
> contact the 'maintainer' if that is the case. All this seems to do to
> me is to insert a notification to the maintainer, delay, and potential
> for dispute into the process.

> What was the intent here?

The purpose of this is to give the author some control (but not too
much control) over modifying the doc.  It may help prevent forks in
the document.  In most cases, the person who wants to modify the doc
will adhere to many of the suggestions of the author/maintainer.  If
the doc is not being well maintained, then perhaps the current
maintainer will gladly turn it over to the person who wants to modify
it.  Perhaps the current maintainer has some notes, emails, etc. that
would be of use to the modifier.

I think that there needs to be friendly communication between them.
But if the maintainer is unreasonable about the situation, then one
should be allowed to go ahead and modify it anyway.  This provision is
to require them to at least talk to each other.  Would not an author
feel bad if they found out that months ago someone had copied and
modified their doc (and was distributing it) without even so much as
notifying them about it.

>> 3. Send your derivative work to the LDP (or the like) for posting
>>  on the Internet.  If not the LDP, then let the LDP know where it is
>>  available.

> This pretty much limits the scope of this license to the LDP, but that
> isn't a real problem I guess.

>> 4. License the derivative work in the spirit of this license or 
>>  use GPL. 

> "in the spirit of" is a problem. It is exceedingly open to individual
> interpretation as to what the "spirit" of the license was in the first
> place. Here are two suggestions:

> "License the derivative work with this license."

The problem is that too many licenses (including GPL) state just that.
Then it's not possible to merge text from one doc into another.  One
solution would be if everyone used GPL.  But note that GPL says that
GPL may be revised from time to time but the new version will be in
the spirit of the old license.

> or:

> "License the derivative work with any of the LDP approved licenses."
> (presuming we do indeed agree and publish a list of these somewhere)

This will run into the problem of licenses not being interoperable.
Even if we allow one to use a certain license, it may not be a good
one if it prohibits modification (even if the doc is not being
maintained).  The "spirit" of my proposed license does ultimately
allow modification and that feature needs to apply to derived works.


>> 5. Give due credit to previous authors and major contributors.

> I think this needs to be much stronger. It doesn't insist on
> preservation of existing copyright notices. I think any reasonable
> license should do this.

Do you mean that the document should continue to state that it's
copyrighted?  The work is still copyrighted at least by the original
author.  Removing the copyright notice would be going against common
sense.  This would imply that the modification changes are in the
public domain and then the original author could put his copyright on
the work.  Probably, a note to the modifier would get the copyright
notice back in the doc.  The requirement to license the derived doc in
the spirit of the old one seems to imply that the copyright notice
should be retained.

> The whole point of copyright is to assert ownership and control of the
> material.

> There is no point placing a copyright notice on a document if you aren't
> concerned about either of those issues which would make the license
> itself redundant.

> regards
> Terry
		David Lawyer


--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org