Why not contribute? (to GCC)

Why not contribute? (to GCC)

[Manuel López-Ibáñez]

This seems to be the question running around the blogosphere for
several projects. And I would like to ask all people that read this
list but hardly say or do anything.

What reasons keep you from contributing to GCC?

Cheers,

Manuel.

PS: Actually, I am not sure how many people read this list and not contribute.

Re: Why not contribute? (to GCC)

[Paolo Carlini]

On 23/04/10 11.39, Manuel López-Ibáñez wrote:
> PS: Actually, I am not sure how many people read this list and not contribute.
>    
Actually, I would say many, the famous "lurkers". I did that myself for 
some time, then I tried to contribute to the library, successfully, as 
it turned out ;)

Paolo.

Re: Why not contribute? (to GCC)

[Richard Kenner]

I've happened to be looking at a number of other free-software projects
recently (having nothing to do with compilers) and find the quality of the
code ABSOLUTELY APALLING.  The formatting is random and very hard to read.
There are almost no comments.  There are few, if any, indications of what
each function is supposed to do.  And many of these projects have no
documentation AT ALL except for some small FAQs or Wikis.

When we ask "why is contributing to GCC so hard", we must never forget that
a large part of the answer to that question is that we have much higher
STANDARDS than most free-software projects in terms of code quality
and documentation.  I don't believe that lessening those standards to
increase contributions would ever be a good thing in the long term.

Re: Why not contribute? (to GCC)

[Michael Witten]

On Fri, Apr 23, 2010 at 14:10, Richard Kenner
<kenner@vlsi1.ultra.nyu.edu> wrote:
> I've happened to be looking at a number of other free-software projects
> recently (having nothing to do with compilers) and find the quality of the
> code ABSOLUTELY APALLING.  The formatting is random and very hard to read.
> There are almost no comments.  There are few, if any, indications of what
> each function is supposed to do.  And many of these projects have no
> documentation AT ALL except for some small FAQs or Wikis.

Funny. I've always felt the same way about gcc and most GNU codebases...

In fact, I've always felt the same way about the vast majority of
codebases that aren't my own :-D

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 23 April 2010 21:52, Michael Witten <mfwitten@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 14:10, Richard Kenner
> <kenner@vlsi1.ultra.nyu.edu> wrote:
>> I've happened to be looking at a number of other free-software projects
>> recently (having nothing to do with compilers) and find the quality of the
>> code ABSOLUTELY APALLING.  The formatting is random and very hard to read.
>> There are almost no comments.  There are few, if any, indications of what
>> each function is supposed to do.  And many of these projects have no
>> documentation AT ALL except for some small FAQs or Wikis.
>
> Funny. I've always felt the same way about gcc and most GNU codebases...
>
> In fact, I've always felt the same way about the vast majority of
> codebases that aren't my own :-D

Maybe contributing will teach you some team skills and style-tolerance? ;-)

I felt a bit silly writing in GNU style at the beginning, but you get
used to it because it is consistent. Now I can switch more easily
between different styles and I don't feel the urge to rewrite
everything in my style. I guess is like learning different languages.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Michael Witten]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:

>>> I've happened to be looking at a number of other
>>> free-software projects recently (having nothing to
>>> do with compilers) and find the quality of the code
>>> ABSOLUTELY APALLING. The formatting is random and very
>>> hard to read. There are almost no comments. There are
>>> few, if any, indications of what each function is
>>> supposed to do. And many of these projects have no
>>> documentation AT ALL except for some small FAQs or
>>> Wikis.

Michael Witten <mfwitten@gmail.com> wrote:

>> Funny. I've always felt the same way about gcc and most
>> GNU codebases...
>>
>> In fact, I've always felt the same way about the vast
>> majority of codebases that aren't my own :-D

Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:

> Maybe contributing will teach you some team skills and
> style-tolerance? ;-)
>
> I felt a bit silly writing in GNU style at the
> beginning, but you get used to it because it is
> consistent. Now I can switch more easily between
> different styles and I don't feel the urge to rewrite
> everything in my style. I guess is like learning
> different languages.

I can play along fine with different styles (even if I
disagree with most of them); indeed, GNU's style can be
very logical (indenting the braces, for instance, makes
a lot of sense to me---though I don't normally do so).

My main problem is largely with identifier naming and
file/code organization (which *can* involve style via
the use of whitespace). Most people don't put too much
thought into these issues (particularly the matter of
organization), which betrays a lack of appreciation for
abstraction that ultimately taints the design and code
itself.

My rule of thumb: good code is largely self-documenting.

Let me make that statement stronger: If people are
complaining that the documentation for the code is
horrible, then they are essentially complaining that
the code is horrible; it should be trivial:

    [0] to find any definition without grepping or
        using something like ctags.

    [1] to find the highest-level of abstraction
        from which to begin a top-down reading.

    [2] to understand what any block of code is
        doing (this follows from [0] and [1], and
        essentially promotes maintaining the proper
        level of abstraction for each such block).

Following these ideals basically forces a programmer to
write code as though it is meant to be read and understood
by *others*; that's crucial to being able to work within
a team (especially one distributed around the world).

Unfortunately, the signal usually gets lost in the
noise produced by people who don't care as much, and I
call those noisy people "hackers"; the world is full of
hackers---they are great for the short-term but terrible
for the long term.

Sincerely,
Michael Witten

Re: Why not contribute? (to GCC)

[Richard Kenner]

> My rule of thumb: good code is largely self-documenting.

Maybe.  But good code can't give the SPECIFICATIONS of a function,
just it's implementation.  I don't believe there's any substitute
for putting comments in front of a function to say what the function
is SUPPOSED to do.  That's only in the mind of the writer and needs
to be written down.

Also, an important thing to put in comments is WHY something is done
the way it is and (more importantly) why it ISN'T done another way.
No amount of good quality code can contain that information.

>     [2] to understand what any block of code is
>         doing (this follows from [0] and [1], and
>         essentially promotes maintaining the proper
>         level of abstraction for each such block).

You need to understand, what a block of code is doing, what it's supposed
to do, and why it's doing it.  In some cases, the latter two parts are
obvious, but when they're not, there's no substitute for proper comments.

> Following these ideals basically forces a programmer to
> write code as though it is meant to be read and understood
> by *others*; that's crucial to being able to work within
> a team (especially one distributed around the world).

Indeed!

Re: Why not contribute? (to GCC)

[Michael Witten]

On Fri, Apr 23, 2010 at 17:12, Richard Kenner
<kenner@vlsi1.ultra.nyu.edu> wrote:
> I there's no substitute for proper comments.

Oh I agree!

However, I proffer that the need to write a comment is often an
indication for the need to write the code better (and to choose
another programming language).

> good code can't give the SPECIFICATIONS of a function...

This may largely be a sign that the formal language is not expressive
enough; in particular, the language should at least try to support
abstraction formally (hence, binary < assembly < C < C++).

Unfortunately, we still have a long way to go before our formal
languages are capable enough to replace comments significantly.

> Also, an important thing to put in comments is WHY something
> is done the way it is and (more importantly) why it ISN'T done
> another way. No amount of good quality code can contain that
> information.

Indeed!

Re: Why not contribute? (to GCC)

[Denys Vlasenko]

On Friday 23 April 2010 21:10, Richard Kenner wrote:
> I've happened to be looking at a number of other free-software projects
> recently (having nothing to do with compilers) and find the quality of the
> code ABSOLUTELY APALLING.

That's because you didn't look at non-open code. It's no better.

> The formatting is random and very hard to read. 
> There are almost no comments.  There are few, if any, indications of what
> each function is supposed to do.

This is typical for most code, open and closed.

> And many of these projects have no 
> documentation AT ALL except for some small FAQs or Wikis.
> 
> When we ask "why is contributing to GCC so hard", we must never forget that
> a large part of the answer to that question is that we have much higher
> STANDARDS than most free-software projects in terms of code quality
> and documentation.

And such attitude (denial that "we" have any problems) is typical too...

> I don't believe that lessening those standards to 
> increase contributions would ever be a good thing in the long term.

This statement carries an implicit assumption that the only barrier
for contribution to GCC is the "high quality of code required".
This is not true. For one, copyright assignment requirement
is an untypical requirement for open-source world,
and may turn away some contributors.

-- 
vda

Re: Why not contribute? (to GCC)

[Richard Kenner]

> That's because you didn't look at non-open code. It's no better.

Nobody said it was.

> This statement carries an implicit assumption that the only barrier
> for contribution to GCC is the "high quality of code required".
> This is not true. For one, copyright assignment requirement
> is an untypical requirement for open-source world,
> and may turn away some contributors.

I said "A" large part.  There is certainly a perception that the
copyright assignment is an issue too.  But, as was discussed here, there
IDENTICAL liability with and without the assignment.  So this is illusory.
And if the reason for not wanting to assign the copyright is that they
aren't comfortable with the code being part of the project, then there's
a larger problem than the assignment itself.

Re: Why not contribute? (to GCC)

[Olivier Galibert]

On Sun, Apr 25, 2010 at 12:36:46PM -0400, Richard Kenner wrote:
> I said "A" large part.  There is certainly a perception that the
> copyright assignment is an issue too.  But, as was discussed here, there
> IDENTICAL liability with and without the assignment.  So this is illusory.

Oh please.  Asking an entity that has no rights on your code to
actually say they have no rights on your code is not an illusory
requirement.  I realize that work contracts in the US tend towards the
thinly veiled slavery contract, but that's not the case in other
places[1] where, as a consequence, employers have never heard of that
kind of disclaimers and having someone with authority sign them is
close to impossible in large structures.  Finding who that someone
would be (short of the CEO or equivalent) is a challenge by itself.

I know I've decided long ago not to look at FSF code because I may be
tempted to patch it and I can't stand the hassle of the assignment.

  OG.

[1] France in my case, probably Europe in general.  What you do in
your free time is yours by default, land grab clauses are not
accepted, and it's only when you work at home on things you also do at
work that questions can be asked.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> [1] France in my case, probably Europe in general.  What you do in
> your free time is yours by default, land grab clauses are not
> accepted, and it's only when you work at home on things you also do at
> work that questions can be asked.

That's true in the US as well, but the sticky part is when you try to
define such nebulous things as "free time", "company equipment", and
"things you also do at work".  If you're not doing programming at work, you
don't need a disclaimer.  And if you are, then how broadly "things" are
defined becomes potentially relevant.

The point is that although intellectual property law does differ between
countries, it's not simple in ANY of them.  A disclaimer protects not only
the entity the code is being assigned to, but the person submitting the
code.  The only way you can be SURE that a company you work for has no
claim on your code is by asking them to tell you that in writing (if it's
ALREADY in your contract, I'd expect the FSF to accept a copy of that
contract as a disclaimer).  Otherwise, you, as a non-attorney, are doing
what attorneys don't even like doing: trying to guess how a court might
rule on a complex set of facts and the law.

Re: Why not contribute? (to GCC)

[Paolo Bonzini]

On 04/26/2010 07:20 AM, Richard Kenner wrote:
>> [1] France in my case, probably Europe in general.  What you do in
>> your free time is yours by default, land grab clauses are not
>> accepted, and it's only when you work at home on things you also
>> do at work that questions can be asked.
>
> That's true in the US as well, but the sticky part is when you try to
> define such nebulous things as "free time", "company equipment", and
> "things you also do at work".  If you're not doing programming at
> work, you don't need a disclaimer.  And if you are, then how broadly
> "things" are defined becomes potentially relevant.

I would not be surprised if these things were better defined in
Europe. I would not be surprised if they weren't better defined either,
but it's worth trying because in my experience the disclaimer is a much
higher barrier-to-entry than the assignment.

In particular, it is not common to find lawyers that are fluent in US
law in European institutions (if they are fluent in English at all).  In
fact, the FSF would do this half of the world a great favor by making a
list of countries where a disclaimer from the employer is not needed (if
any).  Alternatively, ask the FSF Europe to work on a version in at
least French, German, Italian and Spanish.

And even in the US we lost a patch for 4.5 due to a problem with the
disclaimer.  I read this recently on gcc-patches:

    The FSF has a personal copyright assignment for me, but I could not
    get one from my employer at the time, Stanford (according to
    Stanford's policies they would not claim copyright on this patch).

I suppose that this referred to http://rph.stanford.edu/5-2.html which
shows that the matter is not black-and-white:

    BOOKS, ARTICLES, AND SIMILAR WORKS, INCLUDING UNPATENTABLE SOFTWARE
    In accord with academic tradition, except to the extent set forth in
    this policy, Stanford does not claim ownership to pedagogical,
    scholarly, or artistic works, regardless of their form of
    expression. Such works include those of students created in the
    course of their education, such as dissertations, papers and
    articles. The University claims no ownership of popular nonfiction,
    novels, textbooks, poems, musical compositions, unpatentable
    software, or other works of artistic imagination which are not
    institutional works and did not make significant use of University
    resources or the services of University non-faculty employees
    working within the scope of their employment.

Yet copyright.list has:
- 3 disclaimers from Stanford dating back to 1989
- 10 contributors with a Stanford email, all without a disclaimer

So?

Paolo

Re: Why not contribute? (to GCC)

[Russ Allbery]

Paolo Bonzini <bonzini@gnu.org> writes:

> And even in the US we lost a patch for 4.5 due to a problem with the
> disclaimer.  I read this recently on gcc-patches:

>    The FSF has a personal copyright assignment for me, but I could not
>    get one from my employer at the time, Stanford (according to
>    Stanford's policies they would not claim copyright on this patch).

> I suppose that this referred to http://rph.stanford.edu/5-2.html which
> shows that the matter is not black-and-white:

>    BOOKS, ARTICLES, AND SIMILAR WORKS, INCLUDING UNPATENTABLE SOFTWARE
>    In accord with academic tradition, except to the extent set forth in
>    this policy, Stanford does not claim ownership to pedagogical,
>    scholarly, or artistic works, regardless of their form of
>    expression. Such works include those of students created in the
>    course of their education, such as dissertations, papers and
>    articles. The University claims no ownership of popular nonfiction,
>    novels, textbooks, poems, musical compositions, unpatentable
>    software, or other works of artistic imagination which are not
>    institutional works and did not make significant use of University
>    resources or the services of University non-faculty employees working
>    within the scope of their employment.

At Stanford, if you're on the academic side, Stanford mostly only cares
about patents.  Copyright generally vests in the academic author and the
university doesn't try to claim any copyright on that.

Work done for the university as part of the job of a staff member, such as
my work done during working hours, is of course owned by the university
under the work-for-hire provisions of copyright law and is a whole
different kettle of newts.

> Yet copyright.list has:
> - 3 disclaimers from Stanford dating back to 1989
> - 10 contributors with a Stanford email, all without a disclaimer

> So?

Stanford has a lot of staff as well as faculty and students.  :)
Universities are akin to both large villages and moderate-sized
corporations.  We have multiple significant internal IT departments, and
some of us do significant free software work.  Whether or not you need a
disclaimer given Stanford's copyright policy is going to depend on the
nature of your relationship with the university and the contribution.

The problem, as I alluded to in an earlier message, is that this is all
relatively easily handled under the copyright policy on the academic side
of the house for students and faculty.  But if you're staff doing free
software work as part of your job, finding someone at the university who
will sign the disclaimer is extremely difficult.

I can say from my 15 years of experience working here that in general
Stanford *hates* signing legal documents.  This is true even of
procurement contracts.  Stanford negotiates legalities very aggressively,
negotiates vendor contracts very aggressively, and does not generally sign
things unless the university has some compelling reason to do so.  This
is, from the university perspective, an obviously correct legal position
since it keeps the university out of trouble from documents that they
didn't need to sign.

In order to get a disclaimer signed, the last time I investigated this, I
would need to go through the Office of Technology Licensing because the
central IT staff are probably not people with sufficient authority to sign
such a document on behalf of the university.  All university intellectual
property is handled by the OTL.  And the entire purpose of the OTL is
serve as steward of university property and hence to handle the
university's intellectual property to the university's advantage (mostly
around the income that the university derives from licensing of its patent
portfolio; we hold some patents that came out of the Human Genome Project
work, for example).  They don't have much of an incentive to sign such a
document, and their first concern is going to be how much it might cost
the university to do so.

It's much simpler, from their perspective (and somewhat understandably so)
if I just don't contribute to FSF projects on work time unless there's
some particularly compelling reason for me to do so.  Most of the free
software work I do on university time I release under the copyright of the
university with a free software license; the university is more
comfortable with that than with signing legal agreements with third
parties, at least for things that are not particularly central to the
mission of the university and therefore warrant the time and attention
required to vet the agreement.

This is all a digression, as I don't have anything to contribute at the
moment -- this specific case is not a problem that anyone needs to try to
solve.  I describe it in this much detail just so that people are aware of
the sort of challenges that the policy creates and that contributors need
to work through.

Please also note that much of this information is about ten years old, and
the situation may have changed somewhat.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I can say from my 15 years of experience working here that in general
> Stanford *hates* signing legal documents.  This is true even of
> procurement contracts.  Stanford negotiates legalities very aggressively,
> negotiates vendor contracts very aggressively, and does not generally sign
> things unless the university has some compelling reason to do so.  This
> is, from the university perspective, an obviously correct legal position
> since it keeps the university out of trouble from documents that they
> didn't need to sign.
> 
> In order to get a disclaimer signed, the last time I investigated this, I
> would need to go through the Office of Technology Licensing because the
> central IT staff are probably not people with sufficient authority to sign
> such a document on behalf of the university.  All university intellectual
> property is handled by the OTL.  And the entire purpose of the OTL is
> serve as steward of university property and hence to handle the
> university's intellectual property to the university's advantage (mostly
> around the income that the university derives from licensing of its patent
> portfolio; we hold some patents that came out of the Human Genome Project
> work, for example).  They don't have much of an incentive to sign such a
> document, and their first concern is going to be how much it might cost
> the university to do so.

This is, unfortunately, true for most universities.  The only reason
NYU assigned GNAT to the FSF was because the contract with the Air
Force REQUIRED them to do so.  This is probably the best way to get
these to happen.

Re: Why not contribute? (to GCC)

[Paolo Bonzini]

On 04/27/2010 03:46 AM, Russ Allbery wrote:
> This is all relatively easily handled under the copyright policy on
> the academic side of the house for students and faculty.

Unless it's "institutional work"...  I was in the same boat during my 
own Ph.D. studies, cherrypicking what to send for inclusion into FSF GCC 
and what not.

It just shows that the handling of the disclaimer is not at all
black-and-white and very much left to the whims of the contributor.

BTW, thanks for the detailed answer, I did read it entirely and it was 
very interesting.

Paolo

Re: Why not contribute? (to GCC)

[Дмитрий Дьяченко]

I have no hardware to test patches, small free time to work and my
english is bad.
But sometimes i submit bug reports :)


2010/4/23 Manuel López-Ibáñez <lopezibanez@gmail.com>:
> This seems to be the question running around the blogosphere for
> several projects. And I would like to ask all people that read this
> list but hardly say or do anything.
>
> What reasons keep you from contributing to GCC?
>
> Cheers,
>
> Manuel.
>
> PS: Actually, I am not sure how many people read this list and not contribute.
>

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 23 April 2010 21:24, Дмитрий Дьяченко <dimhen@gmail.com> wrote:
> I have no hardware to test patches, small free time to work and my
> english is bad.

I always test patches in the CompileFarm.http://gcc.gnu.org/wiki/CompileFarm
In fact, I only do development in the CompileFarm. I have a not very
powerful laptop that is already overworked.
I only use linux x86 machines but they have plenty of esoteric
hardware and setups for testers.

I don't have a good answer to the lack of time. I also have very
little free time and the most interesting work is time-consuming.
However, just checking whether an unconfirmed PR is still valid takes
5 minutes. When you get proficient writing patches, the most consuming
task of fixing a bug may be writing the Changelog. (ok ok, for some
very very simple bugs, but they exist!).

If you read up to here your English is good enough. We do not need
Shakespeare writing code. We need good programmers. Good patches talk
by themselves.

> But sometimes i submit bug reports :)

Good! Thanks! Maybe the next step could be checking whether bug
reports are valid or not. ;-)

Manuel.

Re: Why not contribute? (to GCC)

[Joel Sherrill]

On 04/23/2010 02:39 PM, Manuel López-Ibáñez wrote:
> On 23 April 2010 21:24, Дмитрий Дьяченко<dimhen@gmail.com>  wrote:
>    
>> I have no hardware to test patches, small free time to work and my
>> english is bad.
>>      
> I always test patches in the CompileFarm.http://gcc.gnu.org/wiki/CompileFarm
> In fact, I only do development in the CompileFarm. I have a not very
> powerful laptop that is already overworked.
> I only use linux x86 machines but they have plenty of esoteric
> hardware and setups for testers.
>    
I am the maintainer of RTEMS (http://www.rtems.org).  We
do all development cross and run all automated tests on
simulators.  There is a wide variety of free simulators for
the esoteric hardware and all can run on Linux x86.  We
have scripts to help run a lot of the simulators.

I think we have scripts to drive about 20 different simulator
configurations.

> I don't have a good answer to the lack of time. I also have very
> little free time and the most interesting work is time-consuming.
> However, just checking whether an unconfirmed PR is still valid takes
> 5 minutes. When you get proficient writing patches, the most consuming
> task of fixing a bug may be writing the Changelog. (ok ok, for some
> very very simple bugs, but they exist!).
>
>    
This is a very important task.

Also helping ensure the PR is decent to start with is important.
Reminding people to submit preprocessed source that
can be used to reproduce the problem.  Getting them to try
different optimization flags and CPU model settings.  Sometimes
a maintainer will hone right in on the problem if you just give them
enough details up front.

Checking if it worked on a previous major branch.  Say broken
in 4.4.2 but worked in 4.3.3.  Then a binary search can find it.

Personally I don't fix any code generation problems.  But I
try to narrow things down so that someone else can use their
time effectively fixing it, not narrowing the problem space.
> If you read up to here your English is good enough. We do not need
> Shakespeare writing code. We need good programmers. Good patches talk
> by themselves.
>
>    
And don't be afraid when someone finds a simple mistake
in your patch.  I get caught on this all the time.  Forgetting
to update the copyright year, etc.
>> But sometimes i submit bug reports :)
>>      
> Good! Thanks! Maybe the next step could be checking whether bug
> reports are valid or not. ;-)
>
>    
Indeed. :)
> Manuel.
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: Why not contribute? (to GCC)

[Дмитрий Дьяченко]

Thank You, Manual and Joel

I'll try to choose smth appropriate to start.

I am a little confused by the term:
http://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F
"3. AND at least one free software project you are a contributor of. "

I have accepted patches (well, very small and very obvious) into
llvm/clang, pcsclite. And how this may be applied to gcc-devel? I.e.,
how i may answer to Q.3? I have no patches to gcc yet.

Looks as "egg -- chicken" problem?

Sorry for waste Your time with trivial questions.

Thank You.
Dmitry

2010/4/23 Joel Sherrill <joel.sherrill@oarcorp.com>:
> On 04/23/2010 02:39 PM, Manuel López-Ibáñez wrote:
>>
>> On 23 April 2010 21:24, Дмитрий Дьяченко<dimhen@gmail.com>  wrote:
>>
>>>
>>> I have no hardware to test patches, small free time to work and my
>>> english is bad.
>>>
>>
>> I always test patches in the
>> CompileFarm.http://gcc.gnu.org/wiki/CompileFarm
>> In fact, I only do development in the CompileFarm. I have a not very
>> powerful laptop that is already overworked.
>> I only use linux x86 machines but they have plenty of esoteric
>> hardware and setups for testers.
>>
>
> I am the maintainer of RTEMS (http://www.rtems.org).  We
> do all development cross and run all automated tests on
> simulators.  There is a wide variety of free simulators for
> the esoteric hardware and all can run on Linux x86.  We
> have scripts to help run a lot of the simulators.
>
> I think we have scripts to drive about 20 different simulator
> configurations.
>
>> I don't have a good answer to the lack of time. I also have very
>> little free time and the most interesting work is time-consuming.
>> However, just checking whether an unconfirmed PR is still valid takes
>> 5 minutes. When you get proficient writing patches, the most consuming
>> task of fixing a bug may be writing the Changelog. (ok ok, for some
>> very very simple bugs, but they exist!).
>>
>>
>
> This is a very important task.
>
> Also helping ensure the PR is decent to start with is important.
> Reminding people to submit preprocessed source that
> can be used to reproduce the problem.  Getting them to try
> different optimization flags and CPU model settings.  Sometimes
> a maintainer will hone right in on the problem if you just give them
> enough details up front.
>
> Checking if it worked on a previous major branch.  Say broken
> in 4.4.2 but worked in 4.3.3.  Then a binary search can find it.
>
> Personally I don't fix any code generation problems.  But I
> try to narrow things down so that someone else can use their
> time effectively fixing it, not narrowing the problem space.
>>
>> If you read up to here your English is good enough. We do not need
>> Shakespeare writing code. We need good programmers. Good patches talk
>> by themselves.
>>
>>
>
> And don't be afraid when someone finds a simple mistake
> in your patch.  I get caught on this all the time.  Forgetting
> to update the copyright year, etc.
>>>
>>> But sometimes i submit bug reports :)
>>>
>>
>> Good! Thanks! Maybe the next step could be checking whether bug
>> reports are valid or not. ;-)
>>
>>
>
> Indeed. :)
>>
>> Manuel.
>>
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research&  Development
> joel.sherrill@OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>   Support Available             (256) 722-9985
>
>
>

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 17:00, Дмитрий Дьяченко <dimhen@gmail.com> wrote:
> Thank You, Manual and Joel
>
> I'll try to choose smth appropriate to start.
>
> I am a little confused by the term:
> http://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F
> "3. AND at least one free software project you are a contributor of. "

I think it means to say explicitly what you want to do in the compile
farm. I added Laurent Guerby to the CC list. He may have a better
answer.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Joel Sherrill]

Hi,

Taking a slightly different tack on this.  One of the things
we at RTEMS have taken away from Google Summer of Code
is that your project has to be approachable to new users
from your target audiences.  You want to minimize the
barrier to entry for each type of users. For us, this
was experienced embedded developers, students with
no cross development experience, students with no
Linux computer, instructors wanting to use RTEMS in
a class, etc.

I think many of the ideas which have been suggested
are great and needed.  Can we identify different types
of users and what might present them hurdles?  Then
we can identify what would be required to lower those
hurdles.

Then work to give each type of user a roadmap, howto,
getting started, resources, etc. on the wiki.

One thing I like to do periodically with RTEMS is
only answer questions with URLs.  This means that
there was an answer in our knowledge base.  If new
info has to be added, it is a hint.  If the user couldn't
find it, it indicates a problem in the way the information
is presented. This is often just due to language barriers
and not thinking like someone unfamiliar to the project.

This is all under the general umbrella of "making
your project approachable".

--joel

Re: Why not contribute? (to GCC)

[Laurent GUERBY]

On Sat, 2010-04-24 at 19:00 +0400, Дмитрий Дьяченко wrote:
> Thank You, Manual and Joel
> 
> I'll try to choose smth appropriate to start.
> 
> I am a little confused by the term:
> http://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F
> "3. AND at least one free software project you are a contributor of. "
> 
> I have accepted patches (well, very small and very obvious) into
> llvm/clang, pcsclite. And how this may be applied to gcc-devel? I.e.,
> how i may answer to Q.3? I have no patches to gcc yet.
> 
> Looks as "egg -- chicken" problem?

The "GCC Compile Farm" project is open to all free software (1)
contributors and is not limited to GCC contributors.

As part of the application process just mention URLs of
patches, bug reports, etc... you have already contributed to
one or more free software project and what project(s)
you intend to use the compile farm for. If you don't have done any
contribution yet, we also have accepted applications in the past when
sponsored by a developper who qualifies (for example internships).

> Sorry for waste Your time with trivial questions.

Questions are always welcomed :).

Sincerely,

Laurent

(1) http://www.gnu.org/licenses/license-list.html

Re: Why not contribute? (to GCC)

[David Daney]

On 04/23/2010 11:39 AM, Manuel López-Ibáñez wrote:
> This seems to be the question running around the blogosphere for
> several projects. And I would like to ask all people that read this
> list but hardly say or do anything.
>
> What reasons keep you from contributing to GCC?
>

I am going to answer why I think it is, even though I like to think that 
I do do something.


GCC has high standards, so anybody attempting to make a contribution for 
the first time will likely be requested to go through several revisions 
of a patch before it can be accepted.

After having spent considerable effort developing a patch, there can be 
a sense that the merit of a patch is somehow related to the amount of 
effort expended creating it.  Some people don't have a personality well 
suited to accepting criticism of something into which they have put a 
lot of effort.  The result is that in a small number of cases, people 
Bad Mouth GCC saying things like:  The GCC maintainers are a clique of 
elitist idiots that refuse to accept good work from outsiders.

Personally I don't agree with such a view, and I don't think there is 
much that can be done about it.  There will always be Vocal Discontents, 
and trying to accommodate all of them would surly be determental to GCC.

I think that some potential contributors are discouraged from 
contributing because they have been frightened away (by the Vocal 
Discontents mentioned above) before they can get started.


David Daney

Re: Why not contribute? (to GCC)

[Mark Mielke]

Copying David Daney's response to contrast against it:

GCC is a mature piece of software that works really well and it is in a 
programming domain which is not as well understood and for people such 
as myself, I would be intimidated from the start, to delve in and expect 
any contributions I make to be valuable enough to bother the existing 
machine with. :-)

But yes, if I overcame that intimidation, I'm sure David Daney's 
comments would describe the *next* barrier to overcome...

Cheers,
mark


On 04/23/2010 03:33 PM, David Daney wrote:
> On 04/23/2010 11:39 AM, Manuel López-Ibáñez wrote:
>> This seems to be the question running around the blogosphere for
>> several projects. And I would like to ask all people that read this
>> list but hardly say or do anything.
>>
>> What reasons keep you from contributing to GCC?
>>
>
> I am going to answer why I think it is, even though I like to think 
> that I do do something.
>
>
> GCC has high standards, so anybody attempting to make a contribution 
> for the first time will likely be requested to go through several 
> revisions of a patch before it can be accepted.
>
> After having spent considerable effort developing a patch, there can 
> be a sense that the merit of a patch is somehow related to the amount 
> of effort expended creating it.  Some people don't have a personality 
> well suited to accepting criticism of something into which they have 
> put a lot of effort.  The result is that in a small number of cases, 
> people Bad Mouth GCC saying things like:  The GCC maintainers are a 
> clique of elitist idiots that refuse to accept good work from outsiders.
>
> Personally I don't agree with such a view, and I don't think there is 
> much that can be done about it.  There will always be Vocal 
> Discontents, and trying to accommodate all of them would surly be 
> determental to GCC.
>
> I think that some potential contributors are discouraged from 
> contributing because they have been frightened away (by the Vocal 
> Discontents mentioned above) before they can get started.
>
>
> David Daney
>
>
>

