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 un
> 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 to
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 to
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:
https://wiki.gnu.tools/gnu:social-
"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 Assemb
[...] 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 doc
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 g
<#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: a...@g
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 ther
>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
> 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, w
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 archit
> > 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 "
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"
To: a...@gnu.org
Date: Mon, 10 May 2010 10:28:41 -0400
> [...@gnu.o
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 emai
People will always find reasons to complain, but most people (and
companies) seem to be happy with how the copyright assignments look
today.
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
th
> 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
> 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 whe
>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 t
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
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.
> 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
>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
> 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 sai
The FSF copyright assignments grant you back ultimate rights to use
it in anyway you please.
> 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 o
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 app
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?
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?
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 p
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 as
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
> 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.
Please take this up with le...@gnu.org.
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. getXbyY
>> 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
> 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).
> 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.
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.
Is there a reason why both config/gnu.h and config/i386/gnu.h don't
include copyright notices or even the license they are under. Does
that mean they are in the public domain or did someone mess up when
contributing them?
They are (or were) non-trivial enough not to require a copyrigh
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
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 au
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.
53 matches
Mail list logo