michelle olson wrote: > Roland Mainz wrote: > >> Michelle.Olson at Sun.COM wrote: >> [CC:'ing Bonnie Corwin <Bonnie.Corwin at sun.com> to take a look at the >> legal stuff...]
See comments inline below. >> >> >>> Roland Mainz wrote On 06/19/07 05:11 PM,: >>> >>> >>>> [The issue came up on IRC today - again... and I have been asked to >>>> forward it to this forum to ask for an official answer and possibly a >>>> roadmap which leads to a solution] >>>> >>>> Why is Solaris still shipping troff manual pages which are build from >>>> DocBook manpages instead of shipping the DocBook manual pages itself ? >>>> >>>> IMO these "intermediate" troff manpage files do not make much sense >>>> (except that you don't have to ship the DTDs etc.) except that the >>>> current situation blocks other contributors from doing their work (for >>>> example we had a talented contributor who was willing to translate the >>>> ksh93 manual page to japanese using the japanese DocBook sources for >>>> ksh(1) as basis - but the DocBook sources were never released even >>>> after >>>> the promise in >>>> http://mail.opensolaris.org/pipermail/docs-discuss/2006-April/000375.html >>>> >>>> ... and after waiting more than six month she finally gave up and >>>> helped >>>> other projects (or short: The problem scared another contributor >>>> away... >>>> ;-( )). >>>> >>>> Now... a year later... nothing has changed (and there is still no >>>> /usr/man/ja_JP.UTF-8/sman1/ksh.1) ... >>>> >>> >>> Thanks for bringing this question to the docs forum, much appreciated. >>> We are on a path to providing XML sources, the roadmap is here: >>> http://opensolaris.org/os/community/documentation/docroadmapr2 >>> >>> Source for ksh.1 >>> >> >> >> Note my request was the japanese version of ksh(1) - the idea was to use >> the file and it's _markup_ as basis for a japanese translation of >> ksh93(1). >> > > Right, I know this must be disappointing, but it does present the > opportunity you describe below WRT splitting up the new page. We'll just > have to use the markup for one of the other 4k man pages that we *can* > open source. There must be a page that would be useful as a good example > and that will provide the markup template we need. I did speak with the > lead on our translated Japanese man page files last night about timing > for open source of those files, so we are planning together to meet your > needs as quickly as we possibly can. > >> >> >>> will not be delivered for legal reasons. >>> >> >> >> What are the exact legal reasons in this case ? > > I can't discuss that. Thanks for copying Bonnie, she's intimate with > these cases and has helped us with all of the process steps. If there is > something we can say, she will. > >> You're shipping (at >> least with B48) nroff versions of the ksh(1) for both english and >> japanese. > > What we ship with Solaris is not licensed under CDDL. That is the > difference. > >> Where is the legal difference in this case - AFAIK the >> SolBook/SGML version is just a different format of the _same_ text... >> why does a different format change the legal status (if that's right... >> > > No, it is not to do with format at all, it is to do with the license. > >> what would happen if someone converts the SolBook/SGML to DocBook/XML - >> would the DocBook/XML version be "free" ? (Disclaimer: I am not a >> lawyer...)) ? >> >> > > Right, me neither, so I cannot answer this hypothetical. As Michelle pointed out, it's not about the format, it's about the license. The pages shipped with the Solaris product releases are not licensed for people to modify or re-distribute. The licenses on the Solaris product releases are RTU licenses (right to use). Wrt ksh man pages, we can not publish the English ksh man page using the CDDL. We suspected the same would be true of the Japanese page, but the last I heard, analysis was not complete. I wouldn't count on any Solaris ksh man pages being available licensed with the CDDL. Bonnie > >>> That page will >>> need to be rewritten along with about ~700 other pages. I published that >>> list recently, let me know if you missed it and I'll give you a pointer. >>> >> >> >> Mhhh... slightly offtopic: >> If you are going to rewrite the ksh(1) manual page please split it into >> a sh(4) manual page describing the POSIX shell syntax (currently this is >> all packed into one manual page making it difficult to seperate korn >> shell extensions from the POSIX shell syntax itself) and a ksh(1) manual >> page (and maybe it's not a good idea to re-write ksh(1) since it may be >> go away and gets replaced with ksh93(1) (e.g. following the migration of >> /usr/bin/ksh to ksh93)). >> > > Indeed, and let's talk about 'we' here. If we rewrite the page, how > should we proceed? :) I think you have the right idea here, that ksh93 > replaces ksh and we should work on development of the man pages for > ksh93 together. We want to help however we can. > >> >> >>> To you, maybe the nroff makes no sense, but it is just the first step, >>> and it is focused on licensing--we must do that first. Next step is >>> >> >> >> Correct me if I am wrong... long ago (may be Solaris 7) Solaris was >> shipping almost all manpages in the SolBook/SGML format - but the change >> was later reverted. Why isn't it possible to revert that change again >> and ship the SolBook/SGML files for now like Solaris 7 did ? >> > > Thank for this input, I'm sure that you are right about this history. We > have discussed it internally. I believe that at a high-level, we went > back to nroff delivery for quality reasons, because we could better > predict the output being highest quality if we delivered nroff. Dennis > will know if I'm remembering this conversation correctly and the reasons > we went back to nroff delivery. > > Our constant concern has been that providing the SolBook SGML to you > would not be useful because there are not good & free tools available > for SGML editing and processing. And, in particular processing to nroff. > But, feel free to tell me if this is not the case and we'll adjust our > plans accordingly. > >> >> >>> about large-scale collaboration and that is when we'll grapple with >>> format. >>> >>> We are on target to make the next steps toward the XML sources, but we >>> must first address the gate split. We follow ON, so when they go, we >>> will go soon after. >>> >> >> >> What do you mean with "gate split" ? >> > > Well, because of those ~700 files we cannot deliver to opensolaris, we > must split the man page gate before we move it to opensolaris, so we can > keep those pages internal. Does that make sense? > > Thanks, > Michelle > >> >> >>> Hope this helps, please review the roadmap and let me know what you >>> think!! >>> >> >> >> Ok... >> >> ---- >> >> Bye, >> Roland >> >> > >