Re: Why not contribute? (to GCC)

[Marc Glisse]

On Fri, 23 Apr 2010, Manuel López-Ibáñez wrote:

> This seems to be the question running around the blogosphere for
> several projects. And I would like to ask all people that read this
> list but hardly say or do anything.
>
> What reasons keep you from contributing to GCC?

Not sure we should spam this list even more with such non-technical 
discussions, but since you are asking:

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.

Note that I am not proposing any change. Assignment to the FSF has 
drawbacks, but it also has some advantages. And if things are slow there, 
I am sure they wouldn't mind extra money to hire more people.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 23 April 2010 21:45, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Fri, 23 Apr 2010, Manuel López-Ibáñez wrote:
>
>> This seems to be the question running around the blogosphere for
>> several projects. And I would like to ask all people that read this
>> list but hardly say or do anything.
>>
>> What reasons keep you from contributing to GCC?
>
> Not sure we should spam this list even more with such non-technical
> discussions, but since you are asking:

I think this is an important question for GCC's future, and this is
the main gcc list. If we cannot discuss this here, then where? Please,
keep sending your answers.

> 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.

OK. the default disclaimer is totally nonsense. But in my previous
university, I drafted the disclaimer together with the legal
department, and the FSF just accepted it. The FSF took a few months
yes, but I also took me a few months to get to the point of committing
my first patch, so no big deal. Nowadays, there are SVN and GIT where
you can keep your patches until you get the OK. Hey, you can even get
patches approved without the disclaimer yet!  If you are in a hurry,
you can always insist politely. They will either say they are busy but
aware of it or they will say: Oh, I forgot to send it, it is done!

> Note that I am not proposing any change. Assignment to the FSF has
> drawbacks, but it also has some advantages. And if things are slow there, I
> am sure they wouldn't mind extra money to hire more people.

In any case, I think GCC is an important project for the FSF and if it
is hurting our future, we should ask for some improvements on this
area, and perhaps someone would decide to act. Steering committee?

Anyway, you do not need a disclaimer for contributing documentation,
helping with bugs, analysing where and why GCC is slow and even
programming helper tools. You can even suggest changes that someone
else may implement!

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Basile Starynkevitch]

Marc Glisse wrote:
> On Fri, 23 Apr 2010, Manuel López-Ibáñez wrote:
>>
>> What reasons keep you from contributing to GCC?
> 
> Not sure we should spam this list even more with such non-technical 
> discussions, but since you are asking:
> 
> 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.

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 people won't even start looking seriously inside GCC before getting 
that legal paper. And getting it in big organizations is very hard, 
especially when you need big bosses in suit (that you never meet in 
person) to sign the papers. And convincing these top level bosses to 
sign a paper for an hypothetical patch is much harder than making them 
approve an existing (but non trivial) patch (eg a 6 month work patch).


I even tend to believe that a possible nice side effects of plugins 
would be to change this sad stage of fact. I am imagining that people 
would first contribute their work as a GPLv3 plugin (that they will 
publish outside of GCC, eg on some site, and under the copyright of 
their employer, not of the FSF). Several years later, it could happen 
that a few such plugins may become popular enough to grant interest from 
the GCC community which might perhaps ask the plugin to be incorporated 
inside GCC. In that hypothetical case, getting the legal document signed 
is a bit easier (the big boss knows what actual work & code is 
transfered to the FSF, and would sign a legal paper with less 
apprehension).

 From a technical point of view, plugins also force us to design some 
more stable API, and that fact alone is good. Perhaps in a few years, we 
will even have less than hundred global variables inside GCC!

I also think (knowing that I am in a small minority) that automatic 
memory management (thru garbage collection techniques) is important to 
keep GCC modular (and to increase its modularity). I don't believe it is 
sensible to pretend having a five million lines of code software 
managing complex & circular internal data structures without a garbage 
collector. Again, I do know that most GCC people are against that 
opinion. (and GCC memory management needs are different, and more 
complex because of circularities, than those inside Gnome or KDE or the 
Linux kernel).

I am personally more attached to the FSF ideal of free software than to 
the actual four millions lines of code inside GCC. GCC is mature, and I 
am happy that other free compilers are appearing. Maybe in a dozen years 
the dominant C free compiler won't be GCC anymore. This is software 
evolution, and as long as free software flourish, I am happy with that. 
(I would even dream that in a dozen of years, C, C++, Ada, Fortran - 
i.e. the major languages of GCC - will be less relevant, but this is 
sadly a dream).

Again, all this is my personal opinion. Don't ask me about what my 
employer's opinion is (I don't know). Don't ask me to have any other 
person from my employer contact any one (including the FSF) to suggest 
improvements or changes to the legalese.

And obviously I am *not* a lawyer, of course (and even my employers 
lawyers are more expert on the laws of my country - France - and my 
continent - Europe - that about the US laws, or the Canadian ones).

I do know that the legal system of GCC is nearly impossible to change 
(we all remember how getting the runtime license of GCC compatible with 
plugins took so long) but I believe it is one of the weaknesses of GCC. 
My feeling is that the legalese inside GCC have been defined in a 
different time and world than today!

Any even since I did send patches to GCC since several years, I am still 
scared even now when sending one.

Sorry for spaming the list with such non-technical blabla.

Cheers

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 23 April 2010 23:19, Basile Starynkevitch <basile@starynkevitch.net> wrote:
>
> I do know that the legal system of GCC is nearly impossible to change (we
> all remember how getting the runtime license of GCC compatible with plugins
> took so long) but I believe it is one of the weaknesses of GCC. My feeling
> is that the legalese inside GCC have been defined in a different time and
> world than today!

The legal status is impossible to change and we do not want to change
it. The legal procedures to satisfy that status are a different matter
altogether and we should evolve and improve them. Mixing the two
concepts leads to confusion.

As for the legal status. For me, the GPL is one of the reasons I chose
to contribute to GCC. I wouldn't like to see Apple to take my work,
add some shiny stuff and start distributing it as a closed-source
bonus to its customers. But if the GPL is stopping you from
contributing, then go now because we cannot and we do not want to
change this. But the procedure, I don't see any reason why it could
not improve.

> Any even since I did send patches to GCC since several years, I am still
> scared even now when sending one.

Scared about what? Legal implications? Please clarify.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Basile Starynkevitch]

Manuel López-Ibáñez wrote:
> On 23 April 2010 23:19, Basile Starynkevitch <basile@starynkevitch.net> wrote:
>> I do know that the legal system of GCC is nearly impossible to change (we
>> all remember how getting the runtime license of GCC compatible with plugins
>> took so long) but I believe it is one of the weaknesses of GCC. My feeling
>> is that the legalese inside GCC have been defined in a different time and
>> world than today!
> 

I was referring to the fact that the threat to GCC is today no more from 
Sun (I read a few weeks ago that as a company Sun does not exist today). 
The competition is from other free compilers like LLVM CLANG. And it 
could happen that LLVM + CLANG would continue to exist even if Apple 
disappeared. It could also happen that LLVM + CLANG would supersede GCC.

> The legal status is impossible to change and we do not want to change
> it. The legal procedures to satisfy that status are a different matter
> altogether and we should evolve and improve them. Mixing the two
> concepts leads to confusion.
> 

In my own perception, the legal status of GCC is *not* the GPL. I would 
be very satisfied if GCC was "only" GPLv3+ (like Linux kernel is only 
GPLv2+). But GCC is not only GPLv3, it is in practice FSF copyrighted, 
with (for big organizations like my employer) *unlimited* liability for 
the code they have written (the lawyers at my organization tried to 
explain me that if I legally do bad things, the entire French state 
could be crushed.. by e.g. a patent litigation between Dark Vador & the 
FSF; perhaps there is some trick to avoid that but I did not understood 
it; I do stay skeptical, because I never coded important enough code 
that would matter a lot to others. Remember that I am not a lawyer, and 
I might have understood all wrong. And most of my GCC code don't 
interest a lot of people.). I repeat, what is scary to lawyers is the 
"*unlimited* liability" words of the copyright transfer to FSF. [If the 
legal documents specified a very large, but limited amount, like 
US$100M, I would imagine lawyers would perceive the FSF copyright 
transfer form differently]

I repeat: the legal document employing organizations of contributors 
have to sign (the transfer of copyright to FSF) is *not* the GPL. (And I 
am not sure that document is public, a fact that I personally find 
disturbing from an organization -the FSF- which defends free software....).

And I did met several persons who abandoned the idea of contributing to 
GCC just because of the transfer of copyright to FSF requirement. If the 
set of such persons is large, and if such persons are collectively wise, 
then GCC might have an issue here, unless we consider that the set of 
GCC contributors is large enough and will stay large enough.

Again, my definition of the legal status is what legal document have to 
be signed to contribute to GCC. For me, as employer of CEA, the legal 
document was *not* the GPL.

> As for the legal status. For me, the GPL is one of the reasons I chose
> to contribute to GCC.

I personally definitely agree with that, and I do find the GPLv3 
attractive. But the lawyers at my organization tried to explain me that 
the GCC compiler is much more than GPL. Any legal mistake could have 
tremendous consequences.
[I'm working at the French DoE equivalent - CEA http://www.cea.fr/ is 
producing French nuclear warheads, and providing expertise for French 
civilian reactors; I definitely don't want to start a nuclear war with 
some GCC patch; honestly, I find such an event very unlikely.]

In my view, the only way GCC would become only GPL (and not GPL + FSF 
copyright with *unlimited* liabilities & co-responsabilities from 
employers of contributors) would be a GCC fork (to a GPLv3 code base 
with patches belonging to *contributors*, not to FSF), unlikely to happen.

In case you did not understood that, any political or legal point of 
view is only mine, not of my employer's. And I am not a lawyer, and I 
don't want to become one, and I don't even like to speak to them.

> I wouldn't like to see Apple to take my work,
> add some shiny stuff and start distributing it as a closed-source
> bonus to its customers. But if the GPL is stopping you from
> contributing, then go now because we cannot and we do not want to
> change this. But the procedure, I don't see any reason why it could
> not improve.

It is not the GPL that bothers me, it is the transfer of copyright to 
FSF. Getting that document signed was so painful to me that I will never 
try again. And this (FSF copyright requirement) fact disable me to even 
consider contributing -even a dozen lines- to other GNU code such as 
binutils.

>> Any even since I did send patches to GCC since several years, I am still
>> scared even now when sending one.
> 
> Scared about what? Legal implications? Please clarify.

I am only scared about the reaction of the community - i.e. cultural 
issues. Working a lot on some code and having it rejected by some folks 
I never met in a few seconds is -for me- very uneasy.  The coding 
typesetting rules (which I don't understand; I won't be able to 
formalize them), the spelling & language conventions, the strong 
language of patch rejections [i.e. words like "this patch is crap"], all 
this is still scary to me. Remember, I am not a native English speaker.

 From a legal point of view, I never dive into patent databases to check 
that any small idea in my code is already patented (especially in the 
US, where the patent system is more crazy than in Europe). Who is really 
honestly doing that before sending a patch for GCC? And my code 
contribution is probably not clever enough to interest any lawyer!

And my employer's lawyers explained to me that there are even some terms 
of the copyright transfer which are illegal in France, because the 
copyright laws are so different in the USA & in France. It is called 
"droit moral de l'auteur" -I don't claim to be able to translate these 
french words; I am not a lawyer but I understood that in France no one - 
not even the FSF - could legally claim to a judge that the code I wrote 
was not written by me, while something similar is possible in US law. 
But I am not a lawyer, and I don't want to become one.

I also never understood what would happen if I had a brain illness to 
the point of submitting illegal patches (I have no idea if such things 
could exist; I am supposing today that if I wrote every character of 
every patch I am submitting to GCC they cannot be illegal.), or what 
would happen if the FSF or RMS decided to make all GCC code base 
proprietary (my limited understanding is that RMS or the FSF could 
relicense GCC under a non-GPL compatible license). Could a foreign 
goverment worker (I am nearly that, employed by a French government 
owned institution) crash the economy of his entire country by some 
single GCC patch? I believe that no, but I cannot prove it or just 
explain it. In principle, the "unlimited liability" words [in the 
transfer of copyright to FSF] make me think that it could be possible, 
but I don't understand how. Could a GCC patch submission start a world 
war? Again, I believe that no, but I am not able to explain why.

Of course, all opinions here are only mines, ...

I agree that I am nitpicking about law (I don't care that much about 
law; I find ethics more important than law). But I did actually spent 
too much energy to get the copyright transfer form signed (from my 
employer to FSF) and this was extremely boring and even painful to me. 
And it is sufficiently unpleasant to several people who, just because of 
the FSF copyright transfer requirement, decide to not contribute to GCC.

I have mixed & contradictory feelings about the long term future of GCC.

Cheers.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Why not contribute? (to GCC)

[Gabriel Dos Reis]

On Fri, Apr 23, 2010 at 7:04 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> Manuel López-Ibáñez wrote:
>>
>> On 23 April 2010 23:19, Basile Starynkevitch <basile@starynkevitch.net>
>> wrote:
>>>
>>> I do know that the legal system of GCC is nearly impossible to change (we
>>> all remember how getting the runtime license of GCC compatible with
>>> plugins
>>> took so long) but I believe it is one of the weaknesses of GCC. My
>>> feeling
>>> is that the legalese inside GCC have been defined in a different time and
>>> world than today!
>>
>
> I was referring to the fact that the threat to GCC is today no more from Sun
> (I read a few weeks ago that as a company Sun does not exist today). The
> competition is from other free compilers like LLVM CLANG. And it could
> happen that LLVM + CLANG would continue to exist even if Apple disappeared.
> It could also happen that LLVM + CLANG would supersede GCC.

Competition is a good thing.  I personally believe that, in the long
run, GCC will
benefit largely from it.  Remember, the new and shiny kid on the block almost
always looks sexy and cool :-)  It is true for programming languages,
and it is true
for the tools we use to execute our programs.

I have seen lot of changes to GCC since summer 1997 (when I got
interested in EGCS,
not just as a user, but as a contributor.)  If you look through the
archive, you'll realize that
some of those changes looked  "out of reach" a decade ago.
I don't see LLVM+CLANG as a threat. I see it as a stimulating competitor, and I
hope core GCC developers and potential contributors see it that way.
My dream for
GCC is to beat LLVM+CLANG, not emulate it.

I don't think lowering our standards will be of any help or good for
the long run -- quite
the contrary.

I understand the copyright issue.  I have lived and worked on both
sides of the Atlantic
(your home country and the US) and I appreciate the differences.  I
know passion runs
deep on both sides about this issue.  I submit that at the end of the
day, it is more a
matter of will than fundamental incompatible philosophical differences.

If you build it they will come.  The number of GCC contributors has
increased over the
years.  Don't get desperate by the competitors' ads :-)

-- Gaby

Re: Why not contribute? (to GCC)

[Basile Starynkevitch]

Gabriel Dos Reis wrote:
> I don't see LLVM+CLANG as a threat. I see it as a stimulating competitor, and I
> hope core GCC developers and potential contributors see it that way.
> My dream for GCC is to beat LLVM+CLANG, not emulate it.

I agree, and I would even add that if LLVM+CLANG happens to win, it is 
not such a big deal. Free software (as an ideal, and as a practice) is 
more important than individual lines of code.

What is important is the existence of good free compilers, and having 
fun to hack inside them.

Cheers.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Basile Starynkevitch <basile@starynkevitch.net> writes:

> In my own perception, the legal status of GCC is *not* the GPL. I
> would be very satisfied if GCC was "only" GPLv3+ (like Linux kernel is
> only GPLv2+). But GCC is not only GPLv3, it is in practice FSF
> copyrighted, with (for big organizations like my employer) *unlimited*
> liability for the code they have written (the lawyers at my
> organization tried to explain me that if I legally do bad things, the
> entire French state could be crushed.. by e.g. a patent litigation
> between Dark Vador & the FSF; perhaps there is some trick to avoid
> that but I did not understood it; I do stay skeptical, because I never
> coded important enough code that would matter a lot to
> others. Remember that I am not a lawyer, and I might have understood
> all wrong. And most of my GCC code don't interest a lot of people.). I
> repeat, what is scary to lawyers is the "*unlimited* liability" words
> of the copyright transfer to FSF. [If the legal documents specified a
> very large, but limited amount, like US$100M, I would imagine lawyers
> would perceive the FSF copyright transfer form differently]

The lawyers you spoke with are mistaken.  Many large companies with
lots of lawyers have signed copyright disclaimers with the FSF, and
they certainly would not have done that in the face of unlimited
liability.  Even companies in France have signed the disclaimer.

There have been issues in the past with the language disclaiming
patent rights for contributions to gcc.  The FSF was, eventually,
flexible enough on this language to permit, e.g., Google to sign the
disclaimer.  I don't know what language they are asking people to sign
to start with, but it can be adjusted.

That said, I do very much agree that the process of assigning or
disclaiming copyright is an onerous and troublesome one, and it
definitely handicaps people who would otherwise wish to contribute.
But I agree that with Manuel that some sort of copyright disclaimer is
absolutely necessary.  Past history shows us clearly that the absence
of a paperwork trail can bring significant trouble.


> I am only scared about the reaction of the community - i.e. cultural
> issues. Working a lot on some code and having it rejected by some
> folks I never met in a few seconds is -for me- very uneasy.  The
> coding typesetting rules (which I don't understand; I won't be able to
> formalize them), the spelling & language conventions, the strong
> language of patch rejections [i.e. words like "this patch is crap"],
> all this is still scary to me. Remember, I am not a native English
> speaker.

I have to agree that any gcc maintainer who would use language like
"this patch is crap" is acting wholly inappropriately and is harming
the project.  We must not speak that way to potential contributors.
It's wholly inappropriate even if the patch really is crap.  There are
many polite ways to say "no."


> I also never understood what would happen if I had a brain illness to
> the point of submitting illegal patches (I have no idea if such things
> could exist; I am supposing today that if I wrote every character of
> every patch I am submitting to GCC they cannot be illegal.),

The liability for the action would land on you rather than on the
FSF.  That is what matters for the future of the gcc project.

> or what
> would happen if the FSF or RMS decided to make all GCC code base
> proprietary (my limited understanding is that RMS or the FSF could
> relicense GCC under a non-GPL compatible license).

This turns out not to be the case.  The language of the copyright
assignment says clearly that that is not permitted.

> Could a foreign
> goverment worker (I am nearly that, employed by a French government
> owned institution) crash the economy of his entire country by some
> single GCC patch?

No, of course not.

> I believe that no, but I cannot prove it or just
> explain it. In principle, the "unlimited liability" words [in the
> transfer of copyright to FSF] make me think that it could be possible,
> but I don't understand how.

There is no unlimited liability in the copyright assignment, either in
words or in action.

> Could a GCC patch submission start a world
> war?

No.

Ian

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > or what
> > would happen if the FSF or RMS decided to make all GCC code base
> > proprietary (my limited understanding is that RMS or the FSF could
> > relicense GCC under a non-GPL compatible license).
> 
> This turns out not to be the case.  The language of the copyright
> assignment says clearly that that is not permitted.

Not only that, but the owner of the code being assigned is granted a
right back from the FSF to use that code in any way they choose, so they
can feel free to assign another copy of it to some other entity or
distribute it to anybody under any conditions they choose.

> There is no unlimited liability in the copyright assignment, either in
> words or in action.

There is in terms of the indemnification, as was discussed up-thread.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/23/2010 08:47 PM, Ian Lance Taylor wrote:
> Basile Starynkevitch<basile@starynkevitch.net>  writes:
>> I also never understood what would happen if I had a brain illness to
>> the point of submitting illegal patches (I have no idea if such things
>> could exist; I am supposing today that if I wrote every character of
>> every patch I am submitting to GCC they cannot be illegal.),
>>      
> The liability for the action would land on you rather than on the
> FSF.  That is what matters for the future of the gcc project.
...
> There is no unlimited liability in the copyright assignment, either in
> words or in action.
>    

In the first quote "The liability..." you agree that there is liability. 
In the second you say no unlimited liability.

So how much liability is required for somebody to accept in order to be 
allowed to contribute to GCC?

Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> So how much liability is required for somebody to accept in order to be 
> allowed to contribute to GCC?

This was answered already.  It's the same for EVERY software project
(not unique to GCC): if I steal somebody's copyrighted material and
"contribute" it to a software project, I am liable for the FULL EXTENT
of damages that my action caused.  This is true whether I sign an
"assignment" document or not.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 05:49 PM, Richard Kenner wrote:
>> So how much liability is required for somebody to accept in order to be
>> allowed to contribute to GCC?
>>      
> This was answered already.  It's the same for EVERY software project
> (not unique to GCC): if I steal somebody's copyrighted material and
> "contribute" it to a software project, I am liable for the FULL EXTENT
> of damages that my action caused.  This is true whether I sign an
> "assignment" document or not.
>    

Yep - but that's my point. "Full extent" without any number listed is 
effectively unlimited liability.

I saw people trying to suggest unlimited = infinity and that it will not 
be infinity, therefore it is not unlimited - but this just sounds like a 
wording game. One poster tried to argue that it was limited by 
describing that it was only 3 times some unspecified amount. But they 
missed that unspecified is unlimited. 3 times unspecified = 3 times 
unlimited = unlimited.

The fact is, it is unlimited liability because no limit has been set.

Whether this is unique to copyright assignment vs the more common shared 
ownership model? It's a good point that in either case, the liability 
may exist. This is where it becomes a bit complicated to me. As a "for 
example", I could see somebody suing the FSF because it is a funded 
organization that can be easily listed as "the defendant", whereas an 
open source project with hundreds of committers each with individual 
assignments for the parts they contributed, would be very difficult to 
list as "the defendant", so they would have to target the people 
involved with the specific patch - or "me". I couldn't see somebody 
suing me (my bank account hovers pretty low most of the time). Companies 
are not going to sue nobodies such as myself because there is no money 
in it. So, in practice, is there a difference or not? I think there is. 
With the assignment comes responsibility - except the FSF is explicitly 
requiring unlimited liability indemnity from the author, so they are 
accepting responsibility for the value, but not accepting responsibility 
for the risk. I can see why the FSF would want this - but I cannot see 
why I would want this. What's in it for me?

Honestly, this discussion has resurrected my concerns about the FSF in 
general. And since I don't really want to argue about this here, I think 
I'll cut it off by just repeating that there are a lot of GPL / BSD / 
etc. projects out there that don't seem to have the problems that are 
being predicted. The only one I see of any value is the ability to 
change the license in the future, without my explicit consent. Honestly, 
I'm a bit concerned about having my code be distributed under a 
different license without my explicit consent, especially as my 
definition of free does not match the definition of free provided by the 
FSF.

Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Yep - but that's my point. "Full extent" without any number listed is 
> effectively unlimited liability.

But what does that have to do with the FSF, GCC, or an assignment agreement?

You have EXACTLY THE SAME unlimited liability if you contribute to GCC,
LLVM, Linux, ECLIPSE, or any other project and whether you sign an
assignment or not.

> I couldn't see somebody suing me (my bank account hovers pretty low
> most of the time). Companies are not going to sue nobodies such as
> myself because there is no money in it. So, in practice, is there a
> difference or not?

No, because then the FSF wouldn't sue you EITHER!  There's NO
DIFFERENCE in theory or in practice as to your liability whether there's
an assignment or not and whether it's GCC or some other project.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 06:27 PM, Richard Kenner wrote:
>> I couldn't see somebody suing me (my bank account hovers pretty low
>> most of the time). Companies are not going to sue nobodies such as
>> myself because there is no money in it. So, in practice, is there a
>> difference or not?
>>      
> No, because then the FSF wouldn't sue you EITHER!  There's NO
> DIFFERENCE in theory or in practice as to your liability whether there's
> an assignment or not and whether it's GCC or some other project.
>    

Obviously there is a difference, otherwise FSF wouldn't be requesting 
copyright assignment. The difference is that the FSF "owns" the entire 
project. Does this affect liability in theory or in practice? You say 
no. I say it might. Consolidated ownership means an easy target for a 
greedy company and a lazy judge (neither of which are in poor 
abundance). Under such a model, this "easy target", if successfully sued 
and if damages are awarded, would pull up the copyright assignment 
agreement and hold me liable for the amount. Distributed ownership 
provides a difficult target and a less likely candidate for either a law 
suit in the first place, or a high $$$ amount once they figure out that 
they can only really sue me (and not a well funded organization). The 
ultimate in free, for me, is if every single person in the world 
contributed at least one line of code to the project, and retains 
ownership to their piece. Each person is then liable to each other 
person, and a true community owned project exists. Consolidated 
ownership can't do this.

The real reason for FSF copyright assignment is control. The FSF wants 
to control GCC. This presents a chore for potential contributors with 
very little value (if any) in return for their efforts. The published 
explanation (why-assign.html) states clearly that the FSF believes it is 
easier to defend the software and all derived software as being "free" 
(as defined by the FSF) using a consolidated ownership mode. I don't see 
how this benefits me in any way. If I'm giving software that I write to 
the community for "free", why do I care what they will do with it? If I 
control how they can use it - it's not free. It's limited use.

In some ways, I wish a group did fork GCC under GPL and drop the 
copyright assignment requirement. In other ways, this entire issue is 
just so minor to me that it isn't worth going beyond this thread. GCC 
works, but so do other compilers (Intel CC, LLVM, ...). GCC is 
distributed under the GPL, so if the FSF ever becomes a real problem (as 
opposed to merely having a political agenda), it can be forked at this 
later time.

All in all, pretty minor. GCC wants FSF copyright assignment and 
employer disclaimers? GCC will not have as many contributors. Your choice.

There are plenty of projects that we (lurkers / non contributors) can 
contribute to other projects that are not as mature and require more 
attention, or even other compilers (LLVM?).

Referring to the people and employees who have gone through the 
copyright assigment and employer disclaimers in the past and saying 
("they didn't have a problem signing") isn't evidence that the process 
is practical, efficient, or acceptable. These people probably just felt 
they had no other choice. If given the option of NOT doing this process, 
I'm sure most of them would happily have chosen option B.

Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Obviously there is a difference, otherwise FSF wouldn't be requesting 
> copyright assignment. 

I didn't say there's no different AT ALL: of course there is and that's
indeed why the assignment is needed.  What we were talking about is whether
there's a difference in the LIABILITY of a patch author.

> Distributed ownership provides a difficult target and a less likely
> candidate for either a law suit in the first place, or a high $$$
> amount once they figure out that they can only really sue me (and
> not a well funded organization).

I find the above quite confusing since in the liability scenario there's
only ONE "target", not a distributed one.  You are liable if and only if
you contribute code you don't own.  This is true whether there's a
copyright assignment or not.  The true copyright holder of the code you've
contributed, once they find out that their copyright has been violated,
will sue whoever it is that owns that code, which is either you or the
FSF, depending on which project it is.  I don't see what the ownership
status of some unrelated code has to do with this.

> The ultimate in free, for me, is if every single person in the world
> contributed at least one line of code to the project, and retains
> ownership to their piece. Each person is then liable to each other
> person, and a true community owned project exists.

Note that, as you said earlier, liability is, as a practical matter, only
relevant for companies since people don't have enough assets to be
worth suing. 

Re: Why not contribute? (to GCC)

[Jack Howarth]

On Sun, Apr 25, 2010 at 08:12:03PM -0400, Mark Mielke wrote:
...
> In some ways, I wish a group did fork GCC under GPL and drop the  
> copyright assignment requirement. In other ways, this entire issue is  
> just so minor to me that it isn't worth going beyond this thread. GCC  
> works, but so do other compilers (Intel CC, LLVM, ...). GCC is  
> distributed under the GPL, so if the FSF ever becomes a real problem (as  
> opposed to merely having a political agenda), it can be forked@this  
> later time.
>
   Is it even possible to fork? Wouldn't that require the new compiler
