Closed Bug 28828 Opened 25 years ago Closed 19 years ago

Need license for documentation

Categories

(mozilla.org :: Miscellaneous, task, P3)

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 296278

People

(Reporter: rudman, Assigned: mitchell)

References

Details

We need to develop a license for documentation on mozilla.org. One possibility 
is the Open Publication License. 

Ideally (at least in my opinion), the docs could be rolled into a book, once 
proper credit is given. We shouldn't adopt a license that restricts this.

For a discussion of open source doc licensing issues, see the Open Source 
Writers Group doc at 
http://www.oswg.org/oswg-nightly/oswg/en_US.ISO_8859-1/articles/OSWG-Licensing-P
olicy/oswg-licensing-policy/t1.html.
Status: NEW → ASSIGNED
Here's a link to the Linux Doc Project license: 
http://www.linuxdoc.org/COPYRIGHT.html.

I'll provide links to others if that helps.
*** Bug 19028 has been marked as a duplicate of this bug. ***
Mitchell, any update? I have a few docs to post, but I'm hesitant in view of the 
lack of a license. Maybe I'm being too cautious? Still, I wouldn't want the lack 
of a license to haunt us (or me) down the road.

I'm not aware of any major open-source effort that doesn't explicitly apply a 
license to the docs. 
You're absolutely right about the need for a license.  I just haven't been able 
to muster the time, and haven't found an appropriate outside resource to help 
with this.  I'll go to work on the latter right now; being pressed has caused me 
to think up some new ideas for getting help on this ....
What is wrong with the Free Documentation License 
(http://www.fsf.org/copyleft/fdl.txt) or the Open Publication License 
(http://opencontent.org/openpub/) with Section VI removed?

BTW, the Open Source Writers Group link is broken.
Thanks for the suggestions.

The Free Doc License seems too tied to the GNU Public License, and my sense is 
that there are too many stipulations in the FDL. I'm not crazy about it as a 
license for mozilla.

The OPL seems appropriate for mozilla, with Option B of Section VI removed.

The link to the OSWG is broken because of the lengthy URL and line break---but 
the URL works if you copy and paste it into the Location field.
Mitchell, how can we move this forward? Note the 5/28 posting by Sean Richardson 
in the Documentation newsgroup, in which he says, "Any progress on specifying an 
appropriate open source licence for documentation
and on creating a doc coordination page? I've created a tutorial on how to 
screen out duplicate bugs for those who
are not yet fully familiar with Bugzilla and bug-handling ettiquette
( http://bugzilla.mozilla.org/show_bug.cgi?id=30978 ) which, with some adaption,

would be useable for other open-source projects using Bugzilla. By preference,
I'd like to release it under an open content licence of some sort while
contributing it to mozilla.org, if such a licence is ready to use."

I recommend the Open Publication License for mozilla docs---see the previous two 
comments in this bug report. Can we use that as a baseline to move forward? Who 
would you get as an "outside resource" to help resolve this? I'm happy to work 
with whoever---I can at least specify the license for 10 different open-source 
doc efforts, which can help us (whoever that is) figure out what works and what 
doesn't. If we need to decide by committee what license works for mozilla, let's 
try at least to determine who is on the committee ASAP---the lack of license is 
a significant blocker bug.
OK, 2 comments.

First, I've got a good lead on someone to help with the licensing issues; hope to 
have this settled next week.  I need a lawyer to help with this, and think I have 
found one. 
Second, there has been a request in the n.p.m. license newsgroup to revise the 
MPL to include documentation.  so we ought think about this option as well.
The MPL doesn't make much sense for use with dosumentation--it's too software-
specific (this is why GNU uses the FDL instead of the GPL for docs as well). 
The GNU FDL seems good enough to me (then again, IANAL).

The only reason the MPL was used instead of the LGPL for the Mozilla codebase 
was because of some technical problems with linking to non-GPLed code. There 
are no equivalent issues with documentation, AFAIK.
That's one of the thing I want to look out -- what would be required to make the 
MPL useful for documentation?  And would this be awkward in terms of 
technicalities of copyright law?  I've found someone with a good legal background 
to help work through some of the issues.  He and I will start tomorrow (tuesday).  
Once he's a bit more up to speed, we can start posting thoughts and moving the 
discussion/decision forward.  
But why? Why would we *need* a version of the MPL for documentation? Mozilla 
probably would have used the LGPL if it hadn't been for a few dependencies (at 
that time) on proprietary code--e.g. integration with then-not-legally-
exportable RSA code. There are no such dependencies in the documentation.

There are already a couple of perfectly useable open-documentation licenses 
available to choose from. I don't see the point of adding yet another to the 
heap...just check out http://www.fsf.org/philosophy/license-list.html to see 
how confusing the issues surrounding the licensing of open source software have 
become (ignore the judgemental comments by the FSF and just comb through the 
list and compare). Do we really want this to happen to open documentation 
licensing too?

Why reinvent the wheel?
I want to consider using the MPL for documentation; several people have asked, 
and we ought consider whether one license can work for the entire project.

we may decide no, we ought use another license.  hopefully an existing one.  the 
question is how close any of the existing licenses come to what we want.  for 
example, my understanding is that one common license has a bunch of restrictions 
on changing the documentation.  maybe we want that, maybe we don't.  If we don't 
want it, maybe we should just live with what we don't like in order to use an 
existing license.  maybe we shouldn't live with things that don't work well for 
us.

that's the set of questions to figure out.
Steve

early in this bug you offered to provide links to other docs.  Can you do so?  
That would help us get started quickly.
One small point that might be important: formatting of the disclaimer.

Quoting from http://www.mozilla.org/MPL/MPL-1.0-annotated-fs.html
  >Required Legalese [Section 7]
  >These last sections of the License are the inevitable legal
  >statements. Where they are in CAPS, we are not
  >shouting, but are required to write these sections in capital
  >letters by law. 

Checking the licenses mentioned above quickly, none of them have their
disclaimer sections in ALL CAPS. I'd assume that the MPL, like other
software licenses, uses CAPS because the disclaimer is not considered
binding in some jurisdictions if it is not in CAPS.

IANAL, but I could see someone arguing that regardless of the license
for software, they could take legal action based on something stupid
they did because of something they (thought they) read in some docs,
if the disclaimer were not enforcable, by referring only to the 
documentation license in the action. 

In any case, seeing the quoted text in the annotated MPL raised the question.
the
Blocks: 148038

*** This bug has been marked as a duplicate of 296278 ***
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.