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.
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 au
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
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.
<#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
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
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.
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
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.
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
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
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?
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
> 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
The FSF copyright assignments grant you back ultimate rights to use
it in anyway you please.
> 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
>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 t
> 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
> 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
th
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 emai
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
I suggest you raise this with lice...@gnu.org.
> 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
Please move such unconstructive arguments elsewhere.
> > 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 "
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
> 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 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
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
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.
- 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
> 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).
>> 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
> 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.
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
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.
[...] 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
"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
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-
Please move these off-topic discussions somewhere else, people are
already annoyed and angry as it is -- on both sides!
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
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
> 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
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
53 matches
Mail list logo