to start over again from the last non-GPLv3 version of the source code
(read 4.2.1...which is why Apple's gcc is stuck there). Weren't things
simplier when egcs forked from gcc (ie that they were both under the same
license)?
            Jack

...
>
> Cheers,
> mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Is it even possible to fork? Wouldn't that require the new compiler
> to start over again from the last non-GPLv3 version of the source code
> (read 4.2.1...which is why Apple's gcc is stuck there). Weren't things
> simplier when egcs forked from gcc (ie that they were both under the same
> license)?

No.  The issue of choice of license is completely orthogonal to the
issue of whether to have assignments or not.  Neither of those decisions
made by a project affects the other.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 26 April 2010 02:29, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> On Sun, Apr 25, 2010 at 08:12:03PM -0400, Mark Mielke wrote:
> ...
>> In some ways, I wish a group did fork GCC under GPL and drop the
>> copyright assignment requirement. In other ways, this entire issue is
>> just so minor to me that it isn't worth going beyond this thread. GCC
>> works, but so do other compilers (Intel CC, LLVM, ...). GCC is
>> distributed under the GPL, so if the FSF ever becomes a real problem (as
>> opposed to merely having a political agenda), it can be forked@this
>> later time.
>>
>   Is it even possible to fork? Wouldn't that require the new compiler

You can still fork GCC as long as the fork is GPLv3. It is less clear
if you can fork LLVM. Will Apple come after you with a portfolio of
patents? If you can make uninformed wild claims, so can I.

> to start over again from the last non-GPLv3 version of the source code
> (read 4.2.1...which is why Apple's gcc is stuck there). Weren't things

No, Apple is stuck there because they don't like the GPL v3. One may
speculate what is that they don't like: the new patents protections?
the new anti-drm-subversion? For sure their lawyers know what the GPL
protects against, they even participated in the process. So only Apple
knows. They seem to prefer a project with less clear terms, and less
protections against potential legal threats. I wonder why.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 26 April 2010 02:12, Mark Mielke <mark@mark.mielke.cc> wrote:
>
> All in all, pretty minor. GCC wants FSF copyright assignment and employer
> disclaimers? GCC will not have as many contributors. Your choice.
>
> There are plenty of projects that we (lurkers / non contributors) can
> contribute to other projects that are not as mature and require more
> attention, or even other compilers (LLVM?).

Are you 100% sure that the fact that LLVM does not ask for your
employer disclaimer means that you do not need to ask your employer
for some paper to legally contribute code? Are you sure you are not
exposing yourself to a legal risk? I would check with a lawyer if that
is the case. A real lawyer, not some computer guy that says "Oh, just
give us your code, it will be fine. Don't worry! We don't ask for
anything."  And a lawyer that is not interested in keeping you at risk
just in case they need to sue you at some moment.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Michael Witten]

On Sun, Apr 25, 2010 at 21:12, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 26 April 2010 02:12, Mark Mielke <mark@mark.mielke.cc> wrote:
>>
>> All in all, pretty minor. GCC wants FSF copyright assignment and employer
>> disclaimers? GCC will not have as many contributors. Your choice.
>>
>> There are plenty of projects that we (lurkers / non contributors) can
>> contribute to other projects that are not as mature and require more
>> attention, or even other compilers (LLVM?).
>
> Are you 100% sure that the fact that LLVM does not ask for your
> employer disclaimer means that you do not need to ask your employer
> for some paper to legally contribute code? Are you sure you are not
> exposing yourself to a legal risk? I would check with a lawyer if that
> is the case. A real lawyer, not some computer guy that says "Oh, just
> give us your code, it will be fine. Don't worry! We don't ask for
> anything."  And a lawyer that is not interested in keeping you at risk
> just in case they need to sue you at some moment.

I thought it was decided in the course of this thread that the
liability of an individual contributor is ultimately NOT changed by
the assignment of the copyrights to the FSF.

Also, Mark's point (I think) is that a copyright lawsuit against the
FSF is much more likely than a lawsuit against some no-name
contributor, and (more importantly) a lawsuit against the FSF is
likely to trigger the FSF to launch a lawsuit against the individual
contributor. Thus, it sort of seems to the individual contributor that
assigning copyrights to the FSF while maintaining 'unlimited
liability' is less safe than not assigning copyrights to the FSF.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Also, Mark's point (I think) is that a copyright lawsuit against the
> FSF is much more likely than a lawsuit against some no-name
> contributor, and (more importantly) a lawsuit against the FSF is
> likely to trigger the FSF to launch a lawsuit against the individual
> contributor. Thus, it sort of seems to the individual contributor that
> assigning copyrights to the FSF while maintaining 'unlimited
> liability' is less safe than not assigning copyrights to the FSF.

Perhaps, but liability is less of an issue for individual than
corporations because individuals have few assets.  This thread started
with a complaint about unlimited liability FROM A CORPORATION, who
are the people that tend to worry about such things.

On the other hand, the FSF doesn't exactly have a lot of assets, so suing
it wouldn't be very productive either.

To me, point is this: if you don't have many assets, there isn't a
difference between a "unlimited" liability and the sort of limit that
would exist in this context.  If you DO have a large number of assets,
then you're actually a BETTER target than the FSF!

And then there's the argument I made before: if you're INNOCENT of an
accuses infringment and you DON'T assign to somebody, then YOU get the
job of defending the merits of the case instead of the entity you
assign it to.

The bottom line, to me, is this: if you ARE guilty of infringement,
you ARE sued and they prevail, then there's no difference whatsoever
between the assignment case.  That's the only case where there's
significant liability and what people are most worried about.

If one of those three ISN'T true, then you can make various arguments
one way or the other based on the perceived likelihood of somebody
suing somebody else, the costs of a defence, and the chance of losing a
case that you "should" have won.  Some scenarios seem to go one way and
some the other, but basically it's all a guess.

That's why I say there's no difference in the two cases.

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 03:32, Michael Witten wrote:

> I thought it was decided in the course of this thread that the
> liability of an individual contributor is ultimately NOT changed by
> the assignment of the copyrights to the FSF.
> 
> Also, Mark's point (I think) is that a copyright lawsuit against the
> FSF is much more likely than a lawsuit against some no-name
> contributor, and (more importantly) a lawsuit against the FSF is
> likely to trigger the FSF to launch a lawsuit against the individual
> contributor. Thus, it sort of seems to the individual contributor that
> assigning copyrights to the FSF while maintaining 'unlimited
> liability' is less safe than not assigning copyrights to the FSF.

  Well, it seems to me that the FSF will not launch a lawsuit against me
unless there is actually some at least prima facie evidence that I have indeed
taken someone else's copyrighted software and presented it as if it were my
own to gift to the FSF, which would be an act of theft on my part.  Since I
know that I'm not going to do that, I'm convinced that this protects me
against copyright related actions, because I know any such action launched
against the FSF would be spurious and I can prove it and they have every
reason to believe I can and that therefore they would lose; contrariwise, if I
have not done that (stealing code and presenting it as my own), then they can
be confident that they will be able to successfully defend any case brought
against them.

  It probably does reduce the number of contributors who would copy and paste
someone else's code from the web or somewhere and submit it as a patch to GCC,
but the ability to get lumbered with the liabilities of code from unknown
provenance would not be such a huge benefit to GCC as to be worth it, I think.

    cheers,
      DaveK

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 01:12, Mark Mielke wrote:
> On 04/25/2010 06:27 PM, Richard Kenner wrote:
>>> I couldn't see somebody suing me (my bank account hovers pretty low 
>>> most of the time). Companies are not going to sue nobodies such as 
>>> myself because there is no money in it. So, in practice, is there a 
>>> difference or not?
>>> 
>> No, because then the FSF wouldn't sue you EITHER!  There's NO DIFFERENCE
>> in theory or in practice as to your liability whether there's an
>> assignment or not and whether it's GCC or some other project.
>> 
> 
> Obviously there is a difference, otherwise FSF wouldn't be requesting 
> copyright assignment.

  There is a difference between requesting assignment and not doing so, but it
is to do with things other than liability.

> The real reason for FSF copyright assignment is control. The FSF wants to
> control GCC.

  Yes.  Specifically, they want to be able to enforce the GPL.  Since only the
copyright holder can license code to anyone, whether under GPL or whatever
terms, FSF has to hold the copyright, or it can't sue anyone who breaches the
GPL, and therefore cannot enforce it.

> mode. I don't see how this benefits me in any way. If I'm giving software
> that I write to the community for "free", why do I care what they will do
> with it? If I control how they can use it - it's not free. It's limited
> use.

  You're only looking at it from one side, that of an author.  The benefits of
the GPL are primarily to users.  Since all us authors are also users of
software, we should weigh up the inconveniences against the benefits.

  There is value for me, as a user, in the existence of free software that
can't be restricted by proprietary acts of "enclosure".  The GPL is
unashamedly a political strategy with a goal that can be seen to benefit all,
even without your needing to agree with the political stance: that goal is to
create a commons, and to make it impossible for there ever to be a tragedy of
that commons.  Whether you agree about the value (social or financial) or
likelihood of success of the exercise or not, you still benefit from that
commons, under pretty much any philosophical or political stance except for
the most extreme "everything is a zero-sum game and therefore anything that
benefits anyone except me is a harm to me" viewpoints.  Or so I think, anyway.

  So, why should you care what others will do with it?  Enlightened
self-interest.   You and others both benefit from the common wealth of free
software, therefore both you and others should, in theory, not want anyone to
try and hoard those benefits to themselves, because that's how tragedies of
commons arise.  This is what can happen with the proprietarisation of open
source software, the GPL is a way to avoid that from happening by caring about
what others do with it, hence you should care what others do with it.  You
release your software to the world because you hope people will benefit from
it, for the same reason you should continue to care what happens to it afterward.

> Referring to the people and employees who have gone through the copyright
> assigment and employer disclaimers in the past and saying ("they didn't
> have a problem signing") isn't evidence that the process is practical,
> efficient, or acceptable. These people probably just felt they had no other
> choice. If given the option of NOT doing this process, I'm sure most of
> them would happily have chosen option B.

  (Heh.  Making arbitrary claims about how many people you suppose or not
would make a certain choice or not and what their motives were or were not is
even more spurious than using ancedotal evidence, no?  It's a bit like saying
"although there is no evidence from their behaviour because they did something
else, I nonetheless assert that all these people secretly agree with me",
isn't it?)

  I do think there's a lot of confusion though, because throughout this
discussion there has been a lot of conflation between the *assignment* and the
*disclaimer*, and I'm not sure how anyone could have a problem with the
_assignment_ that was in any way connected to their employer.

  In my experience, the assignment process is simple and trivial: you email
the FSF, receive some paper documents through the snail within a couple of
weeks at the most, but if you're lucky it can be as little as a few days; you
sign them and shove them back in the post, job done.  Sometimes it takes
longer, paperwork is the kind of thing that goes missing and sometimes the FSF
office is understaffed and snowed in with work and it can take weeks, but it
basically doesn't require any significant effort on your point.  The vital
point that I think is missed when these two separate processes get conflated is:

  *Your employer has nothing to do with this process and no say nor interest
in nor right to involvement in it.*

  The assignment is a personal agreement between you as an individual and the
FSF, you agree to assign them your copyrights - not your employers'.  This
part of it can be done regardless of any subsequent discussion between you and
your employers about what they claim to be their copyright and what yours,
because your position is trivially that this obviously only applies to stuff
you do validly have the copyright of, and not to anything that belongs to them.

  Once they are sure that they aren't going to either lose anything that is
theirs, nor expose themselves or the firm to any kind of liability or expense
or obligation, management become vastly more amenable to persuading them to
sign the disclaimer; by formally disavowing ownership of the patches you
submit, you tell them, all they are promising is not to claim ownership of
stuff that isn't theirs and they don't even want anyway, and in so doing, you
point out to them, this *guarantees* that there will be no come-back on them
regardless what you get up to in your spare time.  At that point, they're
usually *keen* to sign.

  I think it is possible that some of the people who have (or have had)
trouble with the process with their employers, would find it easier if they
realised that the assignment was something they can do without anyone's
permission regardless of the terms of their employment, and subsequently
present as a fait accompli, and that at that point it then actually
facilitates getting the disclaimer from the employer, which is the only part
they have to be involved in.

    cheers,
      DaveK

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Yes.  Specifically, they want to be able to enforce the GPL.  Since only the
> copyright holder can license code to anyone, whether under GPL or whatever
> terms, FSF has to hold the copyright, or it can't sue anyone who breaches the
> GPL, and therefore cannot enforce it.

Unless I'm missing something, that argues that the FSF must have
copyright to SOME of the code.  I don't see how having copyright for
all of the code would be needed to do that.

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 04:30, Richard Kenner wrote:
>> Yes.  Specifically, they want to be able to enforce the GPL.  Since only the
>> copyright holder can license code to anyone, whether under GPL or whatever
>> terms, FSF has to hold the copyright, or it can't sue anyone who breaches the
>> GPL, and therefore cannot enforce it.
> 
> Unless I'm missing something, that argues that the FSF must have
> copyright to SOME of the code.  I don't see how having copyright for
> all of the code would be needed to do that.

  Well, if the FSF don't own all the code, they can only license the bits they
do own.  That would leave the rest of it vulnerable to predation, at least.

    cheers,
      DaveK

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 11:44 PM, Dave Korn wrote:
> On 26/04/2010 04:30, Richard Kenner wrote:
>    
>>> Yes.  Specifically, they want to be able to enforce the GPL.  Since only the
>>> copyright holder can license code to anyone, whether under GPL or whatever
>>> terms, FSF has to hold the copyright, or it can't sue anyone who breaches the
>>> GPL, and therefore cannot enforce it.
>>>        
>> Unless I'm missing something, that argues that the FSF must have
>> copyright to SOME of the code.  I don't see how having copyright for
>> all of the code would be needed to do that.
>>      
>    Well, if the FSF don't own all the code, they can only license the bits they
> do own.  That would leave the rest of it vulnerable to predation, at least.

"... they can only license the bits they do own" isn't quite right. The 
can only license the bits they have permission to license. Under the 
GPL, anybody with a legally obtained copy can re-license the software 
the same version of the GPL or a later version of the GPL.

Perhaps you mean they can only sue the bits they do own - but even that 
sounds suspect. 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? It doesn't make sense to me. But, I'm willing to assume the FSF 
lawyers know something I don't about copyright law, probably something 
about how only the actual owner (either due to being the original author 
or due to implicit copyright assignment to an employer or due to 
explicit copyright assignment to a third party such as the FSF?) can 
raise the law suit. If so, then yes, it would seem to, unfortunately, 
mean that you would need to get the author of the code that you want to 
sue about involved in the process.

Personally, this whole issue is problematic to me. I really can't see 
why I would ever sue somebody for using software that I had declared 
free. It wouldn't be worth my time and I have trouble understanding how 
I could demonstrate personal loss making the law suit worth persuing in 
the first place. Perhaps I do not run an organization such as the FSF or 
own a company that makes money off dual-licensing GPL/Commercial, so I 
don't have the same perspective as they do...

Cheers,
mark

Re: Why not contribute? (to GCC)

[Paolo Bonzini]

On 04/26/2010 11:23 AM, Mark Mielke wrote:
> Personally, this whole issue is problematic to me. I really can't see
> why I would ever sue somebody for using software that I had declared
> free.

Because (a derivative of) it is being made nonfree?

> It wouldn't be worth my time and I have trouble understanding how
> I could demonstrate personal loss making the law suit worth persuing in
> the first place.

Perhaps because you know the code better than anyone else, so you could 
provide paid support on that derivative as well.

Or maybe because you have to.  There was a case of a free software 
project (JMRI) being sued for patent infringement by a proprietary 
software company.  It turned out that the proprietary software included 
source code from the free software project without attribution (copyleft 
was not even necessary, as the project was under the Artistic License!). 
  In this case, the possibility to counter-sue saved the free software 
programmer from having to pay millions of dollars.

Paolo

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 07:41 AM, Paolo Bonzini wrote:
> On 04/26/2010 11:23 AM, Mark Mielke wrote:
>> Personally, this whole issue is problematic to me. I really can't see
>> why I would ever sue somebody for using software that I had declared
>> free.
>
> Because (a derivative of) it is being made nonfree?

How does this hurt me? Instead of being concerned how people might try 
to exploit my code, why shouldn't I be spending effort making sure that 
the best solution for all parties, including greedy corporations, is to 
work with me, to make sure the code is kept in a small number of 
branches all available in the free and open source community? Why can't 
I demonstrate the merits of free software in such a way that even the 
most stubborn of CEOs will understand what I am offering to them?

>> It wouldn't be worth my time and I have trouble understanding how
>> I could demonstrate personal loss making the law suit worth persuing in
>> the first place.
>
> Perhaps because you know the code better than anyone else, so you 
> could provide paid support on that derivative as well.

This is true whether the code is GPL or truly free.

> Or maybe because you have to.  There was a case of a free software 
> project (JMRI) being sued for patent infringement by a proprietary 
> software company.  It turned out that the proprietary software 
> included source code from the free software project without 
> attribution (copyleft was not even necessary, as the project was under 
> the Artistic License!).  In this case, the possibility to counter-sue 
> saved the free software programmer from having to pay millions of 
> dollars.

I think this might be an over simplification. There were many statements 
in this history (new to me - just read it all - good read) that 
demonstrate that the patents were incorrectly granted. The copyright 
issue was involved, and the defense of free / open source copyrights was 
involved, but it looks pretty clear to me that JMRI wanted to shut down 
*all* violations. They wanted the incorrectly granted patents dropped, 
and they wanted their copyrights held intact. Was the latter required 
for the former victory, or was that just how things played out?

I'll also note that even if it was required, it was the Artistic 
License, and it was demonstrated as being valid in a court of law. So, 
the GPL was not really part of this equation, and therefore not really 
part of this discussion, as off topic as it has gone. From my 
perspective, licenses like the Artistic License, the Apache license, or 
the BSD license, are great choices for free software projects.

I see your point that the possibility to counter-sue is valid, but I 
think the scope is the scenario provided is limited to the scope of 
ensuring that the copyright is valid at all, rather than any additional 
restrictions that the GPL defines. I think, though, that this is 
somewhat self-evident, and that the case really shows how a clever 
lawyer can confuse judges into providing poor judgements. This will 
always be a risk, and copyright is not the ultimate defense against this 
risk. It was an option in the case you listed, but I think there were 
other options. It's unfortunate that persuing options in court can cost 
large amount of money, but that's the society we live in. The best 
direction to take from the above case is to attack the problem at the 
source. 1) Patents, at least under the current system, are evil, and 
provide a lot of risk for what is becoming a questionable amount of 
value. 2) The courts need a better way to figure out when somebody is 
lying in their court room.

As demonstrated, there exists adequate laws to protect copyrights. No 
changes required on this front, at least for this scenario.

Cheers,
mark

Re: Why not contribute? (to GCC)

[Paolo Bonzini]

[trimming Cc list]

>>> It wouldn't be worth my time and I have trouble understanding how
>>> I could demonstrate personal loss making the law suit worth persuing in
>>> the first place.
>>
>> Perhaps because you know the code better than anyone else, so you
>> could provide paid support on that derivative as well.
>
> This is true whether the code is GPL or truly free.

First of all, let's avoid equivocal language (and politics).  you'll 
probably agree that the meaning of "truly free" is in the eye of the 
beholder.  So, let's simplify things and say BSD.

The difference is that if that for BSD code the other person has the 
right to close up the derivative, and you know that in this case you 
won't be able to provide any kind of paid support. (There's also the 
case of someone copylefting the derivative; how to approach this case is 
a wholly different topic).

In the case of the GPL, the other person is violating your copyright. 
You may decide to let it go, but if your or your company's finances 
depend on providing paid support for that project, or on dual licensing 
it as GPL/commercial, he's hurting you.

>> Or maybe because you have to. There was a case of a free software
>> project (JMRI) being sued for patent infringement by a proprietary
>> software company. It turned out that the proprietary software included
>> source code from the free software project without attribution
>> (copyleft was not even necessary, as the project was under the
>> Artistic License!). In this case, the possibility to counter-sue saved
>> the free software programmer from having to pay millions of dollars.
>
> I think this might be an over simplification. There were many statements
> in this history (new to me - just read it all - good read) that
> demonstrate that the patents were incorrectly granted. The copyright
> issue was involved, and the defense of free / open source copyrights was
> involved, but it looks pretty clear to me that JMRI wanted to shut down
> *all* violations. They wanted the incorrectly granted patents dropped,
> and they wanted their copyrights held intact. Was the latter required
> for the former victory, or was that just how things played out?

 From my understanding, it was the easiest way to get the case settled.

> I'll also note that even if it was required, it was the Artistic
> License, and it was demonstrated as being valid in a court of law.

Yes, I mentioned it above.  My points were basically two:

1) patents are a big threat to free/open source software, so it's better 
to keep our main counter-weapon (copyright) strong.

2) you might be forced to sue even for violation of a permissive 
license, so watering down the ability to defend your rights may turn out 
to be a bad idea, even if you choose to skip copyleft.

I hope nothing of this happens to anyone involved in this thread, of course!

Paolo

Re: Why not contribute? (to GCC)

[Richard Kenner]

> 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.  Note that I changed "right" to "permission".
The owner of the software (the copyright holder) has given you specific
permissions to do certain things with the software.  Re-distributing it is
one of them.  But you're not the OWNER of the software.

You're also not re-LICENSING the software.  If I write some software and
apply the GPL to it and you get a copy, you have my permission to
redistribute that software to a third person.  But the license that the
third person receives is from ME, not you.  If a person you give it to
violates the GPL (e.g., by giving somebody a binary copy and refusing to
give them the sources), that person has violated a license with ME and only
*I* can persue it legally.

> Personally, this whole issue is problematic to me. I really can't see 
> why I would ever sue somebody for using software that I had declared 
> free.

If they made it NON-FREE!  See above.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

You are free to keep discussing this ad-infinitum. But I really think
that this discussion is not adding anything new. It seems the same old
controversy that is beyond GCC. And it is getting confusing, hard to
follow, and at the end, all your effort will be lost in the archives
and help no one.

Cheers,

Manuel.


On 26 April 2010 14:22, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
>> 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.  Note that I changed "right" to "permission".
> The owner of the software (the copyright holder) has given you specific
> permissions to do certain things with the software.  Re-distributing it is
> one of them.  But you're not the OWNER of the software.
>
> You're also not re-LICENSING the software.  If I write some software and
> apply the GPL to it and you get a copy, you have my permission to
> redistribute that software to a third person.  But the license that the
> third person receives is from ME, not you.  If a person you give it to
> violates the GPL (e.g., by giving somebody a binary copy and refusing to
> give them the sources), that person has violated a license with ME and only
> *I* can persue it legally.
>
>> Personally, this whole issue is problematic to me. I really can't see
>> why I would ever sue somebody for using software that I had declared
>> free.
>
> If they made it NON-FREE!  See above.
>

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > 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 relicense the work
under a later version of the GPL.  In the case of the GNU Lesser GPL,
you have explicit permission to relicense the work under the GPL.  So
depending on the license, you might have permission to relicense the
work.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 11:11 AM, Alfred M. Szmidt wrote:
>     >  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 relicense the work
> under a later version of the GPL.  In the case of the GNU Lesser GPL,
> you have explicit permission to relicense the work under the GPL.  So
> depending on the license, you might have permission to relicense the
> work.
>
>    

I think the ability to re-license in the sense of changing the license 
to a different license (as allowed) is a significant freedom offered by 
the GPL. It's a significant enough freedom that Linus chose to deny it 
for Linux as he apparently felt it provided the wrong sort of freedom, 
at least at the time he made that call.

However, that isn't only/quite what I meant. My understanding of 
copyright law is that it *only* protects distribution rights of the 
works. For example, as long as I use the software internally within a 
single legal entity (company, house hold, or whatever is acceptable to 
the courts), I do not need to abide by *any* of the rules listed in the 
license, as I am not re-distributing the works. Most licenses, 
specifically including the GPL, specify rules that define what 
requirements I must meet before I am allowed to re-distribute the works. 
If re-distribute these works according to requirements, and then 
somebody down stream from me obtains a copy through me and then violates 
their licensing agreement in such a that I can demonstrate loss to a 
judge. I think I can sue. Or, rather, I don't see why I wouldn't be able 
to sue. I am required to include the license in the copy I distribute. 
They accepted the license as I provided. They violated the license. I 
can demonstrate losses as a result. How is this not a valid law suit? 
Why do I have to "own" the software to have a case? I think I just have 
to prove that a violation exists that I was the victim which resulted in 
a direct loss to me. I don't know where this "own" requirement comes 
from. But then, as I said in the thread two back that both of you are 
responding to - I am not a lawyer, and maybe the FSF knows something I 
do not. I think I've seen cases where users of software have leaned on 
companies to produce software under threat of a law suit, without 
necessarily involving each and every owner of the software. The WRT54G 
situation leaps right up to the top for me. I think the "must legally 
own the works to be listed as a victim with losses in a law suit" is not 
a true requirement. I think it might be convenient and might improve the 
chance of success - but I don't think that one requires access and 
commitment from the owners in order to create a law suit.

