> Someone was asking on IRC (not on #php) why we are
> using GPL as the license for the PHP Manual. I
> answered that it for historical reasons, because when
> the manual was first being written, no license (if
> any) existed for documentation.
>
> Now there are several. I think that it was discussed
> before to look into some other licenses, e.g.: FPL
> (http://www.fsf.org/licenses/licenses.html#FDL), OPL,
> FreeBSD Documentation License, etc.
> (http://www.fsf.org/licenses/license-list.html#DocumentationLicenses)
>
> It might be good to finally decide and update that bit
> in the manual.
>
> Opinions? ideas?
At the march phpdoc meeting in Stuutgart, we proposed a license
for the manual authors. After that Egon volunteered to contact all
of them, and ask them about this proposal. Unfortunately he was
unable to fulfill the promise, so I took the job, and mailed all of
them personnaly, as well as mailed the same mail to [EMAIL PROTECTED]
As far as I can remember, noone replyd from those listed as Authors
of the manual. I don't know why they don't care... Legally we cannot
do anything to change the license without the approval of all authors.
With this manual license change we also proposed that some rules need
to be put in place on how to add new authors, and what small group of
authors will decide in licensing questions, so this absurd situation
never comes up again. As far as I can see none of the guys listed as
Authors are active nowadays. They have contributed a significant
ammount of the manual text, but they are currently not active. That
does not mean, that they should be delisted, but the fact that they
hold every right on the manual (as the copyright says), is, well...,
not too fair to todays contributors like Friedhelm or Philip and many
others.
BTW Hartmut and Sterling volunteered to consult lawyers in Europe and
the US about our new license... :)
A fairly new point is that the PHP function reference book started by
Zak is also under the OPL, and if we go under it, it would be possible
to integrate the book's contents, which would be a very big plus for
our manual.
http://www.amazon.com/exec/obidos/tg/detail/-/073570970X/
[ Cannot find where the open text is, but it's somewhere online ]
Here is the meeting text for reference and discussion. It pretty well
summarizes what we found the best solution...
------
4. License issues
(Note: we can only offer suggestions here, the actual decisions have
to be taken by the current copyright holders which are listed on the
frontpage of the english manual. of these only egon took part in this
meeting. we will write up our suggestions and findings in a proposal
to the current copyright holders)
The current manual license (GPL) doesn't really cover documentation
issues as it's primary focus is on sourcecode only. We compared some
open documentation licenses and found that the OPL including options A
and B fits us best (http://opencontent.org/openpub/). We don't want to
be very restrictive regarding option B, so we'll publish a "permission
granting policy" that will make our decision process regarding 3rd
party publishing transparent.
One thing we still have to check is whether the OPL including both
options is compatible with the debian guidelines, we want to make sure
we are in compliance to them. Another thing is that option B seems to
especially refer to printed material and not other forms of
publications like eBooks, we would like to have general protection
here instead of paper-only restrictions.
And finally we have to check the license and our goals against US and
(at least) European copyright law. Regarding the manual infrastructure
and tools (configure, makefile, stylesheet customizations, scripts
...) we suggest to put them under the PHP License for consistancy
reasons. (we might even consider creating a seperate project for them
as they are usable for other documentation projects and phpGTK and SRM
already do so)
For the future we'd suggest that each substantial contributor keeps
the copyright to his contributions (espec. important for extension
documentation) while we elect a small group of two or three people
that are in charge of copyright related issues like dealing with
option B related requests (copyright & license bitches).
5. Role definitions
We'd like to extend the list of people mentioned in the manual. The
position of names on the list should not only be defined by historical
reasons but also reflect the amount of work put into the project by
current contributors. We do not want to degrade the work done by the
founders of this project, but give the newer contributors a fair
share of fame, blame and shame ;)
------
Goba
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
