public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dberlin@dberlin.org>
To: Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
Cc: gcc@gcc.gnu.org
Subject: Re: please update the gcj main page
Date: Mon, 01 Aug 2005 03:41:00 -0000	[thread overview]
Message-ID: <1122867666.32467.99.camel@linux.site> (raw)
In-Reply-To: <10508010320.AA14390@vlsi1.ultra.nyu.edu>

On Sun, 2005-07-31 at 23:20 -0400, Richard Kenner wrote:
>     You don't really need copyright assignment (IE you can go along with
>     just licenses) unless you plan on suing people over your documentation,
>     which seems even less likely than suing someone over your code.
> 
> I don't follow.  The issue is that somebody claims that the FSF documentation
> infringes on their copyright and claims that the disclaimers on the Wiki do
> not constitute a contract or license. 

This is barely worth explaining, but;

Such a claim would be ridiculous to press in spite of a clear and
conspicuous notice to the contrary, plus affirmative action on the user
to agree to such a disclaimer, such as clicking a button.  The case law
on this is nowadays enormous.  If you want to go ask another lawyer
whether they'd feel the same way, ask them.  I'm sure they'd give you
the same answer *for these circumstances*.  In general, you don't get to
claim they can't do something when they told you they were going to do
it, you said "okay", and then they did it.
We have verifiable logs that they clicked the submit button, submitting
these changes, on such and such a day, at such and such a time.

As for the rest of your views on documentation, you could have said the
same thing of managing bug reports under GNATS that were fixed or
affected by their code. It was extra work, and a critical part of
development,  yet people often didn't do it.  Did that make people's
code contributions "not very valuable"?  And are you going to disagree
that the problem with that process was not, in fact, the tool being
used?  Make a process use tools that people don't like, and they won't
do it.  You can say they aren't very valuable then, but that doesn't
actually help you get your project where it wants to go.

Your views seem very out of touch with what other projects have found to
be useful in producing good documentation in terms of tools and
processes.


  reply	other threads:[~2005-08-01  3:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-01  3:17 Richard Kenner
2005-08-01  3:41 ` Daniel Berlin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-07-14 17:02 John M. Gabriele
2005-07-15  7:18 ` Ranjit Mathew
2005-07-15 15:21   ` John M. Gabriele
2005-07-15 15:43     ` Bryce McKinlay
2005-07-15 16:47       ` John M. Gabriele
2005-07-15 15:29   ` Bryce McKinlay
2005-07-15 16:39     ` John M. Gabriele
2005-07-15 16:57       ` Andrew Pinski
2005-07-15 20:48     ` Tom Tromey
2005-07-31 22:30       ` Gerald Pfeifer
2005-07-31 23:00         ` Daniel Berlin
2005-07-31 23:02           ` Gerald Pfeifer
2005-07-31 23:17             ` Daniel Berlin
2005-07-31 23:31               ` Gerald Pfeifer
2005-08-01  2:50                 ` Robert Dewar
2005-08-01  3:08                   ` Daniel Berlin
2005-08-23  8:48                 ` Florian Weimer
2005-08-23 16:53                   ` John M. Gabriele
2005-07-31 23:12         ` Joseph S. Myers
2005-07-31 23:19           ` Daniel Berlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1122867666.32467.99.camel@linux.site \
    --to=dberlin@dberlin.org \
    --cc=gcc@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).