As somebody else pointed out, the freedoms of the GPL are designed for 
the users. The people who are the most likely to be the victims are the 
users. The authors gave the software away for free, so attempting to 
demonstrate losses on something you give away for free is almost 
laughable (I'm sure many here would not laugh). It is the *users* who 
should be able to create the law suit, because it is the *users* who are 
impacted, and it is the *users* who can put a $$$ figure on their 
losses. In the Objective C case, users can claim that without the 
Objective C code being contributed back, it would take X million man 
hours @ $N/hour to re-create the code for use in future projects. This 
is a loss which can be accurately demonstrated. Sue NeXT for 
X*N+penalties. They have the option of paying out the full amount, 
funding the free software community to create their own (hopefully 
better) Objective C implementation, settling for a smaller amount (if 
agreeable to the users), or releasing their software.

So again, I think copyright assignment is a matter of convenience and 
optimization - and not a legal requirement. But then, what do I really 
know...

Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> However, that isn't only/quite what I meant. My understanding of 
> copyright law is that it *only* protects distribution rights of the 
> works. For example, as long as I use the software internally within a 
> single legal entity (company, house hold, or whatever is acceptable to 
> the courts), I do not need to abide by *any* of the rules listed in the 
> license, as I am not re-distributing the works.

VERY FALSE!  If a company buys one copy of a book, they most certainly may
NOT make a copy of that book for every employee!  To give a more relevant
example, do you really think that a company can buy one copy of Windows and
install it on all their computers?

The owner of a copyright gets to say under what conditions somebody can
COPY their work.  Executing a computer program involves COPYING it from
disk into memory.  That's making a copy.  There was even a case where a
jury held that calling a subroutine in a separate library is making a copy
of that library.

> Most licenses, specifically including the GPL, specify rules that
> define what requirements I must meet before I am allowed to
> re-distribute the works.

No, they specify the conditions under which you're allowed to COPY the
works.  Some, like the GPL, choose only to deal with "redistribution"
(which, by the way, isn't as well-defined as you might like to think it is:
I distinction remember an in-person discussion with RMS years ago where the
question was whether it was a violation of the GPL to only have binary, and
not sources, in a bomb, specifically whether dropping the bomb on somebody
was "distributing" the software), but most proprietary licenses talk about
the conditions under which you're allowed to make a COPY, whether that copy
is considered "distributing" or NOT.

> If re-distribute these works according to requirements, and then 
> somebody down stream from me obtains a copy through me and then violates 
> their licensing agreement in such a that I can demonstrate loss to a 
> judge. I think I can sue.

If you are the copyright holder and somebody (no matter how they got it)
violates the copyright, then yes, you can.

> Why do I have to "own" the software to have a case? 

You have to own the COPYRIGHT: it's not clear what "owning" the software
means.  If you don't own the copyright, then you have no legal interest in
the work.  You are confusing yourself by thinking in terms of a "license".
The license is just a way of conveying a set of permissions under which
copies can be made.  Although it somewhat has the status of a contract,
and so contract law applies, it's primarily an instrument of COPYRIGHT law.
Most importantly, you can't license something you don't have copyright 
ownership of.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I think it is possible that some of the people who have (or have had)
> trouble with the process with their employers, would find it easier if they
> realised that the assignment was something they can do without anyone's
> permission regardless of the terms of their employment, and subsequently
> present as a fait accompli, and that at that point it then actually
> facilitates getting the disclaimer from the employer, which is the only part
> they have to be involved in.

This is only the case for people who are not working on GCC as part of
their jobs.  For those who ARE, a disclaimer would be inappropriate: the
appropriate thing is an assignment from the company to the FSF.

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 04:32, Richard Kenner wrote:
>> I think it is possible that some of the people who have (or have had)
>> trouble with the process with their employers, would find it easier if they
>> realised that the assignment was something they can do without anyone's
>> permission regardless of the terms of their employment, and subsequently
>> present as a fait accompli, and that at that point it then actually
>> facilitates getting the disclaimer from the employer, which is the only part
>> they have to be involved in.
> 
> This is only the case for people who are not working on GCC as part of
> their jobs.  For those who ARE, a disclaimer would be inappropriate: the
> appropriate thing is an assignment from the company to the FSF.

  I don't quite see that.  If the company disclaims ownership of the stuff
that you create working on GCC as part of your job, well, they've disclaimed
ownership of it, regardless of the fact that you created it while working on
GCC as part of your job, no?  Berne convention and all that, it is you who
created the creative work, the copyright is yours *unless and until* you have
assigned it to someone, and usually that someone is your employer because the
assignment is part of your contract of employment.  In that circumstance, a
disclaimer from the employer is equivalent to a semi-waiver of that part of
your contract of employment for that part of your work that they agree to
disclaim; but equally, it is possible to conceive being offered a contract of
employment that did *not* require you to assign any copyright to your employer
in some or all of the software you write while employed by them - unlikely, as
ownership of IP is one of the benefits to the employer that they get in
exchange for the money they pay you to work, but certainly not impossible or a
legal nonsense as far as I can see.

    cheers,
      DaveK

Re: Why not contribute? (to GCC)

[Russ Allbery]

Dave Korn <dave.korn.cygwin@googlemail.com> writes:

>   I don't quite see that.  If the company disclaims ownership of the
> stuff that you create working on GCC as part of your job, well, they've
> disclaimed ownership of it, regardless of the fact that you created it
> while working on GCC as part of your job, no?  Berne convention and all
> that, it is you who created the creative work, the copyright is yours
> *unless and until* you have assigned it to someone, and usually that
> someone is your employer because the assignment is part of your contract
> of employment.

I should probably not really be responding to legal threads on this list,
and I'm sure someone will point out that it's more complicated than this
and one needs to talk to a real lawyer, but note that the disposition of
copyright around work-for-hire is an aspect of the law, not something that
exists only in contracts.  Even if your contract with your employer says
absolutely nothing about copyright, work done for hire for your employer
is still owned by that employer.  I believe the contract would have to
explicitly say that this is *not* the case for you to be able to retain
ownership of copyright of work that you did for hire.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I believe the contract would have to explicitly say that this is
> *not* the case for you to be able to retain ownership of copyright
> of work that you did for hire.

That's my understanding as well, but where it gets tricky is whether
a SEPARATE disclaimer would have the effect of doing that as it relates
to a particular work.

Re: Why not contribute? (to GCC)

[Dave Korn]

On 26/04/2010 05:28, Richard Kenner wrote:
>> I believe the contract would have to explicitly say that this is
>> *not* the case for you to be able to retain ownership of copyright
>> of work that you did for hire.
> 
> That's my understanding as well, but where it gets tricky is whether
> a SEPARATE disclaimer would have the effect of doing that as it relates
> to a particular work.

  Well, as a data point: under the contracts that I used to write computer
games under back in the late 80s, I very definitely owned the copyright and
retained it, and was only granting the employer a licence to distribute and
exploit in various mediums and territories.  (But that was in a different
jurisdiction to the one that the FSF is based in, and I can't say for certain
how the more recent updates to the law might undermine my rights or award them
to a possible employer.)

  And yes, they were generous terms.  I was very happy with them.
Particularly when the firm selling the games was shut down and their assets,
when sold off, did not include my copyrights.  One of my fellow authors at the
time did indeed consult a lawyer, and the company in question
kind-of-pathetically sent us all copyright assignments, in case we'd like to
give them our copyright for the benefit of their fire-sale.  Not
unsurprisingly, none of us saw any reason to sign...

    cheers,
      DaveK

Re: Why not contribute? (to GCC)

[Richard Kenner]

>   I don't quite see that.  If the company disclaims ownership of the
> stuff that you create working on GCC as part of your job, well, they've
> disclaimed ownership of it, regardless of the fact that you created it
> while working on GCC as part of your job, no?

My point is that they aren't likely to DO that and it would be
inappropriate to ask them to.  Legal documents usually work out better the
closer they match reality.

> In that circumstance, a disclaimer from the employer is equivalent to a
> semi-waiver of that part of your contract of employment for that part of
> your work that they agree to disclaim; but equally, it is possible to
> conceive being offered a contract of employment that did *not* require
> you to assign any copyright to your employer in some or all of the
> software you write while employed by them - unlikely, as ownership of IP
> is one of the benefits to the employer that they get in exchange for the
> money they pay you to work, but certainly not impossible or a legal
> nonsense as far as I can see.

I wouldn't call it "legal nonsense" and perhaps one could see some sort of
unusual situation where it was the best approach, but normally doing it
that way could open the door to all sorts of OTHER issues.  For example, if
the employee isn't being paid to do this work, then what IS he being paid
for?  Is the employee's salary a legiminate business expense?  What about
the R&D tax credit?  Etc.

To use a GCC analogy, we always tell people when writing machine
descriptions to "not lie" and be as faithful to what the hardware actually
does as possible.  It's certainly possible to write MD files that don't do
that, and historically many have, but when you do that, you risk adding
kludge upon kludge to keep things working optimally.

It's the same here: if you try to use a disclaimer when an assignment is
the appropriate document, you may well find yourself trying to patch things
up later.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 11:27 PM, Dave Korn wrote:
> On 26/04/2010 01:12, Mark Mielke wrote:
>    
>> The real reason for FSF copyright assignment is control. The FSF wants to
>> control GCC.
>>      
>    Yes.  Specifically, they want to be able to enforce the GPL.  Since only the
> copyright holder can license code to anyone, whether under GPL or whatever
> terms, FSF has to hold the copyright, or it can't sue anyone who breaches the
> GPL, and therefore cannot enforce it.
>    

If the software was truly free - and not limited use - there would be no 
need to enforce it. It would be free.

>> mode. I don't see how this benefits me in any way. If I'm giving software
>> that I write to the community for "free", why do I care what they will do
>> with it? If I control how they can use it - it's not free. It's limited
>> use.
>>      
>    You're only looking at it from one side, that of an author.  The benefits of
> the GPL are primarily to users.  Since all us authors are also users of
> software, we should weigh up the inconveniences against the benefits.
>    

This presumes that the benefits of truly free software are not 
sufficient on their own to result in benefits for the users. There are 
many non-GPL "free" software projects, that continue to be distributed 
for free, without the heavy handed "enforcement" defined by the GPL. The 
GPL is just one model for free software. It is not the only model, nor 
it is the most "free" model.

>    There is value for me, as a user, in the existence of free software that
> can't be restricted by proprietary acts of "enclosure".  The GPL is
> unashamedly a political strategy with a goal that can be seen to benefit all,
> even without your needing to agree with the political stance: that goal is to
> create a commons, and to make it impossible for there ever to be a tragedy of
> that commons.  Whether you agree about the value (social or financial) or
> likelihood of success of the exercise or not, you still benefit from that
> commons, under pretty much any philosophical or political stance except for
> the most extreme "everything is a zero-sum game and therefore anything that
> benefits anyone except me is a harm to me" viewpoints.  Or so I think, anyway.
>    

I think that other licenses exist which are both more free (less limited 
use), and would provide the same sorts of value in creating a commons. I 
think the creation of a commons should be about practical merit, and not 
some weird copyright protection that acts like a virus in that it 
infiltrates every derived software of the original software. I think 
people should do the right thing because it makes sense, not because the 
FSF crafted a clever way to lock people in to a certain model and never 
escape from it.

>    So, why should you care what others will do with it?  Enlightened
> self-interest.   You and others both benefit from the common wealth of free
> software, therefore both you and others should, in theory, not want anyone to
> try and hoard those benefits to themselves, because that's how tragedies of
> commons arise.  This is what can happen with the proprietarisation of open
> source software, the GPL is a way to avoid that from happening by caring about
> what others do with it, hence you should care what others do with it.  You
> release your software to the world because you hope people will benefit from
> it, for the same reason you should continue to care what happens to it afterward.
>    

I have no fear of hoarding, because I believe that the merits of free 
software extend beyond a legal requirement to honour a copyright 
license. I believe companies generally discover that it is cheaper to 
contribute back to the project than to maintain patches off stream for 
extended periods of time. I believe that the users have power in 
requesting that the companies provide the software under an open source 
or free software license. I believe that free software has a significant 
place in this world which is compelling and self evident even to greedy 
self-interests. And if somebody doesn't get it, and hoards their own 
copy? I don't care. I as a user, can choose to not buy their solution. I 
as a user, can choose to contribute to an alternative to their solution. 
So what if somebody profits from my work? Companies such as RedHat 
profit from GPL work today. The copyright assignment part only goes so 
far in terms of protection. Personally, I have no problem with companies 
profiting from work which I have chosen to give away for free.

>> Referring to the people and employees who have gone through the copyright
>> assigment and employer disclaimers in the past and saying ("they didn't
>> have a problem signing") isn't evidence that the process is practical,
>> efficient, or acceptable. These people probably just felt they had no other
>> choice. If given the option of NOT doing this process, I'm sure most of
>> them would happily have chosen option B.
>>      
>    (Heh.  Making arbitrary claims about how many people you suppose or not
> would make a certain choice or not and what their motives were or were not is
> even more spurious than using ancedotal evidence, no?  It's a bit like saying
> "although there is no evidence from their behaviour because they did something
> else, I nonetheless assert that all these people secretly agree with me",
> isn't it?)
>    

Yes. Except - various people in this thread have suggested that a 
significant number of people have not had problems, therefore, the 
process cannot be that bad. I think it is far more likely that people 
wish they didn't have to go through this process, and find it odd that 
GCC requires it while other equal or more important projects do not 
require such a process. Sure, we're guessing - but if I can't guess - 
than these other people shouldn't guess either.

I think you are right about the next part except for one possible 
difficulty:

>    I do think there's a lot of confusion though, because throughout this
> discussion there has been a lot of conflation between the *assignment* and the
> *disclaimer*, and I'm not sure how anyone could have a problem with the
> _assignment_ that was in any way connected to their employer.
>
>    In my experience, the assignment process is simple and trivial: you email
> the FSF, receive some paper documents through the snail within a couple of
> weeks at the most, but if you're lucky it can be as little as a few days; you
> sign them and shove them back in the post, job done.  Sometimes it takes
> longer, paperwork is the kind of thing that goes missing and sometimes the FSF
> office is understaffed and snowed in with work and it can take weeks, but it
> basically doesn't require any significant effort on your point.  The vital
> point that I think is missed when these two separate processes get conflated is:
>
>    *Your employer has nothing to do with this process and no say nor interest
> in nor right to involvement in it.*
>
>    The assignment is a personal agreement between you as an individual and the
> FSF, you agree to assign them your copyrights - not your employers'.  This
> part of it can be done regardless of any subsequent discussion between you and
> your employers about what they claim to be their copyright and what yours,
> because your position is trivially that this obviously only applies to stuff
> you do validly have the copyright of, and not to anything that belongs to them.
>
>    Once they are sure that they aren't going to either lose anything that is
> theirs, nor expose themselves or the firm to any kind of liability or expense
> or obligation, management become vastly more amenable to persuading them to
> sign the disclaimer; by formally disavowing ownership of the patches you
> submit, you tell them, all they are promising is not to claim ownership of
> stuff that isn't theirs and they don't even want anyway, and in so doing, you
> point out to them, this *guarantees* that there will be no come-back on them
> regardless what you get up to in your spare time.  At that point, they're
> usually *keen* to sign.
>
>    I think it is possible that some of the people who have (or have had)
> trouble with the process with their employers, would find it easier if they
> realised that the assignment was something they can do without anyone's
> permission regardless of the terms of their employment, and subsequently
> present as a fait accompli, and that at that point it then actually
> facilitates getting the disclaimer from the employer, which is the only part
> they have to be involved in.

The problem point for people is probably that the NDA that most 
employees sign with their employer (big companies at least), usually has 
a clause to the effect "everything you do while employed by this company 
is owned by this company". It varies in terms of severity and scope, but 
I've seen it every time for myself.

Under such an agreement - can the employer truly disclaim ownership of 
software?

In an extreme example, let us say that have access to knowledge and 
resources at work which equip me to write software that would enable 
terrorists to communicate with each other without being noticed by the 
government. This technology is illegal for export under US export 
control law. I put this software into an FSF owned project such as GCC. 
Terrorists make use of this technology and destroy Washington DC. Who is 
liable? Does my employer having penned a disclaimed truly remove 
liability on their part? Would the US government see it this way?

There is a lot of theory when the GPL is talked about - among us non 
lawyers, and from various high paid lawyers.

I don't think this subject is closed, and I don't think we're going to 
close it in this thread. My intent is only to point out that it is not 
closed. I can think of scenarios that I don't believe have been 
successfully resolved, and if *I* can think of such scenarios - this 
concerns me, because I am not a lawyer. I shouldn't be the one thinking 
of these scenarios and resolving them - the lawyers should have.

Cheers,
mark

Re: Why not contribute? (to GCC)

[Dave Korn]

On 24/04/2010 01:04, Basile Starynkevitch wrote:

> I repeat, what is scary to lawyers is the
> "*unlimited* liability" words of the copyright transfer to FSF. [If the
> legal documents specified a very large, but limited amount, like
> US$100M, I would imagine lawyers would perceive the FSF copyright
> transfer form differently]

  They might, but quite possibly in the opposite way than you would expect:
they might very well find the concrete notion of the limited liability more
threatening, being for a precise and very very huge amount, rather than the
more vague and abstract notion of an unlimited liability for "however much
that would be".  Tell someone they're liable for the damage they do, they can
rationalise to themselves that they won't do much so the "unlimited" amount
will seem quite limited to them; tell someone that they're liable for a
hundred million dollars and they're likely not to hear the "up to..." part of
it.  See the description of the "Forbidden toy experiment", described at
    http://en.wikipedia.org/wiki/Cognitive_dissonance
if you're interested.  (Sorry, the French version of the page doesn't seem to
be as complete as the English one).

> I never met in a few seconds is -for me- very uneasy.  The coding
> typesetting rules (which I don't understand; I won't be able to
> formalize them), 

  Indent depth is two spaces per level.  At the start of a line, hard TABs
should be used for all blocks of 8 spaces, followed by any remaining spaces
for the correct indent level.

  Brace-enclosed blocks: braces go on the next line after any controlling
conditional, indented one level; block content is indented two levels.

  Spaces are used around all binary (or greater) operators and after function
names (before the opening bracket of the function call/prototype args).

  That's about it, I think.

> And my employer's lawyers explained to me that there are even some terms
> of the copyright transfer which are illegal in France, because the
> copyright laws are so different in the USA & in France. It is called
> "droit moral de l'auteur" -I don't claim to be able to translate these
> french words;

  "Moral rights of the author", see

   http://en.wikipedia.org/wiki/Moral_rights_(copyright_law)
or http://fr.wikipedia.org/wiki/Droit_moral

    cheers,
      DaveK

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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 people won't even start looking
   seriously inside GCC before getting that legal paper.

Simply not true, you can submit patches without the legal leg work
done.  The patch cannot be commited to the tree though.  And the time
it takes to do this is less than it took me to read your message...

   Any even since I did send patches to GCC since several years, I am
   still scared even now when sending one.

   Sorry for spaming the list with such non-technical blabla.

You should be more scared of that then sending patches. :-)

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/23/2010 06:18 PM, Alfred M. Szmidt wrote:
>     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 people won't even start looking
>     seriously inside GCC before getting that legal paper.
>
> Simply not true, you can submit patches without the legal leg work
> done.  The patch cannot be commited to the tree though.  And the time
> it takes to do this is less than it took me to read your message...
>    

I don't follow this comment...

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?

I thought "clean room implementation" implies not seeing how somebody 
else did it first, as the "clean" part is tainted after somebody 
examines the patch?

Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> 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?
> 
> I thought "clean room implementation" implies not seeing how somebody 
> else did it first, as the "clean" part is tainted after somebody 
> examines the patch?

That's true, but is much less of a risk than actually integrating the patch
into a codebase.  There's already a level of indirection here in any
infringement and the code WAS posted to a public list.

I'm shortening a complex concept here, but when you want to see if an item
infringes on a copyrighted item, you are entitled to look at each level of
abstraction independently.  When you have the sort of infringement you're
talking about above, it's occuring at a higher level of abstraction than
code and most GCC patches have little protectable content at that level.

But indeed people DO have to be careful in how much they look at patches
from people who don't have assignments, especially if the patch is very
large and has a lot of nontrivial stuff in it.

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Mark Mielke <mark@mark.mielke.cc> writes:

> 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?
>
> I thought "clean room implementation" implies not seeing how somebody
> else did it first, as the "clean" part is tainted after somebody
> examines the patch?

Clean room implementation techniques are not required to avoid
copyright violations.  Copyright only covers the expression of an
idea; it does not cover the idea itself.  Expressing the same idea in
different code is not a copyright violation.  Even independent
identical expressions are not copyright violations if they are truly
independent.  And if there is only one possible way to express an
idea, then copyright does not apply at all, as there is no creative
aspect to the work.

Ian

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Expressing the same idea in different code is not a copyright violation.

Unlike patents, in copyright law, whether something is infringing
strongly depends on whether you actually COPIED something.  Writing a
piece of code to do the same as another piece of code that you're looking
at when doing it is dubious.

> Even independent identical expressions are not copyright violations
> if they are truly independent.

Certainly!  But if you've seen one, they aren't independent.

> And if there is only one possible way to express an idea, then
> copyright does not apply at all, as there is no creative aspect to
> the work.

Agreed.  As I said earlier, this is what probably would save you in
practice: the only things that you'd be "copying" would be the unique
way to implement the idea.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 12:31 AM, Ian Lance Taylor wrote:
> Mark Mielke<mark@mark.mielke.cc>  writes:
>    
>> 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?
>>
>> I thought "clean room implementation" implies not seeing how somebody
>> else did it first, as the "clean" part is tainted after somebody
>> examines the patch?
>>      
> Clean room implementation techniques are not required to avoid
> copyright violations.  Copyright only covers the expression of an
> idea; it does not cover the idea itself.  Expressing the same idea in
> different code is not a copyright violation.  Even independent
> identical expressions are not copyright violations if they are truly
> independent.  And if there is only one possible way to express an
> idea, then copyright does not apply at all, as there is no creative
> aspect to the work.

They aren't truly independent if you use the patch as a model to work 
from. Demonstrating to a judge that your work is unique might be a lot 
more difficult if you confess to reading the original before writing the 
new.

What are clean room implementations for if not for avoiding copyright 
violation? At my company, we took things seriously to the point of 
dividing the GPL designers from the non-GPL designers to prevent code 
fragments from being leaked to one side or the other, even if just a 
faint memory that ends up resulting in code that looks just about 
exactly like the original, even if the author cannot identify what the 
original was.

Cheers,
mark

Re: Why not contribute? (to GCC)

[Frank Ch. Eigler]

Mark Mielke <mark@mark.mielke.cc> writes:

> [...]  What are clean room implementations for if not for avoiding
> copyright violation?

It's a paranoid measure to preclude the appearance of the possibility
of conceivable copyright violation.  (It's also sometimes used in the
case of trade secrets.)

> At my company, we took things seriously [...]

I hope this degree of defensiveness is well justified and not too
costly in terms of your productiveness.

- FChE

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Mark Mielke <mark@mark.mielke.cc> writes:

> What are clean room implementations for if not for avoiding copyright
> violation?

Avoiding contract violations such as promises to keep source code
secret.  A strict clean room implementation also makes it clear that
no copyright violation could have occurred.


> At my company, we took things seriously to the point of
> dividing the GPL designers from the non-GPL designers to prevent code
> fragments from being leaked to one side or the other, even if just a
> faint memory that ends up resulting in code that looks just about
> exactly like the original, even if the author cannot identify what the
> original was.

I think that was entirely unnecessary on your part, though of course
lawyers, like anybody else, will tend to ask for whatever they can
get.

I won't respond further on this subthread on the list, it has nothing
to do with gcc.

Ian

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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 rms@gnu.org or assign@gnu.org.

The disclaimers are legally necessary though, the FSF needs a paper
trail in the case your employer comes back and claims that they have
copyright over a change.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
>
> The disclaimers are legally necessary though, the FSF needs a paper
> trail in the case your employer comes back and claims that they have
> copyright over a change.

BTW, in this aspect there is no difference between GCC and LLVM. The
latter also requires to assign copyright to the University of
Illinois. If you don't have a copyright disclaimer before contributing
to LLVM, you are exposing yourself to some future legal troubles.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Joe Buck]

On Fri, Apr 23, 2010 at 03:35:26PM -0700, Manuel López-Ibáñez wrote:
> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
> >
> > The disclaimers are legally necessary though, the FSF needs a paper
> > trail in the case your employer comes back and claims that they have
> > copyright over a change.
> 
> BTW, in this aspect there is no difference between GCC and LLVM. The
> latter also requires to assign copyright to the University of
> Illinois. If you don't have a copyright disclaimer before contributing
> to LLVM, you are exposing yourself to some future legal troubles.

The main difficulties I've experienced haven't been with the copyright
assignment itself, but the issues surrounding patents in the default
disclaimer language (though I understand that the FSF has negotiated other
language with a number of corporate contributors).

Re: Why not contribute? (to GCC)

[Basile Starynkevitch]

Joe Buck wrote:
> On Fri, Apr 23, 2010 at 03:35:26PM -0700, Manuel López-Ibáñez wrote:
>> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
>>> The disclaimers are legally necessary though, [...]
> 
> The main difficulties I've experienced haven't been with the copyright
> assignment itself, but the issues surrounding patents in the default
> disclaimer language (though I understand that the FSF has negotiated other
> language with a number of corporate contributors).

Yes yes yes!

Thanks for the clarification!

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Why not contribute? (to GCC)

[Joe Buck]

On Fri, Apr 23, 2010 at 05:08:02PM -0700, Basile Starynkevitch wrote:
> Joe Buck wrote:
> > On Fri, Apr 23, 2010 at 03:35:26PM -0700, Manuel López-Ibáñez wrote:
> >> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
> >>> The disclaimers are legally necessary though, [...]
> > 
> > The main difficulties I've experienced haven't been with the copyright
> > assignment itself, but the issues surrounding patents in the default
> > disclaimer language (though I understand that the FSF has negotiated other
> > language with a number of corporate contributors).
> 
> Yes yes yes!
> 
> Thanks for the clarification!

But we aren't saying the same thing: you seem to think that people are
opening themselves up to unlimited liability by contributing, and the
issue I encountered was over the generality of the promise not to sue over
any future GCC version even if new capabilities are added.

Re: Why not contribute? (to GCC)

[Basile Starynkevitch]

Manuel López-Ibáñez wrote:
> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
>> The disclaimers are legally necessary though, the FSF needs a paper
>> trail in the case your employer comes back and claims that they have
>> copyright over a change.
> 
> BTW, in this aspect there is no difference between GCC and LLVM. The
> latter also requires to assign copyright to the University of
> Illinois. If you don't have a copyright disclaimer before contributing
> to LLVM, you are exposing yourself to some future legal troubles.

The real issue is not the copyright disclaimer, it is the legal terms 
inside. Maybe U.Illinois don't use words like "unlumited liaibility".

But we cannot know for sure, these documents are not public.

Cheers.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Why not contribute? (to GCC)

[Joe Buck]

On Fri, Apr 23, 2010 at 05:05:47PM -0700, Basile Starynkevitch wrote:
> The real issue is not the copyright disclaimer, it is the legal terms 
> inside. Maybe U.Illinois don't use words like "unlumited liaibility".

Where are you getting this term "unlimited liability" from?
I think that your legal people made a mistake, or no company
would ever agree to contribute code to the FSF.

Re: Why not contribute? (to GCC)

[Basile Starynkevitch]

Joe Buck wrote:
> On Fri, Apr 23, 2010 at 05:05:47PM -0700, Basile Starynkevitch wrote:
>> The real issue is not the copyright disclaimer, it is the legal terms 
>> inside. Maybe U.Illinois don't use words like "unlumited liaibility".
> 
> Where are you getting this term "unlimited liability" from?
> I think that your legal people made a mistake, or no company
> would ever agree to contribute code to the FSF.

Perhaps someone made a mistake, and it could be me (because I don't 
understand lawyer language). Apparently, the sensitive sentence in the 
document is something like "Developer will indemnify FSF for all losses 
if the claim is not spurious".

In my remembering, the "all losses" was interpreted by someone as 
unlimited liability ... Lawyers are usually scared by the "all losses" 
phrase. I remember someone was very angry, but I forgot the details.

But I have no ideas of the terms used in other contracts (between FSF & 
other contributors' employers).

And I am not a lawyer. And the lawyers at CEA -my employer- might know 
better French law that the US ones. And I never understood why GCC is 
convered by US laws only. It could happen that a small majority of GCC 
contributors are not US citizens.

However, I would believe that most GCC contributors do not actively 
check their patch against the US patent system (because I perceive the 
US patent system to be very ill w.r.t. software). I confess I don't do 
that - it would be a full time & boring job.

Of course all opinions are mines only, and I am not a lawyer.

Cheers.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Basile Starynkevitch <basile@starynkevitch.net> writes:

> Perhaps someone made a mistake, and it could be me (because I don't
> understand lawyer language). Apparently, the sensitive sentence in the
> document is something like "Developer will indemnify FSF for all
> losses if the claim is not spurious".

That is not unlimited liability.  That clause says that if you
contribute code which you do not own to the FSF, and the correct owner
of the code sues the FSF, and wins the court case, and the FSF is
forced to pay damages to the true owner, then you are legally
responsible to cover the FSF's costs, both the costs of damages and
the cost of litigation.

Note that this is *not* a patent clause.  This clause only refers to
you contributing code for which you are not the copyright holder.
This clause does not make you legally liable for violating any
patents, only for violating copyright law.

In a lawsuit for the violation of copyright law, the true owner can
ask for penalties of the actual losses sustained by the owner, and in
some cases can ask for triple that amount of money.

So when considering the potential liability of this clause, you need
to consider 1) you must somehow contribute code that you copied from
somebody else, rather than writing yourself; 2) the actual owner must
discover that and must decide to sue the FSF; 3) the actual owner must
show that the distribution by the FSF somehow caused them to lose
money; 4) you may be liable for three times the amount of the money
that they lost; 5) if the FSF chooses to fight this in court, which of
course they would not do if they were in the wrong, then you would
have to pay their legal fees.

So, if you screw up badly, there is liability, yes.  Unlimited
liability, no.

Ian

Re: Why not contribute? (to GCC)

[Richard Kenner]

> That is not unlimited liability.  That clause says that if you
> contribute code which you do not own to the FSF, and the correct owner
> of the code sues the FSF, and wins the court case, and the FSF is
> forced to pay damages to the true owner, then you are legally
> responsible to cover the FSF's costs, both the costs of damages and
> the cost of litigation.

Yes, but there is no limit to the "costs of damages and the cost
of litigation".  THAT'S the concern being expressed.

> So, if you screw up badly, there is liability, yes.

To me, that's the point.  This clause only operates if the person
doing the assignment did something improper.  HOWEVER, there IS a
legitimate issue: suppose an employee develops a patch and submits it
to the FSF.  Unknown to the company, the employee actually stole the code
from a third party.  But it's the COMPANY that's indemnifying the FSF.
Yes, it can sue its employee and get a judgement in the amount it has to
pay the FSF, but most likely the employee couldn't pay such a judgement.
So you do have a situation here where the company is being forced to
trust its employee.

Re: Why not contribute? (to GCC)

[Dave Korn]

On 24/04/2010 02:46, Richard Kenner wrote:

> So you do have a situation here where the company is being forced to
> trust its employee.

  Oh, teh horror!  :-O

    cheers,
      DaveK

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>> That is not unlimited liability.  That clause says that if you
>> contribute code which you do not own to the FSF, and the correct owner
>> of the code sues the FSF, and wins the court case, and the FSF is
>> forced to pay damages to the true owner, then you are legally
>> responsible to cover the FSF's costs, both the costs of damages and
>> the cost of litigation.
>
> Yes, but there is no limit to the "costs of damages and the cost
> of litigation".  THAT'S the concern being expressed.

But, as I outlined, there is a limit.  This is not patents.  This is
copyright.  Copyright law does not provide for unlimited damages.  I
agree that there is no limit specified in the assignment, but there is
a limit in reality.


>> So, if you screw up badly, there is liability, yes.
>
> To me, that's the point.  This clause only operates if the person
> doing the assignment did something improper.  HOWEVER, there IS a
> legitimate issue: suppose an employee develops a patch and submits it
> to the FSF.  Unknown to the company, the employee actually stole the code
> from a third party.  But it's the COMPANY that's indemnifying the FSF.
> Yes, it can sue its employee and get a judgement in the amount it has to
> pay the FSF, but most likely the employee couldn't pay such a judgement.
> So you do have a situation here where the company is being forced to
> trust its employee.

I would not argue that people should not try to talk the FSF out of
this position.  On the other hand, many companies have apparently had
no trouble signing this.

Ian

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > Yes, but there is no limit to the "costs of damages and the cost
> > of litigation".  THAT'S the concern being expressed.
> 
> But, as I outlined, there is a limit.  This is not patents.  This is
> copyright.  Copyright law does not provide for unlimited damages.  I
> agree that there is no limit specified in the assignment, but there is
> a limit in reality.

We're not disagreeing.  I was responding to the question of "where are
people seeing the 'unlimited'".  But in my original post, I said that
limit was a practical one in reality.

> I would not argue that people should not try to talk the FSF out of
> this position.

I agree, because it's a position the FSF *has* to take.

> On the other hand, many companies have apparently had no trouble
> signing this.

It does, however, give a reason why disclaimed+personal assignment may
be a better approach than a corporate assignment in the case where the
patch wasn't developed as part of one's work.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Perhaps someone made a mistake, and it could be me (because I don't 
> understand lawyer language). Apparently, the sensitive sentence in the 
> document is something like "Developer will indemnify FSF for all losses 
> if the claim is not spurious".
> 
> In my remembering, the "all losses" was interpreted by someone as 
> unlimited liability ... Lawyers are usually scared by the "all losses" 
> phrase. I remember someone was very angry, but I forgot the details.

Although that's true from a technical point of view, from a practical
perspective, the liability will only be an issue if the company
misrepresented what it assigned.

There is somewhat of a difference (as I understand it) between French
and US law here, but this is ABSOLUTELY REQUIRED to protect the FSF
from improper behavior of the company doing the assignment.

Let's say the FSF agreed to limit the liability to, say, $100k in an
assignment from Company A.  Now suppose that Company A conspires with
Company B and takes some of Company B's code and submits it to the FSF
with an assignment with the $100k limit.  It warrants that it has the
rights to this code, but has limited itself to a $100k liability if
that's not the case.  Now Company B "discovers" that GCC contains some
copyrighted code that belongs to it and sues the FSF for $1m.  The FSF
gets $100k from Company A, but now has to pay $900k to Company B (who
had agreeded to pay 1/3 to Company A, which now makes $200k on the deal).

Anybody who agrees to take code without any such protection is not
being prudent.

> And I never understood why GCC is convered by US laws only. 

A contract between two parties (such as an assignment) has to be governed
by ONE law.  If the two parties are in different US states (or different
countries), they each have a difference preference to which law will
apply and they need to agree on which law will be used.  Normally,
the entity that drafts the agreement will specify their law.  So the FSF
will naturally request the law of the state and country they're in.

> However, I would believe that most GCC contributors do not actively 
> check their patch against the US patent system (because I perceive the 
> US patent system to be very ill w.r.t. software). I confess I don't do 
> that - it would be a full time & boring job.

Software patents are indeed a serious problem, which is why the FSF
is so strongly against them.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/23/2010 08:37 PM, Basile Starynkevitch wrote:
> However, I would believe that most GCC contributors do not actively 
> check their patch against the US patent system (because I perceive the 
> US patent system to be very ill w.r.t. software). I confess I don't do 
> that - it would be a full time & boring job.
>

At some companies, the lawyers specifically request that employees do 
NOT check for violation of patents or research any patents before 
writing code, as this process actually increases liability. It's similar 
to the "clean room implementation" model. If I look, then my ability to 
say "I wrote this myself without any input" is tainted. If I just write 
it myself without researching what others have done, then I can at least 
claim I never copied any ideas, and although I might still be found in 
violation of a patent, this can be addressed if and when it is found 
(either pay license/royalty fees or re-write the code to NOT use the 
now-known-to-be-patented ideas).

Just thought that this "opposite approach" might be interesting to 
readers... :-)

Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> At some companies, the lawyers specifically request that employees do 
> NOT check for violation of patents or research any patents before 
> writing code, as this process actually increases liability. It's similar 
> to the "clean room implementation" model. If I look, then my ability to 
> say "I wrote this myself without any input" is tainted. If I just write 
> it myself without researching what others have done, then I can at least 
> claim I never copied any ideas, and although I might still be found in 
> violation of a patent, this can be addressed if and when it is found 
> (either pay license/royalty fees or re-write the code to NOT use the 
> now-known-to-be-patented ideas).

Indeed this difference between patents and copyrights is worth repeating
since it's critical and non-intuitive.  If you and I both write an
identical piece of music, neither of us can succeed in a copyright
infringement case against the other if we can prove we never SAW the work
of the other: in order to infringe on a copyright, you actually have to
COPY the work.

That's NOT true for patents.  Even if I independently "invent" the same
thing you do, I owe you royalties if you patented it and I didn't.  This is
why patents are a very serious threat to free software.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 02:05, Basile Starynkevitch <basile@starynkevitch.net> wrote:
> Manuel López-Ibáñez wrote:
>>
>> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
>>>
>>> The disclaimers are legally necessary though, the FSF needs a paper
>>> trail in the case your employer comes back and claims that they have
>>> copyright over a change.
>>
>> BTW, in this aspect there is no difference between GCC and LLVM. The
>> latter also requires to assign copyright to the University of
>> Illinois. If you don't have a copyright disclaimer before contributing
>> to LLVM, you are exposing yourself to some future legal troubles.
>
> The real issue is not the copyright disclaimer, it is the legal terms
> inside. Maybe U.Illinois don't use words like "unlumited liaibility".
>
> But we cannot know for sure, these documents are not public.
>

The university of Illinois is in the same legal position as the FSF
and they probably have good lawyers too, so the terms are with almost
certainty similar. Perhaps someone made a mistake during your process
or they sent the wrong papers or whatever. But again, in this aspect
there is not (or there should not be) any difference between the GCC
and LLVM, except for the process itself, which I am starting to see
that it is more problematic than I thought.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Eric Botcazou]

> But again, in this aspect there is not (or there should not be) any
> difference between the GCC and LLVM, except for the process itself, which I
> am starting to see that it is more problematic than I thought.

But there is nothing new, this has been so for decades.  And this prevented 
neither dozens of invididual contributors nor dozens of companies, including 
some of the biggest ones in the computing industry, from contributing and 
assigning the copyright to the FSF.  It isn't clear why this all of a sudden 
appears to have become an insurmountable obstacle.

-- 
Eric Botcazou

Re: Why not contribute? (to GCC)

[Richard Kenner]

> The university of Illinois is in the same legal position as the FSF
> and they probably have good lawyers too, so the terms are with almost
> certainty similar. Perhaps someone made a mistake during your process
> or they sent the wrong papers or whatever. But again, in this aspect
> there is not (or there should not be) any difference between the GCC
> and LLVM, except for the process itself, which I am starting to see
> that it is more problematic than I thought.

Actually, the University of Illinois is NOT in the same legal position
as the FSF and needs to be much MORE careful!  The FSF has no assets:
anybody suing it and winning will get a symbolic victory only, but no
real money.  Universities own a lot of buildings, to say nothing of
their endowment!  All of that would be a jeopardy if they messed up on
the handling of a patch.  That gives people much MORE incentive to sue
them than the FSF.

I haven't seen the documents from them, but I'd expect them to be even
stricter than those from the FSF since they have so much more at stake.

