But GPL3 has been a good license for GCC; giving up the theoretical ability
to change the license (other than to a later GPL) does not seem like a
significant loss.
That will cause trouble incorperating code or documentation snippets
from the code base into the GCC manual; which is not
> What is the rationale after these changes anyway?
Development of new features for libstdc++ has already moved away from
gcc.gnu.org to avoid the copyright assignment. Other contributors have
expressed a desire to do the same.
>From the GCC mission statement:
- Other components
GCC was created as part of the GNU Project but has grown to operate as
an autonomous project.
That is true for all GNU project.
The GCC Steering Committee has decided to relax the requirement to
assign copyright for all changes to the Free Software Foundation. GCC
will continue
It should remain an acronym, but it should now stand for "GCC Compiler
Collection". That allows the project to be disassociated from the GNU
name while still subtly acknowledging its heritage.
Then it would not longer be GCC. It would be something different.
The whole point of GCC is
Please move these off-topic discussions somewhere else, people are
already annoyed and angry as it is -- on both sides!
These discussions are slightly off topic for gcc@, I'd suggest they
are moved to gnu-misc-discuss@ or some other more suitable list.
To me GNU is people wanting to create a software system that respects
users freedom according to the GNU Social Contract:
"We've always done it this way" is not necessarily a good defence of an
existing practice.
That wasn't the claim, it is how we do it currently, and have been
doing for decades though. If you have concrete suggestions, please
send them to the GNU Advisory Committee.
> Â Â The GNU
[...] That "gnu-stucture" document was written by RMS a couple of
months ago and doesn't represent how the GNU project and its
maintainers have worked for years.
It reflects the same message that has been sent to new GNU maintainers
for the decades. The GNU structure and organization
I ("new moderator") won't recount what happened, it is neither here,
or there, but Mark is presenting a very biased view of what occured,
and also one of the reasons why he no longer is a moderator.
The claims about doxxing, etc, are entierly untrue and unfounded.
A good reason why Richard should be on the SC is to that he does
demonstrates the values of the GNU project, that of the free software
movement and the FSF. GCC is a important project, and having the head
of the GNU project involved -- even if mostly uninvolved in daily
topics, is a ultimately a
<#part type=message/rfc822 disposition=inline raw=t>
X-From-Line: r...@gnu.org Tue Feb 4 23:28:18 2020
Received: from fencepost.gnu.org (fencepost.gnu.org [209.51.188.10])
by localhost (mpop-1.0.28) with POP3
for ; Wed, 05 Feb 2020 00:28:18 +0100
Return-path:
Envelope-to:
Please feel free to share with other groups as appropriate.
The form requires non-free software and Google malware. Please do not
recommend that people share such things on GNU project lists.
- Have them distributed (automake's default). This means that
they will be build in the srcdir, not in the builddir: of
course, this only affects the maintainer, since for a user that
builds the package from a tarball those files should *not* be
rebuilt, hence
So one way to move forward is to effectively have two manuals,
one containing traditional user-written text (GFDL), the other
containing generated text (GPL). If you print it out as a
book, the generated part would just appear as an appendix to
the manual, it's mere
You probably haven't read this thread fully, or you wouldn't imply
that GCC should have an options manual separate from the user's
manual.
I have read the thread in full, and I do not see the problem with
keeping that info in a seperate manual; GCC has so many options for
various
I have read the thread in full, and I do not see the problem with
keeping that info in a seperate manual; GCC has so many options
for various architectures and systems that I think it makes
technical sense to have a Invoking GCC manual.
And what about libstdc++ API docs, which
You are being denied by RMS. He controls the copyright, the SC has
no legal say, and he's stubborn as hell.
When presented with weak arguments, then yes he will be stubborn
but rightly so.
I don't see what the problem is with two manuals, from a users
Please move such unconstructive arguments elsewhere.
Therefore, if I don't have an update soon (within a week or two), I'd
suggest that we operate under the assumption that it will not be
possible to combine GFDL manuals and GPL code in the near future.
I think it should be possible, Emacs does something similar I think.
However,
I suggest you raise this with lice...@gnu.org.
Not sure where to send this, who is responsible for the mail server
for gcc.gnu.org?
--- Start of forwarded message ---
Subject: [gnu.org #572859] [gcc-bugs-h...@gcc.gnu.org: ezmlm warning]
From: Ward Vandewege via RT sysad...@gnu.org
To: a...@gnu.org
Date: Mon, 10 May 2010 10:28:41
And how are potential contributors supposed to know this?
They're really not. The fundamental problem here is that this area of
the law is not only very complicated, but is really all guesswork
since there are few, if any, relevant cases. Moreover, this is an
area of the law
That is more or less what a potentional contributor gets via
email when submitting a patch. I don't see how a web form would
make things different.
True, but I think it would make a significant difference if the web
form could be filled out online without requiring a piece of
As for flexible, it seems clear that the current form is not
sufficiently personalized, which makes it more difficult to get it
signed by an employer.
If you need something specific, you should contact le...@gnu.org.
They are quite flexible, I do not know where people got the idea that
People will always find reasons to complain, but most people (and
companies) seem to be happy with how the copyright assignments look
today.
1) The back-and-forth is too much for casual contributors. If it is
more effort to do the legal work than to submit the first patch,
then they will never submit any patch at all.
Please do not exaggerate, if people have time for threads like these,
then they have time to send a short
Years ago, I was asked to sign one of these documents for some
public domain code I wrote that I never intended to become part
of a FSF project. Someone wanted to turn it a regular GNU
project with a GPL license, configure scripts, a cute acronym and
all that stuff. I said
You are still open to liabilities for your own project, if you
incorporate code that you do not have copyright over, the original
copyright holder can still sue you
That's irrlevent. By signing the FSF's document I'd be doing
nothing to reduce anyone's ability to sue me, I could
If I have the rights to re-license software, and I re-license the
software, why do I not have permission to enforce these rights?
Because you have the permission to re-DISTRIBUTE (not re-LICENSE)
the software and nothing else.
In case of GCC, you have the explicit permission to
Wouldn't contributing a patch to be read by the person who will be
solving the problem, but without transferring of rights, introduce
risk or liability for the FSF and GCC?
That risk always exists; some level of trust has to exist somewhere.
It's unclear whether the LLVM-style implicit copyright assignment
is really enforceable, and this certainly isn't a forum to debate
it. In any case, it doesn't really matter, because the only reason
copyright needs to be assigned (AFAIK) is to change the license.
This is not the only
Given that there are plenty of high-profile projects out there
which seem to be entirely safe in the absence of copyright
assignment policies, why, exactly, does GCC need one to be
legally safe?
I do not know what high-profile projects you are refering to
IANAL but the copyright assignment is probably necessary for the
FSF to have the rights to change the license at will (within the
limitations allowed by the copyright assignment). If there are many
copyright holders, like for say the linux kernel, a change of
license requires the
Not much can be done to either of those, the copyright assignments are
necessary to keep GCC legally safe.
Given that there are plenty of high-profile projects out there
which seem to be entirely safe in the absence of copyright
assignment policies, why, exactly, does GCC need
The FSF copyright assignments grant you back ultimate rights to use
it in anyway you please.
The big reason the copyright assignment. I never even bothered to
read it, but as I don't get anything in return there's no point.
Why should put obligaitons on myself, open myself up to even
unlikely liabilities, just so my patches can merged into the
official source distribution?
I have a script that allows me to do the following in a single step:
gccfarming cleanup
gccfarming bootstrap
gccfarming patch PATCH=mypatch.diff
gccfarming bootstrap
compare_tests clean.log mypatch.log
That seems useful, could you post a copy of it somewhere?
legal reasons. The default disclaimer is nonsense, it is hard to find an
employer willing to sign a sensible disclaimer, and even when you have a
nice employer it can still take months (years?) to get things through the
FSF.
If it takes a long time, please contact r...@gnu.org or
My personal opinion is that this legal reason is a *huge*
bottleneck against external contributions. In particular, because
you need to deal with it *before* submitting any patch, which,
given the complexity (4MLOC) and growth rate (+30% in two years) of
GCC, means in practice that
If the dragonegg and/or LLVM copyright was assigned to the FSF, which
is a prerequisit for anything included in GCC and not what license the
program is under currently, then I'm quite sure that the GCC
maintainers would be more than happy to include both.
Since it is possible to use the 0b prefix to specify a binary
number in GCC/C++, will there be any resistance to add %b format
specifier to the printf family format strings?
You can do that yourself by using the hook facility for printf, see
(libc) Customizing Printf in the GNU C library
Please take this up with le...@gnu.org.
a) discussions of licensing issues are off topic on this mailing list
b) you should ignore all such discussions, since they invariablly
� include lots of legal-sounding opinions from people who are not
� lawyers and don't know, and often have significant misconceptions.
However, I really implore you: by all means link statically to
everything else, but leave libc dynamically linked. I'm not aware
of any reason not to link libc dynamically, and not doing so leads
to a ton of problems.
Problems also arise if one uses functions that use NSS (eg.
I think the mistake is to have them (git hg) hosted on the
same machine as svn. Having them on hg.gcc.gnu.org and
git.gcc.gnu.org would allow to split the load between machines
(even if hg.gcc.gnu.org and git.gcc.gnu.org are the same
machines originally).
This would
I think the mistake is to have them (git hg) hosted on
the same machine as svn. Having them on hg.gcc.gnu.org
and git.gcc.gnu.org would allow to split the load between
machines (even if hg.gcc.gnu.org and git.gcc.gnu.org
are the same machines
Any chance of moving to launchpad.net?
And launchpad.net forces everyone else to remember a new username
and password.
Launchpad is also non-free software.
Fine.. as I said, what's a reasonable forum to discuss this on?
gnu.misc.discuss just doesn't cut it..
gnu-misc-discuss@ is the proper place, just ignore Terekhov.
I'll try to get around it as soon as I can. Thanks.
It has been a month... would be nice if you could look at it soon.
Thanks for poking, I got stuck on a strange bug that causes make to
assert while building the Java bits and I haven't gotten around to
fixing it. I'll try and get
They are (or were) non-trivial enough not to require a copyright
notice.
I obviously mean that they were _trivial_ enough not to require a
copyright notice.
Please read the web page:
http://gcc.gnu.org/contribute.html
This assumes a stable access to the 'net so that such information can
be extracted when one is reading the documentation. Which isn't
always the case for everyone. URL's shouldn't point to important
information of this type in a
Could someone check the bugs that depend on #21824? They have been
pending for several months now with no activity, and it is kinda bad
karma not having GCC working on the GNU system.
Thanks.
The usual process is that you post them to the gcc-patches mailing
list for review. And if they are approved, you can commit then or
you can ask someone to commit them for you. As far as I can tell,
you have never posted the patches. At least, there is no sign of
that in the PR
53 matches
Mail list logo
