Re: Why not contribute? (to GCC)
On 4 May 2010 09:12, Theodore Papadopoulo theodore.papadopo...@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)
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)
[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)
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)
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)
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)
Alfred M. Szmidt a...@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)
On Mon, Apr 26, 2010 at 21:03, Mark Mielke m...@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)
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)
On 27 April 2010 22:45, Alfred M. Szmidt a...@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)
As for flexible, it seems clear that the current form is not sufficiently personalized, which makes it more difficult to get it signed by an employer. If you need something specific, you should contact le...@gnu.org. They are quite flexible, I do not know where people got the idea that they are not.
Re: Why not contribute? (to GCC)
If you need something specific, you should contact le...@gnu.org. They are quite flexible, I do not know where people got the idea that 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)
On 27 April 2010 23:27, Alfred M. Szmidt a...@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 le...@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)
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)
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 le...@gnu.org for further discussions about the topic.
Re: Why not contribute? (to GCC)
On 04/25/2010 06:05 PM, Steven Bosscher wrote: On Sun, Apr 25, 2010 at 6:48 PM, Michael Witten mfwit...@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)
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
Re: Why not contribute? (to GCC)
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)
On 04/26/2010 12:31 AM, Ian Lance Taylor wrote: Mark Mielkem...@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)
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)
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)
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)
On 26 April 2010 07:06, Chris Lattner clatt...@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)
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)
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)
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 ken...@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)
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)
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)
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)
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)
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)
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
Re: Why not contribute? (to GCC)
On Sun, 25 Apr 2010 12:00:13 -0400 Alfred M. Szmidt a...@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)
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)
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)
On Mon, 26 Apr 2010 12:50:14 -0400 Alfred M. Szmidt a...@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)
On Mon, Apr 26, 2010 at 6:08 PM, Jonathan Corbet cor...@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)
On Mon, Apr 26, 2010 at 7:03 PM, Steven Bosscher stevenb@gmail.com wrote: On Mon, Apr 26, 2010 at 6:08 PM, Jonathan Corbet cor...@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)
Mark Mielke m...@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)
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)
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)
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)
Chris Lattner clatt...@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)
Jonathan Corbet cor...@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)
On 26 April 2010 21:28, Ian Lance Taylor i...@google.com wrote: Jonathan Corbet cor...@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)
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)
On Apr 26, 2010, at 12:23 PM, Ian Lance Taylor wrote: Chris Lattner clatt...@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)
Chris Lattner clatt...@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)
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)
On 04/26/2010 10:53 PM, Ian Lance Taylor wrote: Chris Lattnerclatt...@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: t...@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)
Paolo Bonzini bonz...@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
Re: Why not contribute? (to GCC)
On 04/26/2010 03:23 PM, Ian Lance Taylor wrote: Chris Lattnerclatt...@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)
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)
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)
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)
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)
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)
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)
Mark Mielke m...@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)
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)
On 25 April 2010 06:20, Chris Lattner clatt...@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 a...@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)
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)
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)
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)
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)
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)
On Sun, Apr 25, 2010 at 3:00 PM, Richard Kenner ken...@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)
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)
On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote: On 25 April 2010 06:20, Chris Lattner clatt...@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 a...@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)
On 25 April 2010 16:55, Chris Lattner clatt...@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 clatt...@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 a...@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)
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)
On Sun, Apr 25, 2010 at 8:04 AM, Chris Lattner clatt...@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)
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)
On Sat, 24 Apr 2010 08:51:17 -0400 Alfred M. Szmidt a...@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)
On Sun, Apr 25, 2010 at 5:34 PM, Jonathan Corbet cor...@lwn.net wrote: On Sat, 24 Apr 2010 08:51:17 -0400 Alfred M. Szmidt a...@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)
On 25 April 2010 17:44, Steven Bosscher stevenb@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)
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)
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)
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)
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)
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)
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)
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)
On Sun, Apr 25, 2010 at 11:33, Richard Kenner ken...@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)
On 25 April 2010 18:48, Michael Witten mfwit...@gmail.com wrote: On Sun, Apr 25, 2010 at 11:33, Richard Kenner ken...@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)
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)
The FSF copyright assignments grant you back ultimate rights to use it in anyway you please.
Re: Why not contribute? (to GCC)
On Sun, Apr 25, 2010 at 6:48 PM, Michael Witten mfwit...@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)
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)
On 25 April 2010 17:04, Chris Lattner clatt...@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)
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)
Ralf Wildenhues ralf.wildenh...@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)
On Sun, Apr 25, 2010 at 7:23 PM, Richard Kenner ken...@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)
Chris Lattner clatt...@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)
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)
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)
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)
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)
On 04/23/2010 08:47 PM, Ian Lance Taylor wrote: Basile Starynkevitchbas...@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)
On Sun, Apr 25, 2010 at 2:40 PM, Eric Botcazou ebotca...@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.