If somebody sues the FSF for $10M and wins, the FSF goes away, but no
money is lost.  If somebody sues a university for $10M and wins, they
get that money and the university loses it.

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 23, 2010, at 5:05 PM, Basile Starynkevitch wrote:

> Manuel López-Ibáñez wrote:
>> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
>>> The disclaimers are legally necessary though, the FSF needs a paper
>>> trail in the case your employer comes back and claims that they have
>>> copyright over a change.
>> BTW, in this aspect there is no difference between GCC and LLVM. The
>> latter also requires to assign copyright to the University of
>> Illinois. If you don't have a copyright disclaimer before contributing
>> to LLVM, you are exposing yourself to some future legal troubles.
> 
> The real issue is not the copyright disclaimer, it is the legal terms inside. Maybe U.Illinois don't use words like "unlumited liaibility".
> 
> But we cannot know for sure, these documents are not public.

I'm not sure why you think that.  Unlike the FSF, all of the LLVM projects' requirements are public:
http://llvm.org/docs/DeveloperPolicy.html

LLVM does not require a copyright assignment.  People can send in random patches and they get immediately applied.

-Chris

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:

> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
>> 
>> The disclaimers are legally necessary though, the FSF needs a paper
>> trail in the case your employer comes back and claims that they have
>> copyright over a change.
> 
> BTW, in this aspect there is no difference between GCC and LLVM. The
> latter also requires to assign copyright to the University of
> Illinois. If you don't have a copyright disclaimer before contributing
> to LLVM, you are exposing yourself to some future legal troubles.

On what do you base these assertions?  Every point seems wrong to me.

-Chris

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 06:20, Chris Lattner <clattner@apple.com> wrote:
>
> On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
>
>> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
>>>
>>> The disclaimers are legally necessary though, the FSF needs a paper
>>> trail in the case your employer comes back and claims that they have
>>> copyright over a change.
>>
>> BTW, in this aspect there is no difference between GCC and LLVM. The
>> latter also requires to assign copyright to the University of
>> Illinois. If you don't have a copyright disclaimer before contributing
>> to LLVM, you are exposing yourself to some future legal troubles.
>
> On what do you base these assertions?  Every point seems wrong to me.

Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html

<quote>
Developer Agreements

With regards to the LLVM copyright and licensing, developers agree to
assign their copyrights to UIUC for any contribution made so that the
entire software base can be managed by a single copyright holder. This
implies that any contributions can be licensed under the license that
the project uses.

When contributing code, you also affirm that you are legally entitled
to grant this copyright, personally or on behalf of your employer. If
the code belongs to some other entity, please raise this issue with
the oversight group before the code is committed.
</quote>

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote:

> On 25 April 2010 06:20, Chris Lattner <clattner@apple.com> wrote:
>> 
>> On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
>> 
>>> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
>>>> 
>>>> The disclaimers are legally necessary though, the FSF needs a paper
>>>> trail in the case your employer comes back and claims that they have
>>>> copyright over a change.
>>> 
>>> BTW, in this aspect there is no difference between GCC and LLVM. The
>>> latter also requires to assign copyright to the University of
>>> Illinois. If you don't have a copyright disclaimer before contributing
>>> to LLVM, you are exposing yourself to some future legal troubles.
>> 
>> On what do you base these assertions?  Every point seems wrong to me.
> 
> Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html

The key distinction is that contributing to LLVM does not require you to sign a form (which isn't even publicly available) and mail it in to a busy and high-latency organization before non-trivial patches will be accepted.

-Chris

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 16:55, Chris Lattner <clattner@apple.com> wrote:
>
> On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote:
>
>> On 25 April 2010 06:20, Chris Lattner <clattner@apple.com> wrote:
>>>
>>> On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
>>>
>>>> On 24 April 2010 00:18, Alfred M. Szmidt <ams@gnu.org> wrote:
>>>>>
>>>>> The disclaimers are legally necessary though, the FSF needs a paper
>>>>> trail in the case your employer comes back and claims that they have
>>>>> copyright over a change.
>>>>
>>>> BTW, in this aspect there is no difference between GCC and LLVM. The
>>>> latter also requires to assign copyright to the University of
>>>> Illinois. If you don't have a copyright disclaimer before contributing
>>>> to LLVM, you are exposing yourself to some future legal troubles.
>>>
>>> On what do you base these assertions?  Every point seems wrong to me.
>>
>> Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
>
> The key distinction is that contributing to LLVM does not require you to sign a form (which isn't even publicly available) and mail it in to a busy and high-latency organization before non-trivial patches will be accepted.

So, is the copyright disclaimer implicit in the patch submission? Who
defines the conditions?

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
>>>> 
>>>> On what do you base these assertions?  Every point seems wrong to me.
>>> 
>>> Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
>> 
>> The key distinction is that contributing to LLVM does not require you to sign a form (which isn't even publicly available) and mail it in to a busy and high-latency organization before non-trivial patches will be accepted.
> 
> So, is the copyright disclaimer implicit in the patch submission? Who
> defines the conditions?

That web page is everything that there is.  I am aware that this is not as legally air-tight as the FSF disclaimer, but empirically many companies seem to have no problem with it.

-Chris

Re: Why not contribute? (to GCC)

[H.J. Lu]

On Sun, Apr 25, 2010 at 8:04 AM, Chris Lattner <clattner@apple.com> wrote:
> On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
>>>>>
>>>>> On what do you base these assertions?  Every point seems wrong to me.
>>>>
>>>> Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
>>>
>>> The key distinction is that contributing to LLVM does not require you to sign a form (which isn't even publicly available) and mail it in to a busy and high-latency organization before non-trivial patches will be accepted.
>>
>> So, is the copyright disclaimer implicit in the patch submission? Who
>> defines the conditions?
>
> That web page is everything that there is.  I am aware that this is not as legally air-tight as the FSF disclaimer, but empirically many companies seem to have no problem with it.
>

Can't resist. So in theory, someone can sue LLVM and win. If it is the
case, I may
not want to use LLVM as my system compiler.


-- 
H.J.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/25/2010 11:20 AM, H.J. Lu wrote:
> On Sun, Apr 25, 2010 at 8:04 AM, Chris Lattner<clattner@apple.com>  wrote:
>    
>> On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
>>      
>>> So, is the copyright disclaimer implicit in the patch submission? Who
>>> defines the conditions?
>>>        
>> That web page is everything that there is.  I am aware that this is not as legally air-tight as the FSF disclaimer, but empirically many companies seem to have no problem with it.
>>      
> Can't resist. So in theory, someone can sue LLVM and win. If it is the
> case, I may
> not want to use LLVM as my system compiler.
>    

Considering that Linux, as the system kernel for many of us, is in a 
similar position, I don't see why the compiler, which isn't even a 
necessary part of a running system, would need to be more strict...

In any case, the FSF disclaimer is paper work. It may help in some 
theoretical situation - or maybe it will be called invalid at the time 
it is presented. The question is whether the added paper work is really 
providing protection, or is it just slowing contributions? I don't have 
the answer to that - I only see that LLVM and many other projects under 
various free / open source licenses are proceeding just fine without 
such paper work, so on the surface, it does seem like an overall loss 
for GCC. One day might it prove its value? Who knows...

Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> That web page is everything that there is.  I am aware that this is not as 
> legally air-tight as the FSF disclaimer, but empirically many companies
> seem to have no problem with it.

There's nothing to have a problem WITH!  No assignment has taken place.
The statement on the web has no legal significance whatsoever.  Unless
the company SIGNS something, they still own the copyright on the code
and can, at any time, decide they don't want it distributed.

Re: Why not contribute? (to GCC)

[Michael Witten]

On Sun, Apr 25, 2010 at 11:33, Richard Kenner
<kenner@vlsi1.ultra.nyu.edu> wrote:
> There's nothing to have a problem WITH!  No assignment has taken place.
> The statement on the web has no legal significance whatsoever.  Unless
> the company SIGNS something, they still own the copyright on the code
> and can, at any time, decide they don't want it distributed.

If I submit a patch to the GCC project---necessitating an assignment
of the copyright to the FSF---then can the people of the FSF decide
that they don't want me to distribute my own work in another project
(proprietary or otherwise)?

That is, could I actually become liable for infringing on the
copyright of my own original work? Are we just trusting RMS not to be
a troll (tongue-in-cheek)?

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 18:48, Michael Witten <mfwitten@gmail.com> wrote:
> On Sun, Apr 25, 2010 at 11:33, Richard Kenner
> <kenner@vlsi1.ultra.nyu.edu> wrote:
>> There's nothing to have a problem WITH!  No assignment has taken place.
>> The statement on the web has no legal significance whatsoever.  Unless
>> the company SIGNS something, they still own the copyright on the code
>> and can, at any time, decide they don't want it distributed.
>
> If I submit a patch to the GCC project---necessitating an assignment
> of the copyright to the FSF---then can the people of the FSF decide
> that they don't want me to distribute my own work in another project
> (proprietary or otherwise)?
>
> That is, could I actually become liable for infringing on the
> copyright of my own original work? Are we just trusting RMS not to be
> a troll (tongue-in-cheek)?

This is explicitly mentioned on the copyright assignment form from the
FSF. And the answer is NO.

On the other hand, when the assignment is implicit like for LLVM, I
really don't know. You need to ask your own lawyer (not the ones from
Apple or from the U. of Illinois).

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> On the other hand, when the assignment is implicit like for LLVM, I
> really don't know. You need to ask your own lawyer (not the ones from
> Apple or from the U. of Illinois).

I don't believe there IS such a thing as an "implicit assignment".
You either signed a contract that assigns the copyright or you
haven't.  If an employee of some large company (say, Microsoft) writes
a patch for LLVM and submits it, what in the world would bind
Microsoft to having given up their copyright interest in that patch?
Certainly not some statement buried someplace in a web site.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> If I submit a patch to the GCC project---necessitating an assignment
> of the copyright to the FSF---then can the people of the FSF decide
> that they don't want me to distribute my own work in another project
> (proprietary or otherwise)?

No, because the assignment agreement says that the FSF "agrees to
grant the Assigner non-exclusive rights to use the Work (i.e. the
changes and enhancements, not the program which was enhanced) as it
sees fit".  And, indeed, this is commonly done.  For example, Cygwin
had two different license agreements, one when it's distributed by the
FSF and one when it's purchased by Cygnus.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

The FSF copyright assignments grant you back ultimate rights to use
it in anyway you please.

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sun, Apr 25, 2010 at 6:48 PM, Michael Witten <mfwitten@gmail.com> wrote:
> On Sun, Apr 25, 2010 at 11:33, Richard Kenner
> If I submit a patch to the GCC project---necessitating an assignment
> of the copyright to the FSF---then can the people of the FSF decide
> that they don't want me to distribute my own work in another project
> (proprietary or otherwise)?

No. This is very explicitly mentioned in the copyright assignment
papers. For example, from my own copy (2002):

"1.(d) FSF agrees to grant back to Developer, and does hereby grant,
non-exclusive, royalty-free and non-cancellable rights to use the
Works (i.e., Developer's changes and/or enhancements, not The Program
that they enhance), as Developer sees fit."

In other words, you can distribute your own work in another project in
any way you want.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Andrew Haley]

On 04/25/2010 06:05 PM, Steven Bosscher wrote:
> On Sun, Apr 25, 2010 at 6:48 PM, Michael Witten <mfwitten@gmail.com> wrote:
>> On Sun, Apr 25, 2010 at 11:33, Richard Kenner
>> If I submit a patch to the GCC project---necessitating an assignment
>> of the copyright to the FSF---then can the people of the FSF decide
>> that they don't want me to distribute my own work in another project
>> (proprietary or otherwise)?
> 
> No. This is very explicitly mentioned in the copyright assignment
> papers. For example, from my own copy (2002):
> 
> "1.(d) FSF agrees to grant back to Developer, and does hereby grant,
> non-exclusive, royalty-free and non-cancellable rights to use the
> Works (i.e., Developer's changes and/or enhancements, not The Program
> that they enhance), as Developer sees fit."

This is an example of a case where an explicit copyright agreement
helps everyone.  Clarity is good.

Andrew.

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 9:33 AM, Richard Kenner wrote:

>> That web page is everything that there is.  I am aware that this is not as 
>> legally air-tight as the FSF disclaimer, but empirically many companies
>> seem to have no problem with it.
> 
> There's nothing to have a problem WITH!  No assignment has taken place.
> The statement on the web has no legal significance whatsoever.  Unless
> the company SIGNS something, they still own the copyright on the code
> and can, at any time, decide they don't want it distributed.

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.  The LLVM project does not aim to be able to change the license in the future, all that is really important is that contributors agree to license their code under the llvm "bsd" license.

For at least some contributors, not being able to change the license is actually a major feature.  They aren't comfortable with assigning code to an organization which can then change the license of the code to something they don't agree with.  This is exactly what happened when code written and contributed under GPL2 got relicensed as GPL3 for example.  I'm not saying that this is right or wrong, but perceptions are held by people.

In any case the aims of the FSF are quite clear, and IMO it seems that the explicit copyright assignment is a real and necessary part of achieving those aims.  Different projects just have different goals.

-Chris

Re: Why not contribute? (to GCC)

[Richard Kenner]

> because the only reason copyright needs to be assigned (AFAIK) is to
> change the license.

False.  See a discussion of this earlier in the thread.

> The LLVM project does not aim to be able to change the license in the
> future, 

Nobody "aims" to change something in the future, but nobody has a crystal
ball either and it can often be hard to predict what might have to be done
in the future.


But this misses an important point.  There are TWO reasons for what we've
been calling the assignment form.  One is to actually assign the copyright.
The other is to have a signed statement by the contributor that they have
the ownership rights to make the contribution and are indemnifying the
entity they are contributing to in case they don't.  What document serves
this purpose for LLVM if there's no assignment form?

If there's no such document, then what does the project do if, unknown to
them, some employee of a large company contributed code without the
permission of his employer, the project distributes that code, and then the
large software company sues for infringment?  You can't even go after the
employee because not even he has signed anything.

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 25, 2010, at 2:30 PM, Richard Kenner wrote:
>> The LLVM project does not aim to be able to change the license in the
>> future, 
> 
> Nobody "aims" to change something in the future, but nobody has a crystal
> ball either and it can often be hard to predict what might have to be done
> in the future.

We'll see.  Fortunately the future comes sooner than anyone expects.

> If there's no such document, then what does the project do if, unknown to
> them, some employee of a large company contributed code without the
> permission of his employer, the project distributes that code, and then the
> large software company sues for infringment?

This would be on topic if the thread were "Why not contribute? (to LLVM)", but it isn't.  If you're really concerned about LLVM developers, that's one thing, but this is certainly not the place to discuss it.

I find it amusing the willingness of various developers to debate the veracity of the LLVM policies, but the simulataneous (apparent) unwillingness to address GCC's (perceived) problems.  Why not spend your time helping improve the documentation, increase modularity, or improve the copyright assignment process, rather than participate so much in this thread?


On Apr 25, 2010, at 7:12 PM, Manuel López-Ibáñez wrote:
> Are you 100% sure that the fact that LLVM does not ask for your
> employer disclaimer means that you do not need to ask your employer
> for some paper to legally contribute code? Are you sure you are not
> exposing yourself to a legal risk?

This is such an incredibly immense scoop of FUD that I couldn't help but respond to it :-)  Isn't this thread supposed to be about finding ways to improve GCC?

-Chris

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > If there's no such document, then what does the project do if, unknown to
> > them, some employee of a large company contributed code without the
> > permission of his employer, the project distributes that code, and then the
> > large software company sues for infringment?
> 
> This would be on topic if the thread were "Why not contribute? (to LLVM)",
> but it isn't.  If you're really concerned about LLVM developers, that's one
>  thing, but this is certainly not the place to discuss it.

OK, then I'll rephrase it:

If the GCC project were to change their policy so that there is no longer
any document signed between the submitter of the code and the FSF, then
what would the project do if, unknown to them, some employee of a large
company contributed code without the permission of his employer, the
project distributes that code, and then the large software company sues for
infringment?

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 26 April 2010 07:06, Chris Lattner <clattner@apple.com> wrote:
>
> I find it amusing the willingness of various developers to debate the veracity of the LLVM policies, but the simulataneous (apparent) unwillingness to address GCC's (perceived) problems.  Why not spend your time helping improve the documentation, increase modularity, or improve the copyright assignment process, rather than participate so much in this thread?
>

Well, I agree that the discussion is going a bit off-topic. As it
commonly happens when the legal issues are raised. But it has been
raised that it is easier to contribute to LLVM than to GCC because the
former does not require a copyright assignment/disclaimer. The
question then is whether the copyright assignment/disclaimer is needed
at all, or its benefits outweighs its costs. It is a pointless
discussion for GCC because the FSF strongly feels that it is
necessary. I guess you have noticed that I am not in the LLVM mailing
list raising this "uncomfortable" questions.

In fact, I agree that those are (real, not perceived) problems in GCC.
But to address those problems we need more help. And I feel the
feedback from would-be-contributors has been interesting, but we
probably are not going to get anything more useful from this thread.
Can I close it?

> On Apr 25, 2010, at 7:12 PM, Manuel López-Ibáñez wrote:
>> Are you 100% sure that the fact that LLVM does not ask for your
>> employer disclaimer means that you do not need to ask your employer
>> for some paper to legally contribute code? Are you sure you are not
>> exposing yourself to a legal risk?
>
> This is such an incredibly immense scoop of FUD that I couldn't help but respond to it :-)  Isn't this thread supposed to be about finding ways to improve GCC?

From the things we have heard in this thread, this is a pretty
sensible question. Is the answer yes or no? You could actually ask the
lawyers of the U. of Illinois. But yes, until I start contributing to
LLVM (which may happen someday, there is nothing wrong with it) I
don't care much, that is, unless someone raises again the point that
it is easier to contribute to LLVM because they don't ask for a
copyright disclaimer. If you get an answer, I am honestly interested.
:-)

Manuel.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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 reason (and in the GNU projects case, not a
reason at all), the main reason is to be able to enforce the copyright
of the work without having to call in everyone into court.  If only
parts of GCC where copyrighted by the FSF, then the FSF could only sue
only for those parts.

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 26, 2010, at 8:11 AM, Alfred M. Szmidt wrote:
>   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 reason (and in the GNU projects case, not a
> reason at all), the main reason is to be able to enforce the copyright
> of the work without having to call in everyone into court.  If only
> parts of GCC where copyrighted by the FSF, then the FSF could only sue
> only for those parts.

Someone else pointed this out elsewhere in the thread, so perhaps it is worth responding.  Being able to enforce copyright is specifically useful if your code is under a GPL-style license.  For code under a bsd-style "do whatever you want, but don't sue us" style license, this is much less important.  That is why I claimed that the license change aspect is most important: for me personally, "enforcing copyright" is not a particular exciting prospect.

w.r.t. "hoarding", I'll point out that (in the context of GCC) being able to enforce copyright is pretty useless IMO.  While you can force someone to release their code, the GPL doesn't force them to assign the copyright to the FSF.  In practice this means that you can force someone to release their GCC changes, but you can't merge them back to mainline GCC.  In a warped way you could argue that the FSF using the GPL encourages their software to fork :-)


On Apr 25, 2010, at 10:23 PM, Richard Kenner wrote:
>> This would be on topic if the thread were "Why not contribute? (to LLVM)",
>> but it isn't.  If you're really concerned about LLVM developers, that's one
>> thing, but this is certainly not the place to discuss it.
> 
> OK, then I'll rephrase it:
> 
> If the GCC project were to change their policy so that there is no longer
> any document signed between the submitter of the code and the FSF,

To be perfectly clear, I'm not suggesting that the FSF or GCC project change their policies.  I'm just disputing some claims about LLVM system, and pointing out that LLVM and GCC's policies differ because there are substantially different goals involved.  The LLVM project is much more focused on the technology and the community, the GCC project is more focused on ensuring software freedom (as defined by the FSF).  There isn't anything wrong with having different goals.

-Chris

Re: Why not contribute? (to GCC)

[Olivier Galibert]

On Mon, Apr 26, 2010 at 09:53:51AM -0700, Chris Lattner wrote:
> w.r.t. "hoarding", I'll point out that (in the context of GCC) being
> able to enforce copyright is pretty useless IMO.  While you can
> force someone to release their code, the GPL doesn't force them to
> assign the copyright to the FSF.  In practice this means that you
> can force someone to release their GCC changes[...]

No, you can't.  You can't force some entity to release source code
they have copyright to, that's not part of the legal remedies that are
available to a judge.  What the judge can do is preventing the entity
to distribute the code and/or money and/or jail.

When source code is released, it's through a settlement.  And a
settlement can contain anything the parties agree on and the judge
considers fair, including copyright assignments.

  OG.

Re: Why not contribute? (to GCC)

[Richard Kenner]

Chris Lattner wrote:
> To be perfectly clear, I'm not suggesting that the FSF or GCC
> project change their policies. 

Sure.  But others have and that's what this thread is all about.

Jonathan Corbet wrote:
> If the copyright holders don't wish to sue, then, one presumes, they
> are not unhappy about the use of their code?

No, certainly not. One presumes, instead, that they feel it's too much
TROUBLE to sue, which is exactly the point here.  If I'm walking down the
street and somebody's careless and knocks me down and I'm in pain for a
couple of days because of injuring my ankle and I choose not to sue the
person, does that mean I'm not unhappy he injured me?

If I own 1% of the code of a program and somebody makes it non-free, I'm
going to be upset, but probably not enough to either sue the person or try
to organize a group do to collectively.  But if instead I assigned that
software to a group that decided to sue, I'd be very happy they did and
glad that my assignment let them be able to do it.

Olivier Galibert wrote:
> You can't force some entity to release source code they have
> copyright to, that's not part of the legal remedies that are
> available to a judge.

What makes you say that?  Why couldn't that be a legal remedy?  When you
lose a suit, the whole point is you lose something of value.  Maybe it's
money, maybe it's real property, maybe it's a vehicle, maybe it's
custody of a child, or maybe it's loss of rights to illectual property.
The remedy you say a judge "can't" do is, in fact, not that uncommon.

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 02:00 PM, Richard Kenner wrote:
> If I own 1% of the code of a program and somebody makes it non-free, I'm
> going to be upset, but probably not enough to either sue the person or try
> to organize a group do to collectively.  But if instead I assigned that
> software to a group that decided to sue, I'd be very happy they did and
> glad that my assignment let them be able to do it.
>    

Nobody can take your code and make it non-free.

They can take a copy of your code and modify it, but at no time does 
your original code become non-free. As long as people continue to copy 
from your "free" version of the code, they can continue to use it for 
"free".

The GPL isn't free though. The GPL is a limited use license that 
restricts freedoms in such a way that there is some expectation that the 
lost freedoms can purchase future freedom, and this compromise is justified.

Many of us don't agree that the compromise is justified. This will 
forever be a political difference between the two sides, and is unlikely 
to be resolved here. This is an FSF/GPL issue more than a GCC issue. It 
just so happens that GCC is one of the most easily recognized and widely 
used FSF-owned projects, so it is an easy target for us GPL haters. :-)

For the record: There is no ill will about the project. Some of us just 
don't understand why GCC couldn't survive or thrive under a less 
restrictive contribution and/or licensing model. We know of other 
projects that are near equal or in some cases greater than GCC in terms 
of actual impact on the world today that do not seem to share the same 
contribution and/or licensing model. Before anybody gets upset about 
this - please realize that I see GCC primarily as a compiler that 
translates from source form to executable form, and that there exists 
compatible or near compatible alternatives to GCC that could be switched 
to within a few months or less for most projects with an annoying but 
minimum amount of fuss. I also think that any truly free platform should 
have alternative implementations to avoid vendor lock and to enable 
healthy competition that will lead to better overall results for the end 
users.

Cheers,
mark

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Nobody can take your code and make it non-free.
> 
> They can take a copy of your code and modify it, but at no time does 
> your original code become non-free. As long as people continue to copy 
> from your "free" version of the code, they can continue to use it for 
> "free".

Correct.  A perhaps better way of putting is "use my code as part of
something that's non-free".

Re: Why not contribute? (to GCC)

[Michael Witten]

On Mon, Apr 26, 2010 at 21:03, Mark Mielke <mark@mark.mielke.cc> wrote:
> They can take a copy of your code and modify it, but at no time does your
> original code become non-free. As long as people continue to copy from your
> "free" version of the code, they can continue to use it for "free".
>
> The GPL isn't free though. The GPL is a limited use license that restricts
> freedoms in such a way that there is some expectation that the lost freedoms
> can purchase future freedom, and this compromise is justified.
>
> Many of us don't agree that the compromise is justified.

You keep missing the fact that the GPL is meant to protect the USER's
right to play with the software. Read about Tivoization.

As far as the rights of the author, the GPL basically just protect's
the author's wish that his software be distributed under the GPL.

Re: Why not contribute? (to GCC)

[Olivier Galibert]

On Mon, Apr 26, 2010 at 02:00:30PM -0400, Richard Kenner wrote:
> Olivier Galibert wrote:
> > You can't force some entity to release source code they have
> > copyright to, that's not part of the legal remedies that are
> > available to a judge.
> 
> What makes you say that?

The law, *duh*

> Why couldn't that be a legal remedy?

Because it hasn't be voted so.

To stay US-centric, have a look at:
  http://www.copyright.gov/title17/92chap5.html

Any law that makes something illegal has to define the available
penalties associated.  Otherwise it's not a law, it's just a
non-binding statement on intent.  Everything else is of the domain of
the settlement, i.e. something to which both parties agree and the
judge considers fair.  And settlement-wise, releasing source and
assigning copyright are at exactly the same level, i.e. something the
opponent can accept or not, and if not decide to try their luck with
the legal remedies.

  OG.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> To stay US-centric, have a look at:
>   http://www.copyright.gov/title17/92chap5.html
> 
> Any law that makes something illegal has to define the available
> penalties associated. 

You are confusing criminal and civil law.  What you say is certainly true
for criminal law, where the other party is the government.  But in a civil
dispute between two entities, there are few limits on what can be ordered
to remedy an "injury".  What you site are a list (not meant to be complete)
of possible sanctions in the case of pure copyright infringement.  But
normally when there's a copyright dispute between two entities, there
are OTHER claims alleged too.

This is getting WAY off topic ...

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Chris Lattner <clattner@apple.com> writes:

> w.r.t. "hoarding", I'll point out that (in the context of GCC) being
> able to enforce copyright is pretty useless IMO.  While you can
> force someone to release their code, the GPL doesn't force them to
> assign the copyright to the FSF.  In practice this means that you
> can force someone to release their GCC changes, but you can't merge
> them back to mainline GCC.  In a warped way you could argue that the
> FSF using the GPL encourages their software to fork :-)

Again, just for the record.  History shows that this is not entirely
useless.  People at NeXT wrote the Objective C frontend to GCC.  They
did not intend to release the source code.  The FSF objected.  In the
end, NeXT wound up contributing the code, and that is why GCC has an
Objective C frontend.  In other words, the whole process worked as the
GPL intended.

Ian

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 26, 2010, at 12:23 PM, Ian Lance Taylor wrote:

> Chris Lattner <clattner@apple.com> writes:
> 
>> w.r.t. "hoarding", I'll point out that (in the context of GCC) being
>> able to enforce copyright is pretty useless IMO.  While you can
>> force someone to release their code, the GPL doesn't force them to
>> assign the copyright to the FSF.  In practice this means that you
>> can force someone to release their GCC changes, but you can't merge
>> them back to mainline GCC.  In a warped way you could argue that the
>> FSF using the GPL encourages their software to fork :-)
> 
> Again, just for the record.  History shows that this is not entirely
> useless.  People at NeXT wrote the Objective C frontend to GCC.  They
> did not intend to release the source code.  The FSF objected.  In the
> end, NeXT wound up contributing the code, and that is why GCC has an
> Objective C frontend.  In other words, the whole process worked as the
> GPL intended.

This is a often repeated example, but you're leaving out the big part of the story (at least as far as I know).  The license *did not* force the ObjC frontend to be merged back into GCC, there were other factors at work.  This 'victory' has nothing to do with the license, but it did cause them to release the code.

Beyond that, the changes to support Objective C 2.0 (and later) have never been merged back in, despite being published and widely available under the GPL.  Also, the GNU runtime and the NeXT runtimes are wildly incompatible, and the ObjC frontend in GCC is one of the most disliked (I'll leave out the pejoratives :) because its design has not kept up with the other front-ends.

Even in the shining example of the GPL succeeding, are you sure it was a good thing in retrospect? :)  

-Chris

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Chris Lattner <clattner@apple.com> writes:

> On Apr 26, 2010, at 12:23 PM, Ian Lance Taylor wrote:
>> 
>> Again, just for the record.  History shows that this is not entirely
>> useless.  People at NeXT wrote the Objective C frontend to GCC.  They
>> did not intend to release the source code.  The FSF objected.  In the
>> end, NeXT wound up contributing the code, and that is why GCC has an
>> Objective C frontend.  In other words, the whole process worked as the
>> GPL intended.
>
> This is a often repeated example, but you're leaving out the big
> part of the story (at least as far as I know).  The license *did
> not* force the ObjC frontend to be merged back into GCC, there were
> other factors at work.  This 'victory' has nothing to do with the
> license, but it did cause them to release the code.

Yes.  I was pointing out that forcing the release of the code *also*
caused the code to be contributed to the FSF.  As you say, other
factors were at work, but that's OK: there are always other factors.


> Beyond that, the changes to support Objective C 2.0 (and later) have
> never been merged back in, despite being published and widely
> available under the GPL.  Also, the GNU runtime and the NeXT
> runtimes are wildly incompatible, and the ObjC frontend in GCC is
> one of the most disliked (I'll leave out the pejoratives :) because
> its design has not kept up with the other front-ends.
>
> Even in the shining example of the GPL succeeding, are you sure it
> was a good thing in retrospect? :)

That is due to a different set of other factors.  Objective C is not a
shining example of the GPL succeeding.  But it is an example of a case
where the GPL forced release of code *and* it was contributed to gcc,
which is exactly the case that you were skeptical of.

