now that stage3 is over I'm thinking of updating the
MaverickCrunch FPU fixes (currently for 4.3) and merging them but
would appreciate some guidance.
There are 26 patches in all and I can't expect anyone to understand
them because they require a good understanding of the FPU and its
hardware bugs
On 25 April 2010 06:20, Chris Lattner wrote:
>
> On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
>
>> On 24 April 2010 00:18, Alfred M. Szmidt wrote:
>>>
>>> The disclaimers are legally necessary though, the FSF needs a paper
>>> trail in the case your employer comes back and claims that
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 maj
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
Richard Guenther wrote:
On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene wrote:
lto-symtab.c:549:
524
525 /* Helper to process the decl chain for the symbol table entry *SLOT.
*/
526
527 static int
528 lto_symtab_merge_decls_1 (void **slot, void *data ATTRIBUTE_UNUSED)
> > 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
> 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
> 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
Noticed that gcc 4.3.4 doesn't optimize "add with carry" properly:
static u32
add32carry(u32 sum, u32 x)
{
u32 z = sum + x;
if (sum + x < x)
z++;
return z;
}
Becomes:
add32carry:
add 3,3,4
subfc 0,4,3
subfe 0,0,0
subfc 0,0,3
mr 3,0
Instead of:
On Sun, Apr 25, 2010 at 3:00 PM, Richard Kenner
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,
>> yo
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
On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote:
> On 25 April 2010 06:20, Chris Lattner wrote:
>>
>> On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
>>
>>> On 24 April 2010 00:18, Alfred M. Szmidt wrote:
The disclaimers are legally necessary though, the FSF needs a
On 25 April 2010 16:55, Chris Lattner wrote:
>
> On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote:
>
>> On 25 April 2010 06:20, Chris Lattner wrote:
>>>
>>> On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
>>>
On 24 April 2010 00:18, Alfred M. Szmidt wrote:
>
> The disc
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
On Sun, Apr 25, 2010 at 8:04 AM, Chris Lattner 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 i
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.
On Sat, 24 Apr 2010 08:51:17 -0400
"Alfred M. Szmidt" 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 as
On Sun, Apr 25, 2010 at 5:34 PM, Jonathan Corbet wrote:
> On Sat, 24 Apr 2010 08:51:17 -0400
> "Alfred M. Szmidt" 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
On 25 April 2010 17:44, Steven Bosscher 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 k
IANAL but the copyright assignment is probably necessary for the
FSF to have the rights to change the license at will (within the
limitations allowed by the copyright assignment). If there are many
copyright holders, like for say the linux kernel, a change of
license requires the app
> Not much can be done to either of those, the copyright assignments are
> necessary to keep GCC legally safe.
Given that there are plenty of high-profile projects out there
which seem to be entirely safe in the absence of copyright
assignment policies, why, exactly, does GCC need o
> > 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
> 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 s
> 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 unty
> 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
> 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?
On Sun, Apr 25, 2010 at 11:33, Richard Kenner
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, de
On 25 April 2010 18:48, Michael Witten wrote:
> On Sun, Apr 25, 2010 at 11:33, Richard Kenner
> 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 ow
> 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 "
The FSF copyright assignments grant you back ultimate rights to use
it in anyway you please.
On Sun, Apr 25, 2010 at 6:48 PM, Michael Witten 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
> 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 copyri
On 25 April 2010 17:04, Chris Lattner 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 co
> 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
Ralf Wildenhues 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
On Sun, Apr 25, 2010 at 7:23 PM, Richard Kenner
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 d
Chris Lattner 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),
Jon writes:
> Ian Lance Taylor wrote, On 15/03/10 03:12:
>> Jon writes:
>>
>>> How long is it until back in stage 1 development phase?
>>
>> Reasonably soon, I hope, but there is no specific schedule.
>
> Hi Ian,
> Just wanted to ask if it had been possible to integrate the patch.
We are now ba
Martin Guy writes:
> now that stage3 is over I'm thinking of updating the
> MaverickCrunch FPU fixes (currently for 4.3) and merging them but
> would appreciate some guidance.
>
> There are 26 patches in all and I can't expect anyone to understand
> them because they require a good understanding
Joakim Tjernlund writes:
> Noticed that gcc 4.3.4 doesn't optimize "add with carry" properly:
Please file a missed-optimization report according to
http://gcc.gnu.org/bugs/ . Thanks.
Ian
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 assignm
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 mak
On Sun, Apr 25, 2010 at 1:24 PM, Toon Moene wrote:
> Richard Guenther wrote:
>
>> On Sat, Apr 24, 2010 at 3:28 PM, Toon Moene wrote:
>
>>> lto-symtab.c:549:
>>>
>>> 524
>>> 525 /* Helper to process the decl chain for the symbol table entry
>>> *SLOT.
>>> */
>>> 526
>>> 527 static int
>>>
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 (
On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther
wrote:
>
> No, gold should choose a single prevailing definition. The issue is that
> gold and the linker-plugin seem to be unmaintained.
Looking at the binutils list, there seems to be a lot of gold patching
going on. Why do you believe it is un
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 &
On 04/23/2010 08:47 PM, Ian Lance Taylor wrote:
Basile Starynkevitch 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 pa
On Sun, Apr 25, 2010 at 2:40 PM, Eric Botcazou 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
On Sun, Apr 25, 2010 at 9:37 PM, Steven Bosscher wrote:
> On Sun, Apr 25, 2010 at 9:26 PM, Richard Guenther
> wrote:
>>
>> No, gold should choose a single prevailing definition. The issue is that
>> gold and the linker-plugin seem to be unmaintained.
>
> Looking at the binutils list, there seems
On 25 April 2010 20:03, Ian Lance Taylor wrote:
> Jon writes:
>
>> Ian Lance Taylor wrote, On 15/03/10 03:12:
>>> Jon writes:
>>>
How long is it until back in stage 1 development phase?
>>>
>>> Reasonably soon, I hope, but there is no specific schedule.
>>
>> Hi Ian,
>> Just wanted to ask i
> Whatever their reasons, this has very little to do with GCC. If
> copyright assignment is an obstacle for contributing to GCC, we should
> do something about that (clarify the reasons, simplify and speed up
> the process, etc.). Let's talk about that instead :-)
This discussion is part of "clari
Hi Manuel
Manuel López-Ibáñez wrote, On 25/04/10 22:00:
[.]
Jon, would you mind writing a proper Changelog?
I've attached the Changelog I wrote before. I can change if needed,
let me know what info I should add.
I will test that the patch still passes the regression test and commit
it for
> because the only reason copyright needs to be assigned (AFAIK) is to
> change the license.
False. See a discussion of this earlier in the thread.
> The LLVM project does not aim to be able to change the license in the
> future,
Nobody "aims" to change something in the future, but nobody has
On 19/04/2010 01:45, Dave Korn wrote:
> Something strange, unexpected and a bit alarming happened:
For context, it is necessary to explain that I was testing a patch (target
i686-pc-linux-gnu running on FC10) that mechanically renamed a bunch of
functions matching "lto_elf_*" to match "lto_ob
> 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 i
Hey,
I was recently reading through the wiki pages of the LTO branch and
found several open items in the ToDo list which are generally interesting.
I mainly kept an eye on item 7 (Browsing/dumping tools for LTO files),
which seems for me to be a good task to deepen the knowledge about GCC
in
On 04/25/2010 11:20 AM, H.J. Lu wrote:
On Sun, Apr 25, 2010 at 8:04 AM, Chris Lattner wrote:
On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote:
So, is the copyright disclaimer implicit in the patch submission? Who
defines the conditions?
That web page is everything that
On 25 April 2010 23:17, Jon wrote:
> Hi Manuel
>
> Manuel López-Ibáñez wrote, On 25/04/10 22:00:
> [.]
>>
>> Jon, would you mind writing a proper Changelog?
>
> I've attached the Changelog I wrote before. I can change if needed, let me
> know what info I should add.
Ideally, the format should fol
> 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
> So how much liability is required for somebody to accept in order to be
> allowed to contribute to GCC?
This was answered already. It's the same for EVERY software project
(not unique to GCC): if I steal somebody's copyrighted material and
"contribute" it to a software project, I am liable for
On 25 April 2010 23:35, Andi Hellmund wrote:
>
> It is not only related to this ToDo list of LTO, but to all ToDo lists in
> the wiki. I think we should try to keep the ToDo lists up-to-date in the
> sense that someone working on an item should put his/her name in the list to
> signal that this it
On 25/04/2010 21:41, Richard Guenther wrote:
> I'm somewhat uncomfortable that we have the two paths into LTO,
> by using collect2 or the linker plugin. Unfortunately the linker-plugin
> is currently the only path that supports LTOing static libs. As soon
> as that issue is solved we should IMHO
On 04/25/2010 05:49 PM, Richard Kenner wrote:
So how much liability is required for somebody to accept in order to be
allowed to contribute to GCC?
This was answered already. It's the same for EVERY software project
(not unique to GCC): if I steal somebody's copyrighted material and
"cont
On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn
wrote:
> Is there a PR open about this, or any notes anywhere? Being as I use a
> non-ELF platform and so gold is not an option, I'd be pleased to help with
> making this work.
See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00015.html for some
firs
> Yep - but that's my point. "Full extent" without any number listed is
> effectively unlimited liability.
But what does that have to do with the FSF, GCC, or an assignment agreement?
You have EXACTLY THE SAME unlimited liability if you contribute to GCC,
LLVM, Linux, ECLIPSE, or any other proje
Snapshot gcc-4.3-20100425 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100425/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 04/25/2010 06:27 PM, Richard Kenner wrote:
I couldn't see somebody suing me (my bank account hovers pretty low
most of the time). Companies are not going to sue nobodies such as
myself because there is no money in it. So, in practice, is there a
difference or not?
No, because then the F
> Obviously there is a difference, otherwise FSF wouldn't be requesting
> copyright assignment.
I didn't say there's no different AT ALL: of course there is and that's
indeed why the assignment is needed. What we were talking about is whether
there's a difference in the LIABILITY of a patch aut
On Sun, Apr 25, 2010 at 08:12:03PM -0400, Mark Mielke wrote:
...
> In some ways, I wish a group did fork GCC under GPL and drop the
> copyright assignment requirement. In other ways, this entire issue is
> just so minor to me that it isn't worth going beyond this thread. GCC
> works, but so d
> Is it even possible to fork? Wouldn't that require the new compiler
> to start over again from the last non-GPLv3 version of the source code
> (read 4.2.1...which is why Apple's gcc is stuck there). Weren't things
> simplier when egcs forked from gcc (ie that they were both under the same
> licen
On 26 April 2010 02:29, Jack Howarth wrote:
> On Sun, Apr 25, 2010 at 08:12:03PM -0400, Mark Mielke wrote:
> ...
>> In some ways, I wish a group did fork GCC under GPL and drop the
>> copyright assignment requirement. In other ways, this entire issue is
>> just so minor to me that it isn't worth g
On 25/04/2010 23:16, Steven Bosscher wrote:
> On Mon, Apr 26, 2010 at 12:27 AM, Dave Korn wrote:
>
>> Is there a PR open about this, or any notes anywhere? Being as I use a
>> non-ELF platform and so gold is not an option, I'd be pleased to help with
>> making this work.
>
> See http://gcc.gnu.
On 26 April 2010 02:12, Mark Mielke wrote:
>
> All in all, pretty minor. GCC wants FSF copyright assignment and employer
> disclaimers? GCC will not have as many contributors. Your choice.
>
> There are plenty of projects that we (lurkers / non contributors) can
> contribute to other projects that
On Sun, Apr 25, 2010 at 21:12, Manuel López-Ibáñez
wrote:
> On 26 April 2010 02:12, Mark Mielke wrote:
>>
>> All in all, pretty minor. GCC wants FSF copyright assignment and employer
>> disclaimers? GCC will not have as many contributors. Your choice.
>>
>> There are plenty of projects that we (l
> Also, Mark's point (I think) is that a copyright lawsuit against the
> FSF is much more likely than a lawsuit against some no-name
> contributor, and (more importantly) a lawsuit against the FSF is
> likely to trigger the FSF to launch a lawsuit against the individual
> contributor. Thus, it sort
On 26/04/2010 03:32, Michael Witten wrote:
> I thought it was decided in the course of this thread that the
> liability of an individual contributor is ultimately NOT changed by
> the assignment of the copyrights to the FSF.
>
> Also, Mark's point (I think) is that a copyright lawsuit against the
On 26/04/2010 01:12, Mark Mielke wrote:
> On 04/25/2010 06:27 PM, Richard Kenner wrote:
>>> I couldn't see somebody suing me (my bank account hovers pretty low
>>> most of the time). Companies are not going to sue nobodies such as
>>> myself because there is no money in it. So, in practice, is th
> 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 som
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 there
> I think it is possible that some of the people who have (or have had)
> trouble with the process with their employers, would find it easier if they
> realised that the assignment was something they can do without anyone's
> permission regardless of the terms of their employment, and subsequently
On 26/04/2010 04:32, Richard Kenner wrote:
>> I think it is possible that some of the people who have (or have had)
>> trouble with the process with their employers, would find it easier if they
>> realised that the assignment was something they can do without anyone's
>> permission regardless of t
Manuel López-Ibáñez writes:
> Ian, how can I check that there is a copyright assignment in place?
http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html
Jon does have a copyright assignment.
Ian
Dave Korn writes:
> I don't quite see that. If the company disclaims ownership of the
> stuff that you create working on GCC as part of your job, well, they've
> disclaimed ownership of it, regardless of the fact that you created it
> while working on GCC as part of your job, no? Berne conven
> I don't quite see that. If the company disclaims ownership of the
> stuff that you create working on GCC as part of your job, well, they've
> disclaimed ownership of it, regardless of the fact that you created it
> while working on GCC as part of your job, no?
My point is that they aren't lik
> I believe the contract would have to explicitly say that this is
> *not* the case for you to be able to retain ownership of copyright
> of work that you did for hire.
That's my understanding as well, but where it gets tricky is whether
a SEPARATE disclaimer would have the effect of doing that as
Mark Mielke 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
On 26/04/2010 05:28, Richard Kenner wrote:
>> I believe the contract would have to explicitly say that this is
>> *not* the case for you to be able to retain ownership of copyright
>> of work that you did for hire.
>
> That's my understanding as well, but where it gets tricky is whether
> a SEPARA
> Expressing the same idea in different code is not a copyright violation.
Unlike patents, in copyright law, whether something is infringing
strongly depends on whether you actually COPIED something. Writing a
piece of code to do the same as another piece of code that you're looking
at when doing
On Sun, Apr 25, 2010 at 12:36:46PM -0400, Richard Kenner wrote:
> I said "A" large part. There is certainly a perception that the
> copyright assignment is an issue too. But, as was discussed here, there
> IDENTICAL liability with and without the assignment. So this is illusory.
Oh please. Ask
On Apr 25, 2010, at 2:30 PM, Richard Kenner wrote:
>> The LLVM project does not aim to be able to change the license in the
>> future,
>
> Nobody "aims" to change something in the future, but nobody has a crystal
> ball either and it can often be hard to predict what might have to be done
> in th
> [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 wh
> > If there's no such document, then what does the project do if, unknown to
> > them, some employee of a large company contributed code without the
> > permission of his employer, the project distributes that code, and then the
> > large software company sues for infringment?
>
> This would be o
92 matches
Mail list logo