In other words: theory says one thing will happen ("GPL encourages
[FSF] software to fork"); history shows that a different thing
happened.  I'm a pragmatist; given a reasonable choice, I prefer
history over theory.

Ian

Re: Why not contribute? (to GCC)

[Chris Lattner]

On Apr 26, 2010, at 1:53 PM, Ian Lance Taylor wrote:

>> Beyond that, the changes to support Objective C 2.0 (and later) have
>> never been merged back in, despite being published and widely
>> available under the GPL.  Also, the GNU runtime and the NeXT
>> runtimes are wildly incompatible, and the ObjC frontend in GCC is
>> one of the most disliked (I'll leave out the pejoratives :) because
>> its design has not kept up with the other front-ends.
>> 
>> Even in the shining example of the GPL succeeding, are you sure it
>> was a good thing in retrospect? :)
> 
> That is due to a different set of other factors.  Objective C is not a
> shining example of the GPL succeeding.  But it is an example of a case
> where the GPL forced release of code *and* it was contributed to gcc,
> which is exactly the case that you were skeptical of.
> 
> In other words: theory says one thing will happen ("GPL encourages
> [FSF] software to fork"); history shows that a different thing
> happened.  I'm a pragmatist; given a reasonable choice, I prefer
> history over theory.

Heh, ok, but if you're looking for history, look at both sides of it. 

<deleted>

I wrote a long and detailed email about GCC forks, long term corporate branches, the impact of the GPL on all this, etc.  However, it is so off topic, I'm happy to just delete it and drop the issue :-)

-Chris

Re: Why not contribute? (to GCC)

[Toon Moene]

On 04/26/2010 10:53 PM, Ian Lance Taylor wrote:

> Chris Lattner<clattner@apple.com>  writes:

>> This is a often repeated example, but you're leaving out the big
>> part of the story (at least as far as I know).  The license *did
>> not* force the ObjC frontend to be merged back into GCC, there were
>> other factors at work.  This 'victory' has nothing to do with the
>> license, but it did cause them to release the code.
>
> Yes.  I was pointing out that forcing the release of the code *also*
> caused the code to be contributed to the FSF.  As you say, other
> factors were at work, but that's OK: there are always other factors.

There's a funny side effect here:

One of the major reasons I bought a NeXT Station in November 1991 was 
that I considered NeXT's move to use free software a significant point 
on the scale of "doing something differently from the rest".

Little did I know the problems that were underlying these decisions.

Which made me one of the ~ 10,000 proud owners of a NeXT Station (now 
retired) at the cost of a reasonably sized family car :-)

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: Why not contribute? (to GCC)

[Mark Mielke]

On 04/26/2010 03:23 PM, Ian Lance Taylor wrote:
> Chris Lattner<clattner@apple.com>  writes
>> w.r.t. "hoarding", I'll point out that (in the context of GCC) being
>> able to enforce copyright is pretty useless IMO.  While you can
>> force someone to release their code, the GPL doesn't force them to
>> assign the copyright to the FSF.  In practice this means that you
>> can force someone to release their GCC changes, but you can't merge
>> them back to mainline GCC.  In a warped way you could argue that the
>> FSF using the GPL encourages their software to fork :-)
>>      
> Again, just for the record.  History shows that this is not entirely
> useless.  People at NeXT wrote the Objective C frontend to GCC.  They
> did not intend to release the source code.  The FSF objected.  In the
> end, NeXT wound up contributing the code, and that is why GCC has an
> Objective C frontend.  In other words, the whole process worked as the
> GPL intended.

This presumes that NeXT would not have discovered the value of free 
software and done the right thing eventually anyways. I think anybody 
who truly believes in free software should believe in it for practical 
reasons. It's not just a religion - it's the right way to do business. 
Business can understand dollars, and free software can be demonstrated 
to provide value in terms of $$$.

I think anybody who truly believes in the *merit* of free software, 
should be approaching companies who do not understand the merit with a 
business plan, not a class action law suit.

Of course, if you don't believe in the *merit* of free software, and 
just think it's something cool to screw around with and force ideas down 
other people's throats -- Feel free to pursue the class action law suit 
approach, or consolidate ownership with the FSF and make it a straight 
forward law suit instead.

Cheers,
mark

P.S. Objective C in particular has a sour taste in my mouth, as it seems 
to be a key component to Apple's vendor lock in strategy. If you can't 
lock people in through closed source - just choose a barely used open 
source project extension to base the entire front end of your software 
on and cross your fingers the rest of the world won't bother to catch up 
any time soon because it is simply too much effort.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I think anybody who truly believes in the *merit* of free software, 
> should be approaching companies who do not understand the merit with a 
> business plan, not a class action law suit.

Most certainly.  And a number of companies have relicensed their software
under the GPL when presented with a business plan showing why that's a
good thing to do.  But that doesn't mean you give up the right to sue
when somebody infringes a copyright.

It's like international relations.  We all hope that disputes between
nations can be settled using diplomacy, but nobody's willing to give up
their armed forces because of a belief that ALL can be solved that way.

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Mark Mielke <mark@mark.mielke.cc> writes:

> This presumes that NeXT would not have discovered the value of free
> software and done the right thing eventually anyways. I think anybody
> who truly believes in free software should believe in it for practical
> reasons. It's not just a religion - it's the right way to do
> business. Business can understand dollars, and free software can be
> demonstrated to provide value in terms of $$$.
>
> I think anybody who truly believes in the *merit* of free software,
> should be approaching companies who do not understand the merit with a
> business plan, not a class action law suit.
>
> Of course, if you don't believe in the *merit* of free software, and
> just think it's something cool to screw around with and force ideas
> down other people's throats -- Feel free to pursue the class action
> law suit approach, or consolidate ownership with the FSF and make it a
> straight forward law suit instead.
>
> Cheers,
> mark
>
> P.S. Objective C in particular has a sour taste in my mouth, as it
> seems to be a key component to Apple's vendor lock in strategy. If you
> can't lock people in through closed source - just choose a barely used
> open source project extension to base the entire front end of your
> software on and cross your fingers the rest of the world won't bother
> to catch up any time soon because it is simply too much effort.


This subthread no longer has anything to do with gcc.

Ian

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 17:04, Chris Lattner <clattner@apple.com> wrote:
> On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
>>>>>
>>>>> On what do you base these assertions?  Every point seems wrong to me.
>>>>
>>>> Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
>>>
>>> The key distinction is that contributing to LLVM does not require you to sign a form (which isn't even publicly available) and mail it in to a busy and high-latency organization before non-trivial patches will be accepted.
>>
>> So, is the copyright disclaimer implicit in the patch submission? Who
>> defines the conditions?
>
> That web page is everything that there is.  I am aware that this is not as legally air-tight as the FSF disclaimer, but empirically many companies seem to have no problem with it.

So, the copyright transfer is implicit in the patch submission
process. And any submitter that does not have a legal document stating
that his employer company allows the submitter to send that particular
code to LLVM is exposed to be sued not only by his/her employer but
also by the U. of Illinois. Nice.

I can understand companies not having problem with it. If something
goes wrong, they can always blame the employee because there is no
paper proving he or she had permission from his/her employer. Perhaps
the FSF is a bit too cautious, but this rings as a bit reckless. I
find surprising that the U. of Illinois has such relaxed approach to
copyright. But perhaps it is also in their interest to not ask many
questions. If something goes bad, they can just sue the individual
contributor rather than dealing with the whole legal department of a
company. Even more, if the company sues the contributor but not the U.
of Illinois, they may even get to keep the code. Sweet.

Have you made a poll in LLVM asking how many contributors actually
have some legal paper allowing them to contribute? That is how many
are currently legally exposed to a lawsuit. Would LLVM remove code if
a contributor starts doubting his legal position?

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> I find surprising that the U. of Illinois has such relaxed approach to
> copyright. But perhaps it is also in their interest to not ask many
> questions. If something goes bad, they can just sue the individual
> contributor rather than dealing with the whole legal department of a
> company. Even more, if the company sues the contributor but not the U.
> of Illinois, they may even get to keep the code. Sweet.

A University is a big place.  Do we know that their legal department is
even AWARE of this?  Or did some group within the University who doesn't
understand copyright law just decide this is the "right way to do it"?

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sun, Apr 25, 2010 at 7:23 PM, Richard Kenner
<kenner@vlsi1.ultra.nyu.edu> wrote:
>> I find surprising that the U. of Illinois has such relaxed approach to
>> copyright. But perhaps it is also in their interest to not ask many
>> questions. If something goes bad, they can just sue the individual
>> contributor rather than dealing with the whole legal department of a
>> company. Even more, if the company sues the contributor but not the U.
>> of Illinois, they may even get to keep the code. Sweet.
>
> A University is a big place.  Do we know that their legal department is
> even AWARE of this?  Or did some group within the University who doesn't
> understand copyright law just decide this is the "right way to do it"?

Whatever their reasons, this has very little to do with GCC. If
copyright assignment is an obstacle for contributing to GCC, we should
do something about that (clarify the reasons, simplify and speed up
the process, etc.). Let's talk about that instead :-)

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Whatever their reasons, this has very little to do with GCC. If
> copyright assignment is an obstacle for contributing to GCC, we should
> do something about that (clarify the reasons, simplify and speed up
> the process, etc.). Let's talk about that instead :-)

This discussion is part of "clarify the reasons".

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > Quoting from the link: http://llvm.org/docs/DeveloperPolicy.html
> 
> The key distinction is that contributing to LLVM does not require you to
> sign a form (which isn't even publicly available) and mail it in to a busy
> and high-latency organization before non-trivial patches will be accepted.

I'm confused.  If nothing's signed, then how is the copyright being
assigned?

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Chris Lattner <clattner@apple.com> writes:

> The key distinction is that contributing to LLVM does not require
> you to sign a form (which isn't even publicly available) and mail it
> in to a busy and high-latency organization before non-trivial
> patches will be accepted.

For the record (Chris probably knows this), the exact copyright forms
are no longer posted online because in practice it often slowed down
the copyright assignment process.  Contributors routinely downloaded
the wrong form and arranged to have it signed by their employer.  When
the FSF received the wrong form, they had to request a different form,
and the contributors had to go through the signing process again.

That is, the forms are not publically available not because they are
secret, but to avoid confusion because international law is
unavoidably complex.  This fear of confusion is based not on
hypothesis, but on actual experience.

Instead, the process is to fill out a "request for assignment"
form--those forms are publically available--and the FSF will send you
the correct form.  For most contributors, the correct "request for
assignment" form may be found here:

http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future


I agree that this is all far more complex and time consuming than it
ought to be.  I hope that the SC can work with the FSF to simplify the
process.  However, the legalities are there for a reason, as seen by
the copyright challenge from Unipress long ago and the SCO lawsuit
against the Linux kernel.  Apple and the University of Illinois are
taking a risk by permitting patches without any paperwork.  It's a low
probability risk, but it's one that the FSF wants to avoid based on
actual past experience.

Ian

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > BTW, in this aspect there is no difference between GCC and LLVM. The
> > latter also requires to assign copyright to the University of
> > Illinois. If you don't have a copyright disclaimer before contributing
> > to LLVM, you are exposing yourself to some future legal troubles.
> 
> On what do you base these assertions?  Every point seems wrong to me.

The latter point is certainly true.  If you work for a company and submit
a patch to ANY project without having a disclaimer, the company can later
sue you, claiming that it owned the copyright to the material that you
submitted.  The only different is who the disclaimer protects: if you
are assigning the patches to an entity (e.g., the FSF) then the disclaimer
protects the FSF.  If you're NOT assigning the patches to somebody, the
disclaimer protects YOU.  Either way, a disclaimer is required.

Re: Why not contribute? (to GCC)

[HyperQuantum]

On Fri, Apr 23, 2010 at 8:39 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> This seems to be the question running around the blogosphere for
> several projects. And I would like to ask all people that read this
> list but hardly say or do anything.
>
> What reasons keep you from contributing to GCC?

The lack of time, for the most part. For GCC there are other reasons as well:

- the paperwork. I cannot just submit a patch if I feel like it.
- not easy to find something to contribute. Stuff that is either not
interesting to me, or too difficult for me to easily get into. GCC is
a mature project, so there aren't much 'holes to fill' (at first
sight, for a beginner).
- the programming language. I don't have any experience with C, I only
know some things about it because it's a subset of C++.

And I'm also watching other projects. I cannot contribute to all.
Well, actually I don't contribute to any project right now. Since I
started programming for my day job I don't really feel like
programming in the evenings or weekends anymore. Before that I spent
most of my free time working on my own project, my programming
language. But now I don't even have time to work on that anymore.

Re: Why not contribute? (to GCC)

[HyperQuantum]

On Fri, Apr 23, 2010 at 9:58 PM, HyperQuantum <hyperquantum@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 8:39 PM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:

>> What reasons keep you from contributing to GCC?
>
> The lack of time, for the most part.

I submitted a feature request once. It's now four years old, still
open, and the last message it received was two years ago. (PR26061)

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 23 April 2010 22:05, HyperQuantum <hyperquantum@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 9:58 PM, HyperQuantum <hyperquantum@gmail.com> wrote:
>> On Fri, Apr 23, 2010 at 8:39 PM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>
>>> What reasons keep you from contributing to GCC?
>>
>> The lack of time, for the most part.
>
> I submitted a feature request once. It's now four years old, still
> open, and the last message it received was two years ago. (PR26061)

I actually implemented that patch and got rejected. I may try again in
the future but there are more important things that I would like to
implement first. The fact that is still open means that given the
right patch and the right convincing, it may get accepted. That
feature is simply not important enough for me to put more time. Is it
for you?

But is that a reason to not contribute? Precisely, we need more
contributors because the existing contributors are already overworked
with big projects and don't have time to fight/worry for small
fixes/features. For sure you can find unconfirmed bug reports much
older that have simply been overlooked for more than 10 years.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Paweł Sikora]

On Friday 23 April 2010 22:05:56 HyperQuantum wrote:
> On Fri, Apr 23, 2010 at 9:58 PM, HyperQuantum <hyperquantum@gmail.com> 
wrote:
> > On Fri, Apr 23, 2010 at 8:39 PM, Manuel López-Ibáñez
> > 
> > <lopezibanez@gmail.com> wrote:
> >> What reasons keep you from contributing to GCC?
> > 
> > The lack of time, for the most part.
> 
> I submitted a feature request once. It's now four years old, still
> open, and the last message it received was two years ago. (PR26061)

i'm trying to contribute to gcc/glibc via testing on my codebase
and... i have abandoned/rejected long standing PRs too :(

e.g:
http://gcc.gnu.org/PR20128
http://gcc.gnu.org/PR28811
http://gcc.gnu.org/PR28854
http://gcc.gnu.org/PR36568 vs. http://sourceware.org/PR6693

people don't like wait for a years for bug classification/fixing ;)

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 23 April 2010 22:23, Paweł Sikora <pluto@agmk.net> wrote:
> On Friday 23 April 2010 22:05:56 HyperQuantum wrote:
>> On Fri, Apr 23, 2010 at 9:58 PM, HyperQuantum <hyperquantum@gmail.com>
> wrote:
>> > On Fri, Apr 23, 2010 at 8:39 PM, Manuel López-Ibáñez
>> >
>> > <lopezibanez@gmail.com> wrote:
>> >> What reasons keep you from contributing to GCC?
>> >
>> > The lack of time, for the most part.
>>
>> I submitted a feature request once. It's now four years old, still
>> open, and the last message it received was two years ago. (PR26061)
>
> i'm trying to contribute to gcc/glibc via testing on my codebase
> and... i have abandoned/rejected long standing PRs too :(
>
> e.g:
> http://gcc.gnu.org/PR20128
> http://gcc.gnu.org/PR28811
> http://gcc.gnu.org/PR28854
> http://gcc.gnu.org/PR36568 vs. http://sourceware.org/PR6693
>
> people don't like wait for a years for bug classification/fixing ;)

You can find this in every software project that has an userbase
larger than the developer base, free-software or proprietary. You can
find this in every large and mature free-software project. In the
proprietary world there is little you can do. In the free-software
world, you can actually help to fix it. To alleviate this problem (it
will never go away), we need more contributors. Wanna help?

In any case, I think coming from you it is a bit hurtful because I
have personally fixed many of your bugs and I haven't seen a single
beer yet! Where is my beer?

Manuel.

Re: Why not contribute? (to GCC)

[Michael Witten]

On Fri, Apr 23, 2010 at 15:36, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> In any case, I think coming from you it is a bit hurtful because I
> have personally fixed many of your bugs and I haven't seen a
> single beer yet! Where is my beer?

Where's his beer for finding bugs?

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 23 April 2010 22:44, Michael Witten <mfwitten@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 15:36, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>> In any case, I think coming from you it is a bit hurtful because I
>> have personally fixed many of your bugs and I haven't seen a
>> single beer yet! Where is my beer?
>
> Where's his beer for finding bugs?

I don't complain that he doesn't find more and better bugs. I don't
request him to find *my* bugs.

Anyway, this is off-topic, and stop trying to incite people to fight,
in this and other threads, please. It is not the first time you do it.
If you just hate gcc so much, just leave. Thanks,

Manuel.

Re: Why not contribute? (to GCC)

[Michael Witten]

On Fri, Apr 23, 2010 at 15:58, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 23 April 2010 22:44, Michael Witten <mfwitten@gmail.com> wrote:
>> On Fri, Apr 23, 2010 at 15:36, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>>> In any case, I think coming from you it is a bit hurtful because I
>>> have personally fixed many of your bugs and I haven't seen a
>>> single beer yet! Where is my beer?
>>
>> Where's his beer for finding bugs?
>
> I don't complain that he doesn't find more and better bugs. I don't
> request him to find *my* bugs.

I was pointing out that he too has provided a service to the project.

>
> Anyway, this is off-topic, and stop trying to incite people to fight,
> in this and other threads, please. It is not the first time you do it.
> If you just hate gcc so much, just leave. Thanks,

I don't know what you're talking about.

If anything, your comments have been off-topic and inciteful.

Re: Why not contribute? (to GCC)

[Jonathan Wakely]

On 23 April 2010 22:49, Michael Witten <mfwitten@gmail.com> wrote:
>>
>> Anyway, this is off-topic, and stop trying to incite people to fight,
>> in this and other threads, please. It is not the first time you do it.
>> If you just hate gcc so much, just leave. Thanks,
>
> I don't know what you're talking about.

Probably this: http://gcc.gnu.org/ml/gcc/2010-04/msg00542.html

Re: Why not contribute? (to GCC)

[Paweł Sikora]

On Friday 23 April 2010 22:36:21 Manuel López-Ibáñez wrote:

> (...). In the free-software world, you can actually help to fix it.
> (...) we need more contributors. Wanna help?

i haven't so much free time (c++work/family/studies) for learn internal
gcc structures and non-trivial design to start full power contributing.
i'm doing what i can at this point of my gcc knowledge and currently
i'm focused on testing each gcc release on my work codebase and isolating
testcases which is also hard and ugly piece of work. e.g, from few months
i'm trying to isolate a fancy (i think) gcc wrong-code bug (at -O0! on
4.4/4.5 while -O2 on 4.3 works fine) that causes memory over(under)runs
in very big C++/EDA software. long dancing in free time with gdb, valgrind
and electric fence is my little contribution to the quality of g++
- my favourite compiler. 

from the rookie point of view i can say that the new gcc plugin framework
is a fantastic tool for learning gcc internals on the fly via debugging
when partial information on the onlinedocs/gccint/GENERIC are not enough.
this process could be improved by gdb7 python based pretty printers which
e.g. allow easier 'tree' union analyzing.

> In any case, I think coming from you it is a bit hurtful because I
> have personally fixed many of your bugs and I haven't seen a single
> beer yet!

no offence please but that weren't my bugs but compiler bugs :-)
your effort in fixing gcc-bad/false-warnings is great and keep
the "-Wall -Werror" still usable for large projects.
once again many thanks!

btw. i have another PR in this area. wanna help? :-)

> Where is my beer?

http://www.bigstockphoto.com/image-298233/stock-photo-beer-drinking-emoticon
:-)

BR,
Pawel.

Re: Why not contribute? (to GCC)

[Andi Hellmund]

Hey,

are these documents, copyright assignment and employer disclaimer, 
publicly available in the WEB or do I need to explicitly request these 
documents?

I plan to start contributing in the near future and I'm currently in the 
process to get the approval from my employer. After getting the company 
approval, the next obvious step would be to sign these FSF documents.

If someone could send me a link (I searched through the web but couldn't 
find any links at GCC, GNU and FSF) would be really helpful ...

Thanks,
Andi

Re: Why not contribute? (to GCC)

[Joseph S. Myers]

On Sat, 24 Apr 2010, Andi Hellmund wrote:

> Hey,
> 
> are these documents, copyright assignment and employer disclaimer, publicly
> available in the WEB or do I need to explicitly request these documents?
> 
> I plan to start contributing in the near future and I'm currently in the
> process to get the approval from my employer. After getting the company
> approval, the next obvious step would be to sign these FSF documents.
> 
> If someone could send me a link (I searched through the web but couldn't find
> any links at GCC, GNU and FSF) would be really helpful ...

http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright

The relevant form is normally request-assign.future.  I don't know if the 
document that the FSF will send you when you send them 
request-assign.future is available online (there are certainly various 
forms that aren't included in gnulib git).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Why not contribute? (to GCC)

[Richard Kenner]

> http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright
> 
> The relevant form is normally request-assign.future.  I don't know if the 
> document that the FSF will send you when you send them 
> request-assign.future is available online (there are certainly various 
> forms that aren't included in gnulib git).

Although the wording to describe what's being assigned varies slightly
between the documents, if you're interested in knowing what the terms
of the asignments and disclaimers are, any of the assign.* and
disclaim.* documents (respectively) will give you that.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 12:39, Paweł Sikora <pluto@agmk.net> wrote:
> On Friday 23 April 2010 22:36:21 Manuel López-Ibáñez wrote:
>
>> (...). In the free-software world, you can actually help to fix it.
>> (...) we need more contributors. Wanna help?
>
> i haven't so much free time (c++work/family/studies) for learn internal

And who has free time? I am not your boss or your customer, and you
are not mine. Raising awareness about existing bugs is one thing.
Demanding (some people angrily) that they get fixed is another. This
is something that I didn't understand completely until I started
contributing to gcc. And it caused me a lot of frustration.

If you can only contribute bug reports, ok, that is fine, but we also
need people that contribute to fix those bugs. Otherwise there will be
more open bug reports than people fixing them.

> btw. i have another PR in this area. wanna help? :-)

I am specially busy nowadays and a long queue of patches that I would
like to finish, test and submit. But you can always add
manu@gcc.gnu.org to the CC and then it will be in my (long) list of
things to look at.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Toon Moene]

Manuel López-Ibáñez wrote:

> And who has free time? I am not your boss or your customer, and you
> are not mine. Raising awareness about existing bugs is one thing.
> Demanding (some people angrily) that they get fixed is another. This
> is something that I didn't understand completely until I started
> contributing to gcc. And it caused me a lot of frustration.

I wonder what your day time job is.

Compared to *my* day time job, GCC development is a heaven of meritocracy.

Complaints are a dime a dozen - ignore them.

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: Why not contribute? (to GCC)

[Tim Prince]

On 4/23/2010 1:05 PM, HyperQuantum wrote:
> On Fri, Apr 23, 2010 at 9:58 PM, HyperQuantum<hyperquantum@gmail.com>  wrote:
>    
>> On Fri, Apr 23, 2010 at 8:39 PM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com>  wrote:
>>      
>    
>>> What reasons keep you from contributing to GCC?
>>>        
>> The lack of time, for the most part.
>>      
> I submitted a feature request once. It's now four years old, still
> open, and the last message it received was two years ago. (PR26061)
>    
The average time for acceptance of a PR with a patch submission from an 
outsider such as ourselves is over 2 years, and by then the patch no 
longer fits, has to be reworked, and is about to become moot.
I still have the FSF paperwork in force, as far as I know, from over a 
decade ago, prior to my current employment.  Does it become valid again 
upon termination of employment?  My current employer has no problem with 
the FSF paperwork for employees whose primary job is maintenance of gnu 
software (with committee approval), but this does not extend to those of 
us for whom it is a secondary role.  There once was a survey requesting 
responses on how our FSF submissions compared before and after current 
employment began, but no summary of the results.

-- 
Tim Prince

Re: Why not contribute? (to GCC)

[Dave Korn]

On 24/04/2010 02:39, Tim Prince wrote:

> The average time for acceptance of a PR with a patch submission from an
> outsider such as ourselves is over 2 years, 

  By "average", do you mean that you have taken records of many different
patch submissions from many different "outsiders", measured the durations of
the process from initial submission up to being committed into the repository,
and calculated the average duration of the distribution?  If so, which kind,
mean or median?  And what was the sample size?  Did you use any kind of
weighting to adjust for the size and complexity of the patch, or did you rate
all patches equally?  What basis did you use to decide who counts as an
outsider, and who does not? Is your methodology documented?

  Or do you mean something else?

    cheers,
      DaveK

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 23 April 2010 21:58, HyperQuantum <hyperquantum@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 8:39 PM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>> This seems to be the question running around the blogosphere for
>> several projects. And I would like to ask all people that read this
>> list but hardly say or do anything.
>>
>> What reasons keep you from contributing to GCC?
>
> The lack of time, for the most part. For GCC there are other reasons as well:

Not even a sunday afternoon from time to time, instead of watching TV? ;-)

> - the paperwork. I cannot just submit a patch if I feel like it.

This you have to do once and it is done.

> - not easy to find something to contribute. Stuff that is either not
> interesting to me, or too difficult for me to easily get into. GCC is
> a mature project, so there aren't much 'holes to fill' (at first
> sight, for a beginner).

There are a lot of mini-projects in the wiki:

http://gcc.gnu.org/wiki/SummerOfCode

And many stupid bugs in bugzilla.

I am sure that if you say what you would be interested to do, people
will have a thousand mini-projects for you and some developers will
offer to mentor you.

> - the programming language. I don't have any experience with C, I only
> know some things about it because it's a subset of C++.

You said it is a subset! Precisely the controversy about moving to C++
(hey! you can find more mini-projects here:
http://gcc.gnu.org/wiki/gcc-in-cxx ) is the other way around: People
do not want to learn the new things of C++. If you know C++, you know
99% of C, then it is just getting used to what you cannot do in C.

> And I'm also watching other projects. I cannot contribute to all.
> Well, actually I don't contribute to any project right now. Since I
> started programming for my day job I don't really feel like
> programming in the evenings or weekends anymore. Before that I spent
> most of my free time working on my own project, my programming
> language. But now I don't even have time to work on that anymore.

Fair enoug. But still, you are subscribed to this list. That must mean
something ;-)

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Michael Witten]

On Fri, Apr 23, 2010 at 13:39, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> What reasons keep you from contributing to GCC?

I'm really quite the outsider (I don't even deserve to be called a
"lurker"), but my impression is that the common wisdom among the
proles is that gcc is bloated and crufty and everyone is just waiting
for a switch-over to something "new and clean and efficient" like the
LLVM/Clang.

Maybe GCC needs a good Public Relations campaign.

Re: Why not contribute? (to GCC)

[Florian Weimer]

* Manuel López-Ibáñez:

> What reasons keep you from contributing to GCC?

My most recent case: I could not make my needs meet with those of
fringe/embedded architectures, so my little work on a patch led to
nowhere (as of now).

Re: Why not contribute? (to GCC)

[Russ Allbery]

Manuel López-Ibáñez <lopezibanez@gmail.com> writes:

> This seems to be the question running around the blogosphere for several
> projects. And I would like to ask all people that read this list but
> hardly say or do anything.

> What reasons keep you from contributing to GCC?

The last time that I attempted to contribute to an FSF project (Autoconf,
many years ago), I got the legal paperwork for the employer component and
attempted to find someone at Stanford who was willing to sign it, entirely
without success.  It was quickly turning into a hassle that was going to
consume considerably more time than the time I would have spent working on
the contribution.

I'm sure that I could eventually work through the process, but for the
occasional and minor contributions that I would have time to make to FSF
projects, it's just not worth the time and energy.  There are many other
projects to contribute to that don't require this additional overhead.

I find the GCC project fascinating (in a largely positive way) as an
example of a large successful free software project and have been
following the mailing list since egcs, so I'm still following the mailing
list and learning a lot about project management and approval processes
and the like, and I really appreciate people doing that in public where
others can learn from it.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Why not contribute? (to GCC)

[Michael Veksler]

I have been lurking on this list for many years, probably a decade.
I like the progress of GCC and its technology, esp. algorithms and data 
structures,
which are exciting.

Yet, I do not contribute to GCC due to my priorities in life and not due 
to any other technicality. There is family, work, graduate studies 
(where I develop new constraint solver technologies) and dancing. Too 
many things too little time. GCC is currently below the other things in 
my list.

I could have tried to change my working place and to become a paid to 
develop for GCC, but it seems to be a feat too difficult for my part 
time job. I had played with these thoughts several years ago, before 
starting my graduate studies, and I don't really remember why I stayed 
at my current working place.

Michael

On 04/23/10 21:39, Manuel López-Ibáñez wrote:
> This seems to be the question running around the blogosphere for
> several projects. And I would like to ask all people that read this
> list but hardly say or do anything.
>
> What reasons keep you from contributing to GCC?
>
> Cheers,
>
> Manuel.
>
> PS: Actually, I am not sure how many people read this list and not contribute.
>
>    

Re: Why not contribute? (to GCC)

[Thomas Neumann]

> What reasons keep you from contributing to GCC?
I tried this a while ago, but ultimately gave up because I could not get my 
patches in. Some were applied, but many never made it. Admittedly they were 
perhaps not of general interested, there were only improving compatibility 
of the gcc base with C++ (what Ian Lance Taylor then did later).
The most frustrating part was not getting patches rejected (I could then 
improve them, after all), but having patches ignored. You submit a number of 
patches, and the result is... nothing. No response at all. Not exactly what 
encourages gcc as a free time activity.

On the other hand I am a professional developer, too (even working on 
compilers), and I myself would perhaps also be reluctant to spend time on 
reviewing and merging patches that I do not really care about. So I 
understand the gcc developers. But it is still frustrating for outsiders.

Thomas

Re: Why not contribute? (to GCC)

[Joel Sherrill]

On 04/24/2010 02:35 PM, Thomas Neumann wrote:
>> What reasons keep you from contributing to GCC?
>>      
> I tried this a while ago, but ultimately gave up because I could not get my
> patches in. Some were applied, but many never made it. Admittedly they were
> perhaps not of general interested, there were only improving compatibility
> of the gcc base with C++ (what Ian Lance Taylor then did later).
> The most frustrating part was not getting patches rejected (I could then
> improve them, after all), but having patches ignored. You submit a number of
> patches, and the result is... nothing. No response at all. Not exactly what
> encourages gcc as a free time activity.
>
>    
And this is the type of problem I was referring to as
"making the project approachable".  If timely patch review
and feedback is an issue, then we need to figure out a
workflow solution.

I am sure the people who need to review a particular patch
are busy enough that they won't necessarily go hunting for
work.  Maybe a patch triage team that assigns them to
the right person(s) for review.
> On the other hand I am a professional developer, too (even working on
> compilers), and I myself would perhaps also be reluctant to spend time on
> reviewing and merging patches that I do not really care about. So I
> understand the gcc developers. But it is still frustrating for outsiders.
>
>    
And I admit to often privately emailing the person I think
needs to review a patch I care about.  But a new person
wouldn't be comfortable doing that.  A triage step
and a tracking system for patches might help.

There is definitely a workflow problem though.  I have
had patches I submitted through Bugzilla which didn't
get reviewed until I was asked to submit them to
gcc-patches.  And vice-versa.  A triage team and
tracking system might have prevented this.

This is also an opportunity for persons to contribute.

--joel
> Thomas
>
>
>    

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 21:48, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>
> There is definitely a workflow problem though.  I have
> had patches I submitted through Bugzilla which didn't
> get reviewed until I was asked to submit them to
> gcc-patches.  And vice-versa.  A triage team and
> tracking system might have prevented this.

A patch tracking system would already be an improvement and it would
be fantastic if someone contributed such thing.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sat, Apr 24, 2010 at 10:23 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 24 April 2010 21:48, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>>
>> There is definitely a workflow problem though.  I have
>> had patches I submitted through Bugzilla which didn't
>> get reviewed until I was asked to submit them to
>> gcc-patches.  And vice-versa.  A triage team and
>> tracking system might have prevented this.
>
> A patch tracking system would already be an improvement and it would
> be fantastic if someone contributed such thing.

We had a patch tracking system, and it was completely ignored by most
maintainers.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 22:28, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>
> We had a patch tracking system, and it was completely ignored by most
> maintainers.

But *submitters* did use it until it went down. So it was useful for
tracking unreviewed patches, not for improving reviewing. Right now, I
have no way to check what unreviewed patches there may be interesting
for me apart from searching the gcc-patches mailing list. Even the
psychological effect of having your patch tracked somewhere instead of
completely ignored would be effective. Perhaps more importantly, it
showed which parts of the compiler were more in need of further
reviewers.

I think it was really bad that we lost the patch tracker.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Guenther]

On Sat, Apr 24, 2010 at 10:37 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 24 April 2010 22:28, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>>
>> We had a patch tracking system, and it was completely ignored by most
>> maintainers.
>
> But *submitters* did use it until it went down. So it was useful for
> tracking unreviewed patches, not for improving reviewing. Right now, I
> have no way to check what unreviewed patches there may be interesting
> for me apart from searching the gcc-patches mailing list. Even the
> psychological effect of having your patch tracked somewhere instead of
> completely ignored would be effective. Perhaps more importantly, it
> showed which parts of the compiler were more in need of further
> reviewers.
>
> I think it was really bad that we lost the patch tracker.

You can use bugzilla, the patch keyword and the URL field to track patches
for bugs.

Richard.

> Cheers,
>
> Manuel.
>

Re: Why not contribute? (to GCC)

[Richard Guenther]

On Sat, Apr 24, 2010 at 10:28 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Sat, Apr 24, 2010 at 10:23 PM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>> On 24 April 2010 21:48, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>>>
>>> There is definitely a workflow problem though.  I have
>>> had patches I submitted through Bugzilla which didn't
>>> get reviewed until I was asked to submit them to
>>> gcc-patches.  And vice-versa.  A triage team and
>>> tracking system might have prevented this.
>>
>> A patch tracking system would already be an improvement and it would
>> be fantastic if someone contributed such thing.
>
> We had a patch tracking system, and it was completely ignored by most
> maintainers.

Indeed - we do not need another piece of infrastructure.  Note that good
patch review takes a lot of time and we (unfortunately again) do not have
many active patch reviewers.  So it happens that patches from people
with excellent track history get approved quickly but others are just
left behind.  Pinging the patches does usually help here, as well as
working with maintainers during the patch creation so that the final
review is easy.

Richard.

> Ciao!
> Steven
>

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 22:37, Richard Guenther <richard.guenther@gmail.com> wrote:
>>
>> We had a patch tracking system, and it was completely ignored by most
>> maintainers.
>
> Indeed - we do not need another piece of infrastructure.  Note that good
> patch review takes a lot of time and we (unfortunately again) do not have
> many active patch reviewers.  So it happens that patches from people
> with excellent track history get approved quickly but others are just
> left behind.  Pinging the patches does usually help here, as well as
> working with maintainers during the patch creation so that the final
> review is easy.

But this is not a piece of infrastructure for reviewers but for *submitters*.

Anyway, the patch tracker is not the main point. The point is how we
alleviate this problem? You see that a few already mentioned that this
was a reason to NOT contribute to GCC. People that probably have
solved the legal issues, were knowledgeable enough to modify, build
and test GCC, and then submit a patch. And they left because of this.
That is sad.

Cheers,

Manuel.



>
> Richard.
>
>> Ciao!
>> Steven
>>
>

Re: Why not contribute? (to GCC)

[Andi Hellmund]

Richard Guenther wrote:

> Indeed - we do not need another piece of infrastructure.  Note that good
> patch review takes a lot of time and we (unfortunately again) do not have
> many active patch reviewers.  So it happens that patches from people
> with excellent track history get approved quickly but others are just
> left behind.  Pinging the patches does usually help here, as well as
> working with maintainers during the patch creation so that the final
> review is easy.
> 
> Richard.

This all sounds like a typical "dead-lock" problem. The projects 
obviously needs more patch reviewers, but to be qualified for a patch 
reviewer, you clearly require a _thorough_ understanding of the GCC 
internals. And I think to get this deep knowledge - at least for my 
person - I need the motivation to look and work through the source code 
to understand the internals. And to get this motivation or keep it up 
and running, I need to work productively on this project by submitting 
patches among others. Documentation is important and could make fun as 
well, but the real fun is to work on the code and submit - at one time - 
patches to the main line.

All the mentioned aspects sound somehow devastating for me that it is 
_that_ hard to get into the real contribution and I could generally 
understand that a lot of persons decided to NOT contribute.

Although some might think this is stupid SPAM, I think this thread is 
really good (Thanks Manuel!) to get an overview of the current 
"problems" of the GCC projects and what could be improved so that the 
project becomes more attractive to potential contributors.

A patch tracking system might basically be a good idea for contributors 
but it nevertheless doesn't solve the real problem, the limited amount 
and time of the patch reviewers!!!

Re: Why not contribute? (to GCC)

[Joel Sherrill]

On 04/24/2010 04:27 PM, Andi Hellmund wrote:
> Richard Guenther wrote:
>
>    
>> Indeed - we do not need another piece of infrastructure.  Note that good
>> patch review takes a lot of time and we (unfortunately again) do not have
>> many active patch reviewers.  So it happens that patches from people
>> with excellent track history get approved quickly but others are just
>> left behind.  Pinging the patches does usually help here, as well as
>> working with maintainers during the patch creation so that the final
>> review is easy.
>>
>> Richard.
>>      
> This all sounds like a typical "dead-lock" problem. The projects
> obviously needs more patch reviewers, but to be qualified for a patch
> reviewer, you clearly require a _thorough_ understanding of the GCC
> internals. And I think to get this deep knowledge - at least for my
> person - I need the motivation to look and work through the source code
> to understand the internals. And to get this motivation or keep it up
> and running, I need to work productively on this project by submitting
> patches among others. Documentation is important and could make fun as
> well, but the real fun is to work on the code and submit - at one time -
> patches to the main line.
>    
So we need more patch reviewers.  How can that be addressed?

It is also important to make more effective use of the patch
reviewers we already have.  What could be done to make the
patch review process easier or less time-consuming?
> All the mentioned aspects sound somehow devastating for me that it is
> _that_ hard to get into the real contribution and I could generally
> understand that a lot of persons decided to NOT contribute.
>    
Would a mentoring program of some type help?  I don't
know how to associate people who want to become a long
term part of GCC with the right people.
> Although some might think this is stupid SPAM, I think this thread is
> really good (Thanks Manuel!) to get an overview of the current
> "problems" of the GCC projects and what could be improved so that the
> project becomes more attractive to potential contributors.
>
>    
That's the goal.  And to make the workflow as easy as possible
for those who are already contributing.
> A patch tracking system might basically be a good idea for contributors
> but it nevertheless doesn't solve the real problem, the limited amount
> and time of the patch reviewers!!!
>
>    
Yep.  But both the submitter and reviewer sides of the patch
tracking are important.

--joel

Re: Why not contribute? (to GCC)

[Eric Botcazou]

> So we need more patch reviewers.  How can that be addressed?

The situation has improved in this area since the "Reviewer" position was 
introduced a few years ago though.

> It is also important to make more effective use of the patch
> reviewers we already have.  What could be done to make the
> patch review process easier or less time-consuming?

Write small patches.  Even if you know that the change is not a complete 
solution to the problem, it might be good enough as a first try so adding 
a ??? comment would be sufficient.

Eliminate the easy mistakes in patches.  GCC uses strict coding conventions, 
including formatting and commenting conventions, so not following them is a 
mistake that will be flagged as such.  Fortunately this is easy to correct, 
you don't even need to read the (whole) documentation, just look around in 
the existing code you're modifying and make it so that the new code cannot 
be distinguished from the old one in this respect.

Write proper ChangeLogs.  They are kind of executive summaries for patches and 
help to grasp what they do.  The various ChangeLog files have many examples.

-- 
Eric Botcazou

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Eliminate the easy mistakes in patches.  GCC uses strict coding conventions, 
> including formatting and commenting conventions, so not following them is a 
> mistake that will be flagged as such.  Fortunately this is easy to correct, 
> you don't even need to read the (whole) documentation, just look around in 
> the existing code you're modifying and make it so that the new code cannot 
> be distinguished from the old one in this respect.
> 
> Write proper ChangeLogs.  They are kind of executive summaries for patches
> and help to grasp what they do.  The various ChangeLog files have many
> examples.

Moreover, I think that having a patch that's improperly formatted or
missing or improper ChangeLog may simply cause reviewers to ignore the
patch because they don't want to have to deal with explaining these
things to people.  This SHOULDN'T happen, but I'm pretty sure it does.

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sun, Apr 25, 2010 at 3:00 PM, Richard Kenner
<kenner@vlsi1.ultra.nyu.edu> wrote:
>> Eliminate the easy mistakes in patches.  GCC uses strict coding conventions,
>> including formatting and commenting conventions, so not following them is a
>> mistake that will be flagged as such.  Fortunately this is easy to correct,
>> you don't even need to read the (whole) documentation, just look around in
>> the existing code you're modifying and make it so that the new code cannot
>> be distinguished from the old one in this respect.
>>
>> Write proper ChangeLogs.  They are kind of executive summaries for patches
>> and help to grasp what they do.  The various ChangeLog files have many
>> examples.
>
> Moreover, I think that having a patch that's improperly formatted or
> missing or improper ChangeLog may simply cause reviewers to ignore the
> patch because they don't want to have to deal with explaining these
> things to people.  This SHOULDN'T happen, but I'm pretty sure it does.

In the aerospace industry we have a somewhat similar problem. Every
part of assembly drawing has to be reviewed ("checked") and approved.
But the common mistakes often are so distracting that checkers don't
even want to begin to comment on to-be-released drawing in the PDM
system. It is very demotivating to review something and you're just
pointing out issues with formalities instead of focusing on the actual
design.

The solution for this in my working environment is an automatic
checker. This checker validates the drawing against a set of
requirements (proper design principles, proper drawing formatting,
correct label, etc.). You can't upload a drawing for check in the PDM
system until it passes the checker (it is part of the PDM system, and
it simply rejects drawings that don't pass).

Perhaps it is possible to create some kind of check-patch script for
GCC too, e.g. one that checks the following things at least:
* ChangeLog presence
* ChangeLog format and completeness
* formatting / coding style of the patch itself

We should perhaps make tools available in contrib/ that help people
set up things properly for patch submission. For example Diego had a
script that extracts a skeleton ChangeLog from a patch, perhaps it
should be put in contrib/ and advertised somewhere (e.g. wiki).

There are many things beside this that we could do to simplify the
patch submission process. It's just part of the problem but perhaps it
helps.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Ralf Wildenhues]

I don't like self-advertising, but ...

* Steven Bosscher wrote on Sun, Apr 25, 2010 at 03:05:45PM CEST:
> Perhaps it is possible to create some kind of check-patch script for
> GCC too, e.g. one that checks the following things at least:
> * ChangeLog presence
> * ChangeLog format and completeness
> * formatting / coding style of the patch itself
> 
> We should perhaps make tools available in contrib/ that help people
> set up things properly for patch submission. For example Diego had a
> script that extracts a skeleton ChangeLog from a patch, perhaps it
> should be put in contrib/ and advertised somewhere (e.g. wiki).

FWIW, I wrote vc-chlog a while ago (ships together with vc-dwim[1]) which
IMVHO is fairly accurate at creating stub ChangeLog entries if you have
Exuberant Ctags installed.  Without it, updates to the GCC build system
would have been rather painful.

I would add blurb about it in the wiki if that is acceptable.

Cheers,
Ralf

[1] www.gnu.org/software/vc-dwim/

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> FWIW, I wrote vc-chlog a while ago (ships together with vc-dwim[1]) which
> IMVHO is fairly accurate at creating stub ChangeLog entries if you have
> Exuberant Ctags installed.  Without it, updates to the GCC build system
> would have been rather painful.
>
> I would add blurb about it in the wiki if that is acceptable.

Certainly acceptable for the wiki.  Thanks.

Ian

Re: Why not contribute? (to GCC)

[Richard Guenther]

On Sun, Apr 25, 2010 at 2:40 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> So we need more patch reviewers.  How can that be addressed?
>
> The situation has improved in this area since the "Reviewer" position was
> introduced a few years ago though.
>
>> It is also important to make more effective use of the patch
>> reviewers we already have.  What could be done to make the
>> patch review process easier or less time-consuming?
>
> Write small patches.  Even if you know that the change is not a complete
> solution to the problem, it might be good enough as a first try so adding
> a ??? comment would be sufficient.
>
> Eliminate the easy mistakes in patches.  GCC uses strict coding conventions,
> including formatting and commenting conventions, so not following them is a
> mistake that will be flagged as such.  Fortunately this is easy to correct,
> you don't even need to read the (whole) documentation, just look around in
> the existing code you're modifying and make it so that the new code cannot
> be distinguished from the old one in this respect.
>
> Write proper ChangeLogs.  They are kind of executive summaries for patches and
> help to grasp what they do.  The various ChangeLog files have many examples.

Do not followup your patch with new versions every other day.  Doing so
sticks with reviewers and so you get ignored until they are confident
enough their review time is not wasted.

Thus, be confident of your own patches!  Have them tested _before_
submitting them (well, if you're not in the small group of people that
patch reviewers forgive when doing so).  Test your patches on a
common target (like i?86/x86_64-linux).

Richard.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 21:35, Thomas Neumann <tneumann@users.sourceforge.net> wrote:
>> What reasons keep you from contributing to GCC?
> I tried this a while ago, but ultimately gave up because I could not get my
> patches in. Some were applied, but many never made it. Admittedly they were
> perhaps not of general interested, there were only improving compatibility
> of the gcc base with C++ (what Ian Lance Taylor then did later).
> The most frustrating part was not getting patches rejected (I could then
> improve them, after all), but having patches ignored. You submit a number of
> patches, and the result is... nothing. No response at all. Not exactly what
> encourages gcc as a free time activity.

Patches falling through the cracks is a well-known problem. Currently,
the only advice is insisting politely. Even a patch from a
long-standing contributor may require four or five pings. The person
in charge may not even be aware that the patch is for them because of
the subject or they might be in vacation or very busy. Often they are
unsure about the patch and waiting for others to comment. Not getting
your patch reviewed after four or five pings would be enough to raise
the issue in a more general email.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Theodore Papadopoulo]

On 04/24/2010 09:35 PM, Thomas Neumann wrote:
>> What reasons keep you from contributing to GCC?
>>      
> I tried this a while ago, but ultimately gave up because I could not get my
> patches in. Some were applied, but many never made it. Admittedly they were
> perhaps not of general interested, there were only improving compatibility
> of the gcc base with C++ (what Ian Lance Taylor then did later).
> The most frustrating part was not getting patches rejected (I could then
> improve them, after all), but having patches ignored. You submit a number of
> patches, and the result is... nothing. No response at all. Not exactly what
> encourages gcc as a free time activity.
>
> On the other hand I am a professional developer, too (even working on
> compilers), and I myself would perhaps also be reluctant to spend time on
> reviewing and merging patches that I do not really care about. So I
> understand the gcc developers. But it is still frustrating for outsiders.
>    

     Sorry to reply so late (was away off internet for a while).

 From my experience, the reasons for not contributing are:

- Code complexity: Doing even the simplest stuff in gcc requires quite 
some time to a newcomer.
   Occasionnally, I got some good advices which helped to produce a 
functional patch, but in many
   cases, having access to a simple hint (just to localize the actual 
code that needs to be modified)
   is often difficult. C does not help here (even though I'm fluent in 
that langage), but I do not want
   to re-open a war...

- Time involvement: I can spend a few days (mostly over the week ends) 
or hours after work and can
   spend an equivalent amount of time for dealing with consequences of a 
patch. I cannot afford to
   spend weeks of work (except exceptionnaly if this relates to my 
work). On one occasion, I submitted
   a prototype patch to remove default template parameters with some 
questions whether the flag I used
   was really available and request for comments.... The only answer I 
got was to use the new (completely
   undocumented and un-comprehensible to me after a few days of 
struggling with it -- this was several
   years ago) error message system.... Not even one comment on the 
usefulness of the feature or on
   my questions, I decided that the patch would anyway be never accepted 
(at the time INRIA had no
   copyright agreement -- and I'm still not sure I'm covered now --), so 
I abandonned. Since then
   Paolo IIRC also proposed something (probably much more elaborated 
than what I did), still such a "trivial"
   (for me it was some effort) functionality is not available unless I'm 
wrong. I agree that this is a minor
   functionality, and typically the kind of effort that might interest a 
newcomer, but the effort to get accepted
   is/was just too high.

- I'd like to help gcc not to fight/bother gcc people to get some more 
or less trivial stuff accepted.
   I can very well understand that they have more important things to 
do.....
   I must say though that I see some maintainers spending time to answer 
beginner questions, and I
   appreciate.

- Copyright assignment only comes fourth (and actually may be solved for 
me). I believe anyhow that
   most newcomers should first start with very small patches first (one 
liners, documentation, style, unused
   variables....). But those patch are often ignored (again, I can 
understand that for a gcc developper that
   might not be worth the effort).

- All in all, I believe that there is gap between skilled developpers 
and newcomers. Once one is skilled enough
   the list is very helpful. For newcomers, the answers form the list 
are just not reliable enough (in terms of useful
   answers). Again, I have seen recently some effort by a few 
developpers to anser basic questions and that's good.
   A slightly better way might be to offer mentorship (eventually 
pyramidal) on some small projects in order to help
   people jump in the bandwagon.... At least this is true for 
non-compiler people as I'm.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 4 May 2010 09:12, Theodore Papadopoulo
<Theodore.Papadopoulo@sophia.inria.fr> wrote:
>
> - Code complexity: Doing even the simplest stuff in gcc requires quite some
> time to a newcomer.

Do you have any suggestion how this could be enhanced? We know that
better documentation may help, but at some moment one has to get the
hands dirty and dive into the code. I think we are also happy to know
if something is not intuitively located/named/documented. This is one
part where one could learn *and* help a lot the project.

In general, asking here or in the IRC will get you a quick reply,
which perhaps is not so good because it doesn't actually fix the
original problem.

> - Time involvement: I can spend a few days (mostly over the week ends) or
> hours after work and can
>  spend an equivalent amount of time for dealing with consequences of a
> patch. I cannot afford to
>  spend weeks of work (except exceptionnaly if this relates to my work). On

The time spent decreases a lot with increasing experience. This is
also true for producing good patches, that is, patches that need
little or no further modifications. Using the right tools can also
save a lot of time (the debug_* functions in gdb, automatic scripts
for bootstrapping/regression testing).

> one occasion, I submitted
>  a prototype patch to remove default template parameters with some questions
> whether the flag I used
>  was really available and request for comments.... The only answer I got was

This is a problem of communication. Point 5 in
http://gcc.gnu.org/wiki/GCC_Research: Your email/patch may not receive
much feedback. There are many reasons for it, as listed there. The
only solution is to insist.

>  my questions, I decided that the patch would anyway be never accepted (at
> the time INRIA had no
>  copyright agreement -- and I'm still not sure I'm covered now --), so I
> abandonned. Since then

But then, why people are going to spend time reviewing a patch that is
not going to be accepted? However, I strongly feel that this was not
the reason for the lack of feedback. Probably, the fact that you were
not using the appropriate functions was already such a show-stopper
that reviewers didn't spend more time on the patch.

> newcomer, but the effort to get accepted
>  is/was just too high.

The criteria should be the same for everybody, but it is easier to get
it right the first time if one has experience. Otherwise, more
iterations are needed. Asking for clarifications, and perseverance are
the only solutions.

> - I'd like to help gcc not to fight/bother gcc people to get some more or
> less trivial stuff accepted.

Fighting: bad. Arguing politely and with sound arguments: good.
Demanding: bad. Asking: good. It just depends on the tone.

>  I can very well understand that they have more important things to do.....
>  I must say though that I see some maintainers spending time to answer
> beginner questions, and I
>  appreciate.

In fact, sometimes I think maintainers spent too much time answering
begginner questions instead of documenting those answers somewhere or
fixing the reason for the question. ;-)

> - Copyright assignment only comes fourth (and actually may be solved for
> me). I believe anyhow that
>  most newcomers should first start with very small patches first (one
> liners, documentation, style, unused
>  variables....). But those patch are often ignored (again, I can understand
> that for a gcc developper that
>  might not be worth the effort).

Really often ignored? I do not see this often, but I can imagine that
it happens more to newcomers who do not insist when a patch is not
reviewed. Unfortunately, many patches require "pinging", even when
they come from experience developers. I added a note to the above page
in the wiki.

http://gcc.gnu.org/wiki/GCC_Research

I don't know how this particular issue could be handled better.

> - All in all, I believe that there is gap between skilled developpers and
> newcomers. Once one is skilled enough
>  the list is very helpful. For newcomers, the answers form the list are just
> not reliable enough (in terms of useful
>  answers). Again, I have seen recently some effort by a few developpers to
> anser basic questions and that's good.
>  A slightly better way might be to offer mentorship (eventually pyramidal)
> on some small projects in order to help
>  people jump in the bandwagon.... At least this is true for non-compiler
> people as I'm.

I think this is a really good suggestion. And I feel that many
experienced GCC developers would be up for it if the "student" shows
real interest. I am pretty sure potential mentors have many "beginner"
projects in mind even simpler than those carried out during the google
summer of code.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Martin Guy]

OK, now that stage3 is over I'm thinking of updating the
MaverickCrunch FPU fixes (currently for 4.3) and merging them but
would appreciate some guidance.

There are 26 patches in all and I can't expect anyone to understand
them because they require a good understanding of the FPU and its
hardware bugs (and there are a lot of them!) :) What's the best path?
Create a branch, work there and then merge when done?

I have done the copyright assignment stuff but don't have an account
on gcc.gnu.org. They all affect files under config/arm/ apart from one
testsuite fix and the docs.

The missing part is a huge testsuite for it. I confess I find that
daunting; it is potentially huge in that it replaces a non-working
code generator with a working one, and for the non-working one there
were *no* fpu-specific tests.
Do I really need to write an entire validation suite?

    M

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 22:46, Martin Guy <martinwguy@gmail.com> wrote:
> OK, now that stage3 is over I'm thinking of updating the
> MaverickCrunch FPU fixes (currently for 4.3) and merging them but
> would appreciate some guidance.

I think you should send a new email with a different subject to gcc@,
otherwise this thread goes off-topic and more importantly, the
relevant people may be not reading this long thread anymore.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Ross Ridge]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

Manuel López-Ibáñez writes:
>What reasons keep you from contributing to GCC?

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 work on software on my own time to solve my own problems.  I'm happy
enough not "horde" it and give it away for "free", but it doesn't
make much difference to me if anyone else actually ends up using it.
I can have my own patched version of GCC that does what I want without
signing anything.

Another reason is the poor patch submission process.  Why e-mail a patch
if I know, as a new contributor, there's a good chance it won't even be
looked at by anyone?  Why would I want to go through I a process where I'm
expected to keep begging until my patch finally gets someone's attention?

I also just don't need the abuse.  GCC, while not the most of hostile of
open source projects out there, it's up there.  Manuel López-Ibáñez's
unjustified hostility towards Michael Witten in this thread is just a
small example.

Finally, it's also a lot of work.  Just building GCC can be pain, having
to find upto date versions of a growing list of math libraries that
don't benefit me in the slightest way.  Running the test suite takes a
long time, so even trivial patches require a non-trivial amount of work.
Anything more serious can take a huge ammount of time.  I've abandonded
projects once I realized it would be lot quicker to find some other
solution like using assembly, rather than trying to get GCC to do what
I wanted it to do.

Now these are just the main reasons why I don't contribute to GCC.
I'm not arguing that any these issues need to be or can be fixed.  If I
had what I thought where good solutions that would be better overall to
GCC then I'd have suggested them long ago.

I will add, that I don't think code quality is a problem with GCC.  I hate
the GNU coding style as much as anyone, but it's used consistantly and
that's what matters.  Compared other open and closed projects I've seen
it's as easy to understand and maintain as anything.  GNU binutils is
a pile of poo, but I don't know of any codebase the size of GCC that's
as nice to work with.

					Ross Ridge

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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?

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.

   Another reason is the poor patch submission process.  Why e-mail a
   patch if I know, as a new contributor, there's a good chance it
   won't even be looked at by anyone?  Why would I want to go through
   I a process where I'm expected to keep begging until my patch
   finally gets someone's attention?

We are all humans, patches fall through the cracks.  Would you like to
help keeping an eye out for patches that have fallen through?  Would
anyone else like to do this?

   I also just don't need the abuse.  GCC, while not the most of
   hostile of open source projects out there, it's up there.  Manuel
   López-Ibáñez's unjustified hostility towards Michael Witten in this
   thread is just a small example.

Please refer to GCC as a free software project, it was written by the
GNU project and the free software community.  Manuel might have been
rough, but it wasn't hostile.


It seems that the major complaints fall into these categories:

 - Copyright assignments

 - Complex and big project with high standards

Not much can be done to either of those, the copyright assignments are
necessary to keep GCC legally safe.  If a assignment takes a long
time, please contact either rms@gnu.org or assign@gnu.org; if nobody
says anything then nobody knows anything.

Compilers are complex programs (specially if you support as many front
ends as GCC does), lowering the quality would be disastrous and nobody
really wants that.  The bigger the project, the longer it takes to
become accustomed to it, and not everyone has enough time to get up to
par.  This is not specific to GCC, it affects all large projects.

Re: Why not contribute? (to GCC)

[Richard Kenner]

>    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?
> 
> 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 a critical point, which almost everybody misses, so I want to
repeat it and expand on it.

There is ABSOLUTELY NO DIFFERENCE in your legal liability in contributing
patches to a program in the case where you assign copyright to the owner of
that program and in the case you don't.  The difference is who you're
liable TO and who'll defend you, not the amount or the conditions under
which you're liable.

In fact, for an individual, you're better off WITH the assignment, which
people also don't realize!

Let's look at two cases.  Suppose I contribute two patches, one to GCC
where I'm required to assign the patch to the FSF, and one to Linux where,
as I understand it, I can keep ownership of the patch and don't have to
assign it to anybody.

Now let's suppose some company claims my patches violate their copyright.
What happens?  In the GCC case, they can't come to me since I no longer own
that code.  They sue the FSF, who defends the case.  If they lose (because
I DID, in fact, violate somebody's copyright), the FSF now has a claim
against me for what they owe plus legal fees.  But if they WIN (because I
DIDN'T violate the copyright), I haven't had any responsibility beyond
possibly being a witness.

But now let's look at the case where there WASN'T an assignment.  Then the
company comes and sues ME.  It's now MY responsibility to find and hire
attorneys.  If I lose, I have pay both the judgement and the legal fees,
just like the assignment case.  But if I WIN, I may or may not recover my
legal fees, unlike the assignment case where I don't HAVE any legal fees.

Now, in the case of a large corporation submitting the patch, they DO have
the resources to hire attorneys, so in their case the advantage of the
assignment isn't there.

But the point to take away from this, which is worth emphasizing yet again,
is that the assignment does not affect your legal liability AT ALL!

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 15:26, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
>>    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?
>>
>> 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 a critical point, which almost everybody misses, so I want to
> repeat it and expand on it.

I certainly was missing this point!
Please, could you write this down in the wiki somewhere? For example, here:

http://gcc.gnu.org/wiki/FAQ

This is so good explanation and so obvious once you have explained it
that we should be pointing people to this answer (and the one above
about the U. of Illinois) everytime  the copyright assignment comes
up.

Many thanks!

Manuel.

Re: Why not contribute? (to GCC)

[Florian Weimer]

* Richard Kenner:

> Now let's suppose some company claims my patches violate their copyright.
> What happens?  In the GCC case, they can't come to me since I no longer own
> that code.  They sue the FSF, who defends the case.  If they lose (because
> I DID, in fact, violate somebody's copyright), the FSF now has a claim
> against me for what they owe plus legal fees.  But if they WIN (because I
> DIDN'T violate the copyright), I haven't had any responsibility beyond
> possibly being a witness.

Isn't it far more likely that you would be co-defendant because your
posting to gcc-patches was a copyright violation in itself?

Re: Why not contribute? (to GCC)

[Richard Kenner]

> > Now let's suppose some company claims my patches violate their copyright.
> > What happens?  In the GCC case, they can't come to me since I no longer own
> > that code.  They sue the FSF, who defends the case.  If they lose (because
> > I DID, in fact, violate somebody's copyright), the FSF now has a claim
> > against me for what they owe plus legal fees.  But if they WIN (because I
> > DIDN'T violate the copyright), I haven't had any responsibility beyond
> > possibly being a witness.
> 
> Isn't it far more likely that you would be co-defendant because your
> posting to gcc-patches was a copyright violation in itself?

Perhaps, but the point is that since the FSF is involved, THEY would be the
ones primarily responsible for the defense, whereas if I had not assigned
the copyright, everything would rest completely on my shoulders.

Re: Why not contribute? (to GCC)

[Jonathan Corbet]

On Sat, 24 Apr 2010 08:51:17 -0400
"Alfred M. Szmidt" <ams@gnu.org> wrote:

> 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 one to be "legally safe"?

Note that "copyright assignment" and "being sure that the developer
has the right to contribute the code" are two very different things.

Thanks,

jon

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Sun, Apr 25, 2010 at 5:34 PM, Jonathan Corbet <corbet@lwn.net> wrote:
> On Sat, 24 Apr 2010 08:51:17 -0400
> "Alfred M. Szmidt" <ams@gnu.org> wrote:
>
>> 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 one to be "legally safe"?
>
> Note that "copyright assignment" and "being sure that the developer
> has the right to contribute the code" are two very different things.

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 approval of at least all major copyright holders, IIUC.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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 approval of at least all major copyright
   holders, IIUC.

This is incorrect, anyone can upgrade the license for GCC (and the
rest of the GNU project), since GCC is licensed under the `GPLv3 or
any later version'.  Linux on the other hand is explicitly licensed
only under GPLv2; i.e. it lacks the `or (at your option) any later
version)' clause.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 25 April 2010 17:44, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>
> 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 approval of at least all major copyright holders, IIUC.

I think this is not worth discussing. The FSF is not going to not ask
for copyright assignment. The question is whether the process can be
simplified.

LLVM has also copyright assignment, however, it is implicit in the
patch submission. Whether this is enough or not or the legal
consequences of it are not clear to me.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> LLVM has also copyright assignment, however, it is implicit in the
> patch submission. 

Do they have any legal opinion which backs the claim that this sort of
"implicit" assignment has any legal force at all?

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > 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 one to be "legally
   safe"?

I do not know what high-profile projects you are refering to, you will
have to ask them why they think they can ignore a paper trail.  Having
one copyright holder solves many issues when enforcing copyright, you
do not need to contact all parties.  There is a short article on why
you should assign copyright to the FSF at:
http://www.gnu.org/licenses/why-assign.html

Re: Why not contribute? (to GCC)

[Jonathan Corbet]

On Sun, 25 Apr 2010 12:00:13 -0400
"Alfred M. Szmidt" <ams@gnu.org> wrote:

>    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

Kernel, apache, MeeGo, git, for starters.

> you will
> have to ask them why they think they can ignore a paper trail.  

Copyright assignment != paper trail.

> Having
> one copyright holder solves many issues when enforcing copyright, you
> do not need to contact all parties.

The projects with the most public success at enforcing free licensing
are the kernel and busybox.  Neither requires copyright assignment.
The enforcement actions did not require the contacting of all parties -
where did that assertion come from?

I would not presume to tell the GCC project what its policy should be;
that's a decision for the people who are doing the work. But I do get
irritated when people claim that copyright assignment is required to
somehow keep a project "safe" or to make the copyright enforceable.
Both claims are demonstrably false.

jon

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   >    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

   Kernel, apache, MeeGo, git, for starters.

If with kernel you mean Linux, then they require you to agree to an
type of assignment (though not in paper form), same for git.  Linux
(and git) started with this right around when SCO started threatening
free software projects.  If such a such an agreement is legally
binding or not is for the court to decide, the assignments from the
FSF are legally binding, though (they are contracts).

Apache requires an assignment as well from the looks, see
http://www.apache.org/licenses/icla.txt

I do not know about MeeGo. 

Regarding BusyBox, it was Erik Anderseen who filed suite (via SFLC),
but he can only file suite for the code he holds the copyright over.
If a company manages to remove the code he holds copyright over, and
nobody of the other copyright holders wish to sue, then the company
can go about violating the license.

Re: Why not contribute? (to GCC)

[Jonathan Corbet]

On Mon, 26 Apr 2010 12:50:14 -0400
"Alfred M. Szmidt" <ams@gnu.org> wrote:

> If with kernel you mean Linux, then they require you to agree to an
> type of assignment (though not in paper form), same for git.  

No.

What you agree to is the developers certificate of origin (DCO), which
says you have the right to contribute the code to the kernel.  No
copyright assignment takes place.  Trust me, I have thousands of lines
of code in the kernel, and the copyright remains mine.

> Apache requires an assignment as well from the looks, see
> http://www.apache.org/licenses/icla.txt

Did you read it?  It's not a copyright assignment agreement.

> I do not know about MeeGo. 

	http://meego.com/about/licensing-policy

	MeeGo project will neither require nor accept copyright
	assignment for code contributions. The principle behind this is
	on the one hand to avoid extra bureaucracy or other obstacles
	discouraging contributions. On the other hand the idea is to
	emphasize that contributors themselves carry the rights and
	responsibilities associated with their code.

> Regarding BusyBox, it was Erik Anderseen who filed suite (via SFLC),
> but he can only file suite for the code he holds the copyright over.
> If a company manages to remove the code he holds copyright over, and
> nobody of the other copyright holders wish to sue, then the company
> can go about violating the license.

If the copyright holders don't wish to sue, then, one presumes, they
are not unhappy about the use of their code?

Anyway, I've probably irritated this list more then enough already;
I'll stop now, sorry for the noise.

jon

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

Jonathan Corbet <corbet@lwn.net> writes:

> What you agree to is the developers certificate of origin (DCO), which
> says you have the right to contribute the code to the kernel.  No
> copyright assignment takes place.  Trust me, I have thousands of lines
> of code in the kernel, and the copyright remains mine.

The FSF permits something like this as well, in the form of a
copyright disclaimer.  The FSF prefers to get an assignment, but a
disclaimer is also acceptable.  The important point is the explicit
signature.

Ian

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 26 April 2010 21:28, Ian Lance Taylor <iant@google.com> wrote:
> Jonathan Corbet <corbet@lwn.net> writes:
>
>> What you agree to is the developers certificate of origin (DCO), which
>> says you have the right to contribute the code to the kernel.  No
>> copyright assignment takes place.  Trust me, I have thousands of lines
>> of code in the kernel, and the copyright remains mine.
>
> The FSF permits something like this as well, in the form of a
> copyright disclaimer.  The FSF prefers to get an assignment, but a
> disclaimer is also acceptable.  The important point is the explicit
> signature.

And how are potential contributors supposed to know this?

If there is something that I can take from this thread is:

* The reasons for the copyright assignment/disclaimer, and their legal
effects are totally misunderstood by almost any potential contributor
and by a large number of existing contributors. After the whole
thread, I am perhaps a bit more confused than before. It would be
extremely useful if anyone that feels confident on the subject wrote a
FAQ-like document in the wiki that we could use as a reference for the
future. Otherwise, I feel that all the heated discussion will be for
nothing.

* The process is overly complex, obscure, confusing  and slow. It does
not seem that it needs to be so. It is scaring away potential
contributors and slowing down GCC development. Couldn't the SC
intercede with the FSF to make it as simpler (and clear) as possible?
In the ideal world, a web form would be sufficient to explain all
details and gather all required information.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> 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 where details matter, often quite a bit.

My suggestion for this process is develop an online form where a
person specifies various things about their contribution including
what program it's for an how long it is.  It should ask whether the
person anticipates submitting more changes.  Then it needs to ask what
the person's employment status is and in which country.  It should ask
about terms relating to IPR in any employment agreements.  And so on.

Then it should be able to come up with a set of choices that would
cover this person's unique situation.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > 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 where details matter, often quite a bit.

   My suggestion for this process is develop an online form where a
   person specifies various things about their contribution including
   what program it's for an how long it is.  It should ask whether the
   person anticipates submitting more changes.  Then it needs to ask what
   the person's employment status is and in which country.  It should ask
   about terms relating to IPR in any employment agreements.  And so on.

   Then it should be able to come up with a set of choices that would
   cover this person's unique situation.

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.

Re: Why not contribute? (to GCC)

[Ian Lance Taylor]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> 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 paper, a
pen, and a stamp.

Ian

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > 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 paper,
   a pen, and a stamp.

There are two forms to be filled out, the `request' and then the
`assignment'.  I'm guessing you are refering to the assignment here,
since that is the paper form--I was refering to the request form.  I'd
love to see that, and all GNU project maintainers would be happy about
it, but that is a topic for the FSF, its lawyers and Richard.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 27 April 2010 22:45, Alfred M. Szmidt <ams@gnu.org> wrote:
>   > 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 paper,
>   a pen, and a stamp.
>
> There are two forms to be filled out, the `request' and then the
> `assignment'.  I'm guessing you are refering to the assignment here,
> since that is the paper form--I was refering to the request form.  I'd
> love to see that, and all GNU project maintainers would be happy about
> it, but that is a topic for the FSF, its lawyers and Richard.

Given the feedback we have got in this thread, it would make a
significant difference if all the process could be done via a web
form. I regularly sign copyright papers for conferences and publishers
via web, e.g., IEEE and ACM.

If the FSF insists that a hard-copy signature is absolutely necessary,
then the web form should provide a personalized pdf that can be
printed, signed and sent by fax or email, which is the method that
have been used in academia since faxes were invented.

If snail mail is absolutely necessary, still a clear and flexible web
form could greatly improve the situation. As for clear, we have seen
that the process is more than obscure. 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. It is not sufficient
to put the current procedure in the web. The procedure itself has to
be improved.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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 legal@gnu.org.
They are quite flexible, I do not know where people got the idea that
they are not.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> If you need something specific, you should contact legal@gnu.org.
> They are quite flexible, I do not know where people got the idea that
> they are not.

You're missing the point.  If flexibilty isn't the DEFAULT people
won't know about it and will think it doesn't exist and complain.  I
strongly agree with previous post: this needs to move to a web-based
mostly-automatic and and approach much more personalized to a person's
individual situation.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

People will always find reasons to complain, but most people (and
companies) seem to be happy with how the copyright assignments look
today.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 27 April 2010 23:27, Alfred M. Szmidt <ams@gnu.org> wrote:
>   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 legal@gnu.org.
> They are quite flexible, I do not know where people got the idea that
> they are not.

But this is precisely the problem we are discussing. Lack of
information and clarity. I know they are very flexible because I
drafted my form together with the legal department of my university
and they just accepted it. However, it was just a bold move on my part
to get things moving when my university told they will never sign the
original form. But this thread shows precisely that:

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.

2) Potential contributors are lost as to what changes to make. I was
lucky that someone helped me to draft the document but this is
probably an exception.

3) Depending on the complexity of the organisation, you may have one
chance to get the paper signed. Afterwards, the organisation won't
bother again to consider the issue. Even in my case, I had to go in
person and wait for hours to get the paper that they drafted signed by
them.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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 email with some questions or wait
a few days for a piece of paper to sign.

   2) Potential contributors are lost as to what changes to make. I
   was lucky that someone helped me to draft the document but this is
   probably an exception.

Wether a change is required is up to who is signing the form, if they
are not willing to sign it then respective legal departments should be
contacted.

Please contact legal@gnu.org for further discussions about the topic.

Re: Why not contribute? (to GCC)

[Paolo Bonzini]

On 04/28/2010 12:33 AM, Alfred M. Szmidt wrote:
>     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 email with some questions or wait
> a few days for a piece of paper to sign.

People are fine with spending time to improve things.

I find it harder to understand why one should argue to maintain the 
status quo.

Paolo

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Mon, Apr 26, 2010 at 6:08 PM, Jonathan Corbet <corbet@lwn.net> wrote:
> I would not presume to tell the GCC project what its policy should be;
> that's a decision for the people who are doing the work.

Actually it's not. The FSF sets the rules, and you either play along
or you don't do the work (not for the FSF anyway).

But to toss in $0.02 from someone who occasionally does some of the
work: I honestly just don't think of this copyright assignment as a
problem. I have assignments on file for g95 and for gcc, and I
assigned them because it allows me to contribute to a project that
gives me joy and fun (most of the time anyway) and the feeling I am
contributing to something useful for everyone. Every time I see a
device built in part with GCC (android phones, playstations,
Google(!)), I think "hey, some of my work helped build that".

There is so much negativism about a mere nuisance in this thread. It's
a shame, but I guess it's just more proof that negative discussions
about GCC are more popular than positive ones.

Shall we continue hacking now? There's enough to do.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Steven Bosscher]

On Mon, Apr 26, 2010 at 7:03 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Mon, Apr 26, 2010 at 6:08 PM, Jonathan Corbet <corbet@lwn.net> wrote:
>> I would not presume to tell the GCC project what its policy should be;
>> that's a decision for the people who are doing the work.
>
> Actually it's not. The FSF sets the rules, and you either play along
> or you don't do the work (not for the FSF anyway).

And to avoid being misunderstood: I don't say I like this situation.
It's just the facts as I understand them.

Ciao!
Steven

Re: Why not contribute? (to GCC)

[Olivier Galibert]

On Mon, Apr 26, 2010 at 07:03:25PM +0200, Steven Bosscher wrote:
> There is so much negativism about a mere nuisance in this thread. It's
> a shame, but I guess it's just more proof that negative discussions
> about GCC are more popular than positive ones.

Seriously, depending on the country it's not a mere nuisance.  To put
things in perspective, for a lot of people in France it's equivalent
to, in the US, go to the bank that owns your mortgage[1] and ask them
a paper saying that they have no copyright interests on your interior
decoration.  Or a landlord of the thousands of places on rent kind.

  OG.

[1] If you don't have one, imagine you do.

Re: Why not contribute? (to GCC)

[Richard Kenner]

> Note that "copyright assignment" and "being sure that the developer
> has the right to contribute the code" are two very different things.

Although that's true, the stated concern with the assignment document
had to do with the question of the right to contribute the code.

But I'm confused here: if the entity submitting the code doesn't use
an assignment document to guarantee that he has the right to contribute
the code, then what document DOES that entity sign?  What DOES make sure
that no third party has a claim on the submitted code?

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 14:12, Ross Ridge <rridge@csclub.uwaterloo.ca> wrote:
> I can have my own patched version of GCC that does what I want without
> signing anything.

Then we change that code and your patch is broken. Or your patch has a
bug and you never find out. Or we decide to remove something essential
for your patch to work because we think nobody is using it.

> I also just don't need the abuse.  GCC, while not the most of hostile of
> open source projects out there, it's up there.  Manuel López-Ibáñez's
> unjustified hostility towards Michael Witten in this thread is just a
> small example.

Perhaps his intention was not trolling but it strongly felt like that
given past behaviour.

http://gcc.gnu.org/ml/gcc-help/2008-01/msg00304.html
http://gcc.gnu.org/ml/gcc/2010-04/msg00542.html
http://gcc.gnu.org/ml/gcc/2010-04/msg00583.html

It wasn't my intention to be hostile just to state the obvious: If you
feel gcc is doomed, why are you still in this list repeating this
mantra over and over? does it make you feel better? how is that not
trolling?

But I have also found previous good posts, so it was a mistake from my
part to assume he was trolling.


> Finally, it's also a lot of work.  Just building GCC can be pain, having
> to find upto date versions of a growing list of math libraries that
> don't benefit me in the slightest way.  Running the test suite takes a
> long time, so even trivial patches require a non-trivial amount of work.

Everything is already setup for you here:

http://gcc.gnu.org/wiki/CompileFarm

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

It takes computer time, yes, but I am not in a hurry. If I were, I
would use one of the computers with 8 or 16 cores.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Gabriel Dos Reis]

On Sat, Apr 24, 2010 at 9:13 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:

> It wasn't my intention to be hostile just to state the obvious: If you
> feel gcc is doomed, why are you still in this list repeating this
> mantra over and over? does it make you feel better? how is that not
> trolling?

I don't think that line of discussion is going to make people more comfortable
about the whole thing of getting more contributors.  You can't complain about
angry people, and at the same time send messages that suggest that
you might yourself be angry.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 16:23, Gabriel Dos Reis <dosreis@gmail.com> wrote:
> On Sat, Apr 24, 2010 at 9:13 AM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>
>> It wasn't my intention to be hostile just to state the obvious: If you
>> feel gcc is doomed, why are you still in this list repeating this
>> mantra over and over? does it make you feel better? how is that not
>> trolling?
>
> I don't think that line of discussion is going to make people more comfortable
> about the whole thing of getting more contributors.  You can't complain about
> angry people, and at the same time send messages that suggest that
> you might yourself be angry.

Again, I apologize for overreacting to a (mistakenly perceived)
trolling attempt. I can only say that I completely missed that my post
could be understood as hostile or angry. You tell me I was wrong. I
say sorry. Can we be friends? ;-)

I am not angry. It is very sunny here. :-)

Manuel.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   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?

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 16:34, Alfred M. Szmidt <ams@gnu.org> wrote:
>   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?

It is just a modified version of the gcc_build script in contrib/. You
can find my version in /home/manuel/bin/gccfarming in both gcc11 and
gcc12 nodes in the compile farm. But there is also
contrib/patch_tester.sh which is probably even better implemented and
more clear.

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Manuel López-Ibáñez]

On 24 April 2010 16:39, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> On 24 April 2010 16:34, Alfred M. Szmidt <ams@gnu.org> wrote:
>>   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?
>
> It is just a modified version of the gcc_build script in contrib/. You
> can find my version in /home/manuel/bin/gccfarming in both gcc11 and
> gcc12 nodes in the compile farm. But there is also
> contrib/patch_tester.sh which is probably even better implemented and
> more clear.

It is also here:

http://gcc.gnu.org/wiki/ManuelLópezIbáñez

Cheers,

Manuel.

Re: Why not contribute? (to GCC)

[Leif Ekblad]

Why do I not contribute to GCC? Well, I tried to get some really simple 
patches for RDOS
accepted in 2006, but it seemed to take forever. I'm not sure if they have 
been accepted now,
or if the binutils patches (which were accepted) are still there. For 
somebody wanting to support
a new OS with GCC (that is not unix-style), the patch acceptance policy is 
simply making the
whole process impossible to do in reasonable time. Such a new OS will need 
hundreds or
even thousands of patches, and getting all of these accepted in reasonable 
time seems more
or less impossible.

When I had given up on GCC, I got interested in OpenWatcom. They gave me a 
new branch
to work in, and eventually helped me integrate my changes with trunk. This 
worked very well
and RDOS will be supported in the upcoming 1.9 release.

The 2006 patches I worked a lot to find out are probably totally obsolete 
today, and needs to
be done from scratch again. This is the nature of supporting new OSes. I 
just doesn't work
to find out the patches if nobody cares to incorporate them, as they will 
quickly become obsolete.
However, I suspect that the community is only interested in supporting 
unix-like environments,
where these issues doesn't exist.

Leif Ekblad



----- Original Message ----- 
From: "Ross Ridge" <rridge@csclub.uwaterloo.ca>
To: <gcc@gcc.gnu.org>
Sent: Saturday, April 24, 2010 2:12 PM
Subject: Re: Why not contribute? (to GCC)


> Manuel López-Ibáñez writes:
>>What reasons keep you from contributing to GCC?
>
> 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 work on software on my own time to solve my own problems.  I'm happy
> enough not "horde" it and give it away for "free", but it doesn't
> make much difference to me if anyone else actually ends up using it.
> I can have my own patched version of GCC that does what I want without
> signing anything.
>
> Another reason is the poor patch submission process.  Why e-mail a patch
> if I know, as a new contributor, there's a good chance it won't even be
> looked at by anyone?  Why would I want to go through I a process where I'm
> expected to keep begging until my patch finally gets someone's attention?
>
> I also just don't need the abuse.  GCC, while not the most of hostile of
> open source projects out there, it's up there.  Manuel López-Ibáñez's
> unjustified hostility towards Michael Witten in this thread is just a
> small example.
>
> Finally, it's also a lot of work.  Just building GCC can be pain, having
> to find upto date versions of a growing list of math libraries that
> don't benefit me in the slightest way.  Running the test suite takes a
> long time, so even trivial patches require a non-trivial amount of work.
> Anything more serious can take a huge ammount of time.  I've abandonded
> projects once I realized it would be lot quicker to find some other
> solution like using assembly, rather than trying to get GCC to do what
> I wanted it to do.
>
> Now these are just the main reasons why I don't contribute to GCC.
> I'm not arguing that any these issues need to be or can be fixed.  If I
> had what I thought where good solutions that would be better overall to
> GCC then I'd have suggested them long ago.
>
> I will add, that I don't think code quality is a problem with GCC.  I hate
> the GNU coding style as much as anyone, but it's used consistantly and
> that's what matters.  Compared other open and closed projects I've seen
> it's as easy to understand and maintain as anything.  GNU binutils is
> a pile of poo, but I don't know of any codebase the size of GCC that's
> as nice to work with.
>
> Ross Ridge
>
> 

Re: Why not contribute? (to GCC)

[Joel Sherrill]

On 04/24/2010 02:07 PM, Leif Ekblad wrote:
> Why do I not contribute to GCC? Well, I tried to get some really simple
> patches for RDOS
> accepted in 2006, but it seemed to take forever. I'm not sure if they have
> been accepted now,
> or if the binutils patches (which were accepted) are still there. For
> somebody wanting to support
> a new OS with GCC (that is not unix-style), the patch acceptance policy is
> simply making the
> whole process impossible to do in reasonable time. Such a new OS will need
> hundreds or
> even thousands of patches, and getting all of these accepted in reasonable
> time seems more
> or less impossible.
>    
Maybe my search is wrong but "rdos site:gcc.gnu.org" doesn't
turn it up.

I don't know how divergent rdos from any other OS that is
not self-hosted and is cross-compiled but there shouldn't
be 100s or 1000s of patches required to support an OS on gcc
unless you have a divergent object format or are including
a new CPU.

Also you haven't mentioned two major issues that are
not "patch" related.

(1) Did you arrange for a maintainer for the rdos target?

(2) Did you submit test results with the port?

(3) Has copyright assignment paperwork been dealt with?

I maintain the *-rtems* targets (~12 architectures) and there
just isn't much special to them in contrast to the large amount of
code that just works fine with a bit of OS specific configuration
and glue.

Not to pick but from Google'ing the mailing list, I just see you
asking questions.  I didn't find code being submitted.

And speaking from experience, if you submit code and it doesn't
get reviewed and merged.  Ask again.  The submitter cares a lot
more about it than anyone else and that's just the nature of the
game.  If you don't care enough about your area to follow up, why
should anyone else?
> When I had given up on GCC, I got interested in OpenWatcom. They gave me a
> new branch
> to work in, and eventually helped me integrate my changes with trunk. This
> worked very well
> and RDOS will be supported in the upcoming 1.9 release.
>    
And if you had arranged for the things above, the gcc community
would have supported you doing the same.  There are a number of
Microblaze and other special project branches.


> The 2006 patches I worked a lot to find out are probably totally obsolete
> today, and needs to
> be done from scratch again. This is the nature of supporting new OSes. I
> just doesn't work
> to find out the patches if nobody cares to incorporate them, as they will
> quickly become obsolete.
> However, I suspect that the community is only interested in supporting
> unix-like environments,
> where these issues doesn't exist.
>
>    
Depends.  Not seeing the patches I can't say but I have maintained
patches for odd RTEMS targets (e.g. sparc64 and nios) off the
main source across multiple major gcc releases without any
real problems.

--joel
> Leif Ekblad
>
>
>
> ----- Original Message -----
> From: "Ross Ridge"<rridge@csclub.uwaterloo.ca>
> To:<gcc@gcc.gnu.org>
> Sent: Saturday, April 24, 2010 2:12 PM
> Subject: Re: Why not contribute? (to GCC)
>
>
>    
>> Manuel López-Ibáñez writes:
>>      
>>> What reasons keep you from contributing to GCC?
>>>        
>> 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 work on software on my own time to solve my own problems.  I'm happy
>> enough not "horde" it and give it away for "free", but it doesn't
>> make much difference to me if anyone else actually ends up using it.
>> I can have my own patched version of GCC that does what I want without
>> signing anything.
>>
>> Another reason is the poor patch submission process.  Why e-mail a patch
>> if I know, as a new contributor, there's a good chance it won't even be
>> looked at by anyone?  Why would I want to go through I a process where I'm
>> expected to keep begging until my patch finally gets someone's attention?
>>
>> I also just don't need the abuse.  GCC, while not the most of hostile of
>> open source projects out there, it's up there.  Manuel López-Ibáñez's
>> unjustified hostility towards Michael Witten in this thread is just a
>> small example.
>>
>> Finally, it's also a lot of work.  Just building GCC can be pain, having
>> to find upto date versions of a growing list of math libraries that
>> don't benefit me in the slightest way.  Running the test suite takes a
>> long time, so even trivial patches require a non-trivial amount of work.
>> Anything more serious can take a huge ammount of time.  I've abandonded
>> projects once I realized it would be lot quicker to find some other
>> solution like using assembly, rather than trying to get GCC to do what
>> I wanted it to do.
>>
>> Now these are just the main reasons why I don't contribute to GCC.
>> I'm not arguing that any these issues need to be or can be fixed.  If I
>> had what I thought where good solutions that would be better overall to
>> GCC then I'd have suggested them long ago.
>>
>> I will add, that I don't think code quality is a problem with GCC.  I hate
>> the GNU coding style as much as anyone, but it's used consistantly and
>> that's what matters.  Compared other open and closed projects I've seen
>> it's as easy to understand and maintain as anything.  GNU binutils is
>> a pile of poo, but I don't know of any codebase the size of GCC that's
>> as nice to work with.
>>
>> Ross Ridge
>>
>>
>>      
>    

Re: Why not contribute? (to GCC)

[Leif Ekblad]

Joel Sherrill:
> I don't know how divergent rdos from any other OS that is
> not self-hosted and is cross-compiled but there shouldn't
> be 100s or 1000s of patches required to support an OS on gcc
> unless you have a divergent object format or are including
> a new CPU.
> 
> Also you haven't mentioned two major issues that are
> not "patch" related.
> 
> (1) Did you arrange for a maintainer for the rdos target?
> 
> (2) Did you submit test results with the port?
> 
> (3) Has copyright assignment paperwork been dealt with?
> 
> I maintain the *-rtems* targets (~12 architectures) and there
> just isn't much special to them in contrast to the large amount of
> code that just works fine with a bit of OS specific configuration
> and glue.
> 
> Not to pick but from Google'ing the mailing list, I just see you
> asking questions.  I didn't find code being submitted.

The primary issue I had was that some basic configuration was
never updated to GCC (libtool). Because this was the place where the
targets and stuff was defined, it was not even possible to submit specific
patches in the first place, because they would fail without this refresh.
 
> And speaking from experience, if you submit code and it doesn't
> get reviewed and merged.  Ask again.  The submitter cares a lot
> more about it than anyone else and that's just the nature of the
> game.  If you don't care enough about your area to follow up, why
> should anyone else?

I think I posted pings. 

As for the steps above, nobody requested me to fill out the
copyright assignment, and neither about maintainer for rdos
target.

The 100s of patches related to libc (in this case newlib), not
to gcc. I mixed up those. However, it was not possible to submit
the patches to newlib either until the GCC patches had been
applied.
 
Leif Ekblad

Re: Why not contribute? (to GCC)

[Ralf Wildenhues]

Hello Leif,

* Leif Ekblad wrote on Sun, Apr 25, 2010 at 12:56:21PM CEST:
> The primary issue I had was that some basic configuration was
> never updated to GCC (libtool). Because this was the place where the
> targets and stuff was defined, it was not even possible to submit specific
> patches in the first place, because they would fail without this refresh.

Wait, Libtool has a patch from you from 2006-01-12 in its tree,
<http://thread.gmane.org/gmane.comp.gnu.libtool.patches/6680>
Is that the one you're talking about?

Was it that GCC took long to merge the Libtool changes?  Did you ever
ping that?

Nowadays the Libtool sources in GCC track upstream more closely than
they used to do, and updating them should be fairly straightforward.

Thanks,
Ralf

Re: Why not contribute? (to GCC)

[Matthew J Fletcher]

Like many people it seems I've read the gcc lists for many years but 
never contributed. I am an embedded developer using GCC on x86 and ARM.

- GCC works really well, i've never found a serious GCC bug so there is 
nothing that i have had to fix. No "itch to scratch".

- When i modified GCC for C++ support on a propitiatory RTOS (Nucleus), 
it was a bit of a bodge so i knew it would not get accepted, but it 
works well enough for me.

- I have reported bugs mostly to do with cross compiling but the proper 
fix is often more complex than my 5 minute hack to build the cross 
compiler, you generally only build these things once so its a lot of 
effort for a small gain.



- Matthew J Fletcher

Re: Why not contribute? (to GCC)

[Ross Ridge]

Alfred M. Szmidt writes:
>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 only be increasing them.
And please don't try to argue that's not true, because I have no reason
to believe you.  Only a lawyer working for myself would be in a position
to convince me otherwise, but if I have to go that far, it's clearly
not worth it.

The debate over legalities has already derailed this thread, so let me
try to put it another way.

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 no.
It's public domain, take it or leave it.  Why I should I sign some
legally binding document for some code I had in effect already donated
to the public?  How would you feel if some charity you donated money to
came back with a piece of paper for you to sign?

Submitting a hypothetical patch to GCC isn't much different to me.  For
some people having their code in the GCC distribution is worth something.
For me it's not.  For them it's a fair trade.  For me it's a donation.

>We are all humans, patches fall through the cracks.  Would you like to
>help keeping an eye out for patches that have fallen through?  Would
>anyone else like to do this?

As I said, I was just listing the reasons why I don't contribute.
I'm not arguing that anything should be changed or can be changed.
However, what I do know is that excuses won't make me or anyone else
more likely to contribute to GCC.

>Please refer to GCC as a free software project, it was written by the
>GNU project and the free software community. 

Oh, yah, forgot about that one.  Political stuff like this another reason
not to get involved with GCC. 

					Ross Ridge

Re: Why not contribute? (to GCC)

[Richard Kenner]

> 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 no.
> It's public domain, take it or leave it.  Why I should I sign some
> legally binding document for some code I had in effect already donated
> to the public?

Because that's the only way to PUT something in the public domain!
Copyright law says that if you write something, you own the copyright to
it.  That's true whether you put a copyright notice in it or not.  If you
mean to disclaim copyright interest in it, you have to sign some document
saying you do.

> How would you feel if some charity you donated money to came back
> with a piece of paper for you to sign?

A closer analogy: a charity receives an unsolicited script for a play from
you.  There's no copyright notice on it.  They love the script and feel
they can make a lot of money producing the show.  If you were the charity's
attorney would you recommend they go ahead and produce the show under the
assumption you MEANT to assign the rights to them or should they get a
document from you STATING that you mean to assign the rights to them?

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > 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 no.  It's public domain, take it or leave
   > it.  Why I should I sign some legally binding document for some
   > code I had in effect already donated to the public?

   Because that's the only way to PUT something in the public domain!

Well, not entiterly correct... It is very hard to put something into
the public domain (legally) other than dropping dead, and waiting N
years.  What you do is just give a `free for all' license.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   >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 only be
   increasing them.  And please don't try to argue that's not true,
   because I have no reason to believe you.

Well, it isn't true, the liabilities are exactly the same against you.

   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.

If you wrote it, then it is copyrighted and not public domain.
Putting code into the PD is complex, and depending on the place
impossible.  So unless you are a ghost from say 90 years back, the
code was infact copyrighted by you and not in the PD.  The general
method is to ask either for an assignment, or an explicit `free for
all' license.

Re: Why not contribute? (to GCC)

[Ross Ridge]

Ross Ridge writes:
> 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 no.
> It's public domain, take it or leave it.  Why I should I sign some
> legally binding document for some code I had in effect already donated
> to the public?

Richard Kenner writes:
> Because that's the only way to PUT something in the public domain!

That's absurd and beside the point.  

>> How would you feel if some charity you donated money to came back
>> with a piece of paper for you to sign?
>
>A closer analogy: a charity receives an unsolicited script for a play from
>you.

No, that's not a closer analogy.  As I said, I never intended for my
code to become part of an FSF project.  I didn't send them anything
unsolicited.

I'm contributing to this thread solely to answer the question asked.
Either take the time to read what I've written and use it try to
understand why I don't and others might not contribute to GCC, or please
just ignore it.  Your unsubstantiated and irrelevent legal opinions
aren't helping.

					Ross Ridge