27 Nov
2005
27 Nov
'05
4:11 p.m.
The discussion is located here:
http://www.reactos.org/archives/public/ros-dev/2005-October/005671.html
I will create a vote with the options below.
Proposal A from Ged Murphy:
/*
* ReactOS <place holder>
* Copyright (C) 2005 ReactOS Foundation
*
* LICENCE: <place holder>
* PROJECT: <place holder>
* FILE: <place holder>
* PURPOSE: <place holder>
* PROGRAMMERS: <place holder>
* REVISIONS:
* <place holder>
*
*/
Proposal B from Alex Ionescu:
/*
* PROJECT: ReactOS Kernel
* LICENSE: GPL - See COPYING in the top level directory
* FILE: ntoskrnl/ex/mutant.c
* PURPOSE: section of the kernel
* PROGRAMMERS: Alex Ionescu (alex at reactos.org)
* David Welch (welch at cwcom.net)
*/
Proposal C from Casper Hornstrup/Gé van Geldorp:
/*
* PROJECT: ReactOS Kernel
* LICENSE: GPL - See COPYING in the top level directory
* COPYRIGHT: Copyright 2004-2005 John Doe
* Copyright 2005 Jane Doe
*/
5:35 p.m.
I've seen a disturbing increase of arguments in ros-dev over the last
year on various issues such as this one, and the direction we're heading
really has me concerned.
This proposal won't even work for vendor drops, but I'm more concerned
with the larger picture.
Every time we have a disagreement, we put up a vote so the group can
decide "this is how it's going to be". What I fear is going to happen is
the next time someone oversteps something we've voted on, now people
have an excuse to publically lampoon that person. This is only going to
drive away developers. ReactOS is still a hobby OS. It's an open source
project that most of us do because we love the vision of ReactOS and
mostly because it's fun and rewarding to make it better.
Today, we're voting the exact allowed format of headers - for which
somebody is going to have the excruciatingly boring job of changing all
the headers that are non-compliant. What if a year from now we have 30
more developers and enough are dissatisfied with the header and a new
vote is taken that changes the format. We're wasting a lot of time and
energy over something that really doesn't matter! Who cares what the
format of the header is, really? As long as it conveys the necessary
copyright information, the rest is fluff. What if someone *wants* or
feels the need to put more? Now he's going to be penalized because he
added something unofficial to the official header. This is foolishness.
I'll give a good example of what I'm talking about. We've had various
heated discussions in the past regarding the subject of code styling.
Some have proposed to vote on an official style. I and a couple others
have fought vehemently against setting a hard standard. We all use
different editors that we're comfortable and most efficient in. And each
editor has different weaknesses regarding certain code styles. The most
often proposed code style is poorly handled by the editor I use by
default, for example.
I think this vote should be cancelled. It has no place in our policies
and guidelines. Now, if someone wants to step up and pay me for my time
to develop ReactOS, then I'll happily submit to all the coding
strictures they feel are necessary. It'd be my place to interject where
I think they are wrong, but as a paid employee it wouldn't be my place
to ignore or rebel against them. Until that day, we need to keep ReactOS
a fun project to work - we've got too much work to do for it to be any
other way.
I say it again, I think this vote is wrong, and should be cancelled and
rethought.
Peace,
Royce
6:34 p.m.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Royce
Mitchell
III
Sent: 27. november 2005 18:35
To: ReactOS Development List
Subject: Re: [ros-dev] [Vote] Top-level source header
Every time we have a disagreement, we put up a vote so the group can
decide "this is how it's going to be". What I fear is going to happen is
the next time someone oversteps something we've voted on, now people
have an excuse to publically lampoon that person. This is only going to
drive away developers. ReactOS is still a hobby OS. It's an open source
project that most of us do because we love the vision of ReactOS and
mostly because it's fun and rewarding to make it better.
A project rule doesn't give you the right to ridicule people. It merely
says "this it the way we do it" until such time that the rule is changed.
It's a fact of life that within a group of people there will be disputes,
so we need a way to resolve these disputes and currently we have voting
to do that. If you know of a more effective method than voting then feel
free to share it.
By making project rules we can better avoid the "I'll rewrite it this way
because my way is better" class of changes. Without project rules, it is
the last one to commit that "wins".
Today, we're voting the exact allowed format of
headers - for which
somebody is going to have the excruciatingly boring job of changing all
the headers that are non-compliant. What if a year from now we have 30
more developers and enough are dissatisfied with the header and a new
vote is taken that changes the format. We're wasting a lot of time and
energy over something that really doesn't matter! Who cares what the
format of the header is, really? As long as it conveys the necessary
copyright information, the rest is fluff.
Apparently you do as you just stated that there should be copyright
information in the header.
What if someone *wants* or feels the need to put
more?
Now he's going to be penalized because he
added something unofficial to the official header. This is foolishness.
That's what comments are for.
I'll give a good example of what I'm talking
about. We've had various
heated discussions in the past regarding the subject of code styling.
Some have proposed to vote on an official style. I and a couple others
have fought vehemently against setting a hard standard. We all use
different editors that we're comfortable and most efficient in. And each
editor has different weaknesses regarding certain code styles. The most
often proposed code style is poorly handled by the editor I use by
default, for example.
That you or someone else don't like a change shouldn't prevent someone
else from trying to make that change. Which person or persons should
decide which changes shouldn't be allowed to be proposed? If you don't
like what someone else proposes, then you can use your right to vote to
stop that change within the project.
I think this vote should be cancelled. It has no place
in our policies
and guidelines. Now, if someone wants to step up and pay me for my time
to develop ReactOS, then I'll happily submit to all the coding
strictures they feel are necessary. It'd be my place to interject where
I think they are wrong, but as a paid employee it wouldn't be my place
to ignore or rebel against them. Until that day, we need to keep ReactOS
a fun project to work - we've got too much work to do for it to be any
other way.
I say it again, I think this vote is wrong, and should be cancelled and
rethought.
Peace,
Royce
Sorry, I can't do that. Feel free to vote Further Discussion though
and/or put up a new vote with a proposal to "let the developer
choose/change/remove the contents of the headers at his will".
Casper
7:01 p.m.
Casper Hornstrup wrote:
A project rule doesn't give you the right to ridicule people. It merely
says "this it the way we do it" until such time that the rule is changed.
It's a fact of life that within a group of people there will be disputes,
so we need a way to resolve these disputes and currently we have voting
to do that. If you know of a more effective method than voting then feel
free to share it.
By making project rules we can better avoid the "I'll rewrite it this way
because my way is better" class of changes. Without project rules, it is
the last one to commit that "wins".
I don't disagree with this, but as I stated before this is an open
source unpaid project, so we should only have so many rules as are
strictly necessary. We should take great care about the rules we create.
Too many rules - especially frivolous ones, and we'll drive potential
developers and even existing developers away.
Apparently you do as you just stated that there should
be copyright
information in the header.
I stated that copyright information is important. What I did not state
was the exact formatting. I'll give the benefit of the doubt that you're
not intending the exact indentation and order of parameters to be
specified by the vote, but that's not made clear.
Furthermore, this vote seems to have started in part because you
complained that a header copied from another file didn't get updated
properly. I can only assume that means you intend to have removed parts
of the headers that are in excess of the agreed-upon header in the vote.
That's what comments are for.
As I just stated, you were complaining about comments in the header
about the name of the file that you felt shouldn't be there. Where do we
draw this line of what's an allowed comment?
That you or someone else don't like a change
shouldn't prevent someone
else from trying to make that change. Which person or persons should
decide which changes shouldn't be allowed to be proposed? If you don't
like what someone else proposes, then you can use your right to vote to
stop that change within the project.
Even this is a gray area, because if someone is making changes to an
area nobody else wants to touch... well... maybe I don't like it, but if
I'm not willing to fix a perceived problem but someone else is, then how
much right do I have to complain.... it's like the story of the little
red hen: nobody wanted to help her bake the bread, but they all wanted
to eat it. All I'm saying is that we should try to limit our complaints
about other people's changes just because we don't "like" them.
We're
never going to all agree completely on how things should be done. We
need to agree to disagree and only invoke this kind of policy-setting
when it's really important. I think at a minimum we need to more
carefully word the proposals for the top-level source header issue here
- in order to solve the problem without unnecessarily constraining
freedom to develop in each of our own styles.
Sorry, I can't do that. Feel free to vote Further
Discussion though
and/or put up a new vote with a proposal to "let the developer
choose/change/remove the contents of the headers at his will".
I went ahead and selected further discussion, as it seems the most
prudent way to pursue my feelings on the issue. If not enough people
feel as I do, there's no point wasting effort creating another vote.
Thanks!
9:09 p.m.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Royce
Mitchell
III
Sent: 27. november 2005 20:02
To: ReactOS Development List
Subject: Re: [ros-dev] [Vote] Top-level source header
Casper Hornstrup wrote:
I agree, but I trust people to use their best judgement. If 90% vote for
something which I think is crazy, who am I to say this shouldn't be how
the project will do it?
By making project rules we can better avoid the
"I'll rewrite it this way
because my way is better" class of changes. Without project rules, it is
the last one to commit that "wins".
I don't disagree with this, but as I stated before this is an open
source unpaid project, so we should only have so many rules as are
strictly necessary. We should take great care about the rules we create. Too many rules - especially frivolous ones, and
we'll drive potential
developers and even existing developers away.
I could say the same about too few rules. Remember that what one person
does, affects the other persons on the project. I suppose I would like
ReactOS to be somewhere on the middle of this line.
No rules Many rules
<----------------------------------------------------------->
Chaos/inconsistency order/consistency
E.g. having order/consistency where is helps the group function well
and help the group create a better product. I know ReactOS is about
having fun, but I don't think that not being able to do whatever you feel
like with regard to the project implies no fun. Certainly being in the
chaos/inconsistency state (we've been there) won't create a happy team.
I remember times when ReactOS often couldn't be built or booted for weeks
at a time. In the early days, I just spent my time elsewhere when that
happened. ReactOS wasn't useful anyway.
I recently joined a 15 person team who were working on some project.
This project was close to the no rules/chaos end of that line. Of course
the project was more than 100% over budget and half of the team worked
60-70 hours/week for two months. They were of course unhappy about that,
but they really wanted to have this product ready for their customer.
Nobody likes to fail. For those of you who are interested in numbers,
that is a burn-rate of approx. 700 hours/week. I'll leave it as an
exercise to the reader to calculate their salary per week ;-) Hint:
additional hours over 37 hours/week pays 100% extra.
I see similarity in the ReactOS project. I see many desperately waiting
for that 1.0 release. Now since nobody is paid to work on ReactOS, the
project can't go 100% over budget. We can however spend twice or more as
many hours getting there, depending on how we choose to develop ReactOS.
So instead of reaching 1.0 in 2010 we have to wait until 2022. I'm not
a patient person.
Furthermore, this vote seems to have started in part
because you
complained that a header copied from another file didn't get updated
properly. I can only assume that means you intend to have removed parts
of the headers that are in excess of the agreed-upon header in the vote.
Well, the voting is about what the standard should be (e.g. for new files).
It doesn't specify anything about what to do with the existing headers.
They could be replaced over time for instance.
That's what
comments are for.
As I just stated, you were complaining about comments in the header
about the name of the file that you felt shouldn't be there. Where do we
draw this line of what's an allowed comment? That you or
someone else don't like a change shouldn't prevent someone
else from trying to make that change. Which person or persons should
decide which changes shouldn't be allowed to be proposed? If you don't
like what someone else proposes, then you can use your right to vote to
stop that change within the project.
Even this is a gray area, because if someone is making changes to an
area nobody else wants to touch... well... maybe I don't like it, but if
I'm not willing to fix a perceived problem but someone else is, then how
much right do I have to complain.... it's like the story of the little
red hen: nobody wanted to help her bake the bread, but they all wanted
to eat it. All I'm saying is that we should try to limit our complaints
about other people's changes just because we don't "like" them.
We're
never going to all agree completely on how things should be done. We
need to agree to disagree and only invoke this kind of policy-setting
when it's really important. I think at a minimum we need to more
carefully word the proposals for the top-level source header issue here
- in order to solve the problem without unnecessarily constraining
freedom to develop in each of our own styles. 
9:26 p.m.
Hi,
On 11/27/05, Casper Hornstrup <ch(a)csh-consult.dk> wrote:
Well, the voting is about what the standard should be
(e.g. for new files).
It doesn't specify anything about what to do with the existing headers.
They could be replaced over time for instance.
This is fine with me. I will be voting for C. Once we have a standard
I am sure we can find some Janitor that would love to help out by
standardising the source headers for all of the ReactOS code. As long
as this would not effect code we regularly import from other projects
its fine with me. Adding this to the code we have already forked and
or will not be trying to re-sync with seems like a good idea. However
we should not replace the existing license header in any third party
code we fork, we should append our header if we make major additions.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
10:32 p.m.
Hmm, can't we put the license in a svn property, too?
The project should be clear from the directory it is, and the copyright
should be clear from the SVN-History, if not, e.g. imports/vendor drops
from another projects, we could add a COPYRIGHT-file in these directories.
So we wouldn't need a header at all...
Or the header could be autogenerated on commit or on a checkout...
I would vote for d (further discussion), too.
I argumented that the contents of the FILE fields in the headers tend to
become wrong and thus useless over time. I can point you to at least four
new files added this week for which this is true. I can point you to
another
set of files where the PURPOSE and PROGRAMMER fields states "Unknown" just
because "something should be there".
The vote is about how the header should look like and there were three
suggestions. We have no rules for comments so you can put anything you
feel
like in a comment below the header. If you put the name of the file in a
comment in the file, then fine. I will however still argument that they
become wrong over time.
He has every right. If not, who decides that he hasn't the right?
He may not have good reasons to complain, and may just be annoying to
other people, but that's another issue.
Casper
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org]
On Behalf Of Royce Mitchell
III
Sent: 27. november 2005 20:02
To: ReactOS Development List
Subject: Re: [ros-dev] [Vote] Top-level source header
Casper Hornstrup wrote:
I agree, but I trust people to use their best judgement. If 90% vote for
something which I think is crazy, who am I to say this shouldn't be how
the project will do it?
By making project rules we can better avoid the
"I'll rewrite it this
way
because my way is better" class of changes.
Without project rules, it
is
the last one to commit that "wins".
I don't disagree with this, but as I stated before this is an open
source unpaid project, so we should only have so many rules as are
strictly necessary. We should take great care about the rules we create. Too many rules - especially frivolous ones, and
we'll drive potential
developers and even existing developers away.
I could say the same about too few rules. Remember that what one person
does, affects the other persons on the project. I suppose I would like
ReactOS to be somewhere on the middle of this line.
No rules Many rules
<----------------------------------------------------------->
Chaos/inconsistency order/consistency
E.g. having order/consistency where is helps the group function well
and help the group create a better product. I know ReactOS is about
having fun, but I don't think that not being able to do whatever you feel
like with regard to the project implies no fun. Certainly being in the
chaos/inconsistency state (we've been there) won't create a happy team.
I remember times when ReactOS often couldn't be built or booted for weeks
at a time. In the early days, I just spent my time elsewhere when that
happened. ReactOS wasn't useful anyway.
I recently joined a 15 person team who were working on some project.
This project was close to the no rules/chaos end of that line. Of course
the project was more than 100% over budget and half of the team worked
60-70 hours/week for two months. They were of course unhappy about that,
but they really wanted to have this product ready for their customer.
Nobody likes to fail. For those of you who are interested in numbers,
that is a burn-rate of approx. 700 hours/week. I'll leave it as an
exercise to the reader to calculate their salary per week ;-) Hint:
additional hours over 37 hours/week pays 100% extra.
I see similarity in the ReactOS project. I see many desperately waiting
for that 1.0 release. Now since nobody is paid to work on ReactOS, the
project can't go 100% over budget. We can however spend twice or more as
many hours getting there, depending on how we choose to develop ReactOS.
So instead of reaching 1.0 in 2010 we have to wait until 2022. I'm not
a patient person.
Furthermore, this vote seems to have started in
part because you
complained that a header copied from another file didn't get updated
properly. I can only assume that means you intend to have removed parts
of the headers that are in excess of the agreed-upon header in the vote.
Well, the voting is about what the standard should be (e.g. for new
files).
It doesn't specify anything about what to do with the existing headers.
They could be replaced over time for instance.
That's
what comments are for.
As I just stated, you were complaining about comments in the header
about the name of the file that you felt shouldn't be there. Where do we
draw this line of what's an allowed comment? That you
or someone else don't like a change shouldn't prevent someone
else from trying to make that change. Which person or persons should
decide which changes shouldn't be allowed to be proposed? If you don't
like what someone else proposes, then you can use your right to vote to
stop that change within the project.
Even this is a gray area, because if someone is making changes to an
area nobody else wants to touch... well... maybe I don't like it, but if
I'm not willing to fix a perceived problem but someone else is, then how
much right do I have to complain.... it's like the story of the little
red hen: nobody wanted to help her bake the bread, but they all wanted
to eat it. All I'm saying is that we should try to limit our complaints
about other people's changes just because we don't "like" them.
We're
never going to all agree completely on how things should be done. We
need to agree to disagree and only invoke this kind of policy-setting
when it's really important. I think at a minimum we need to more
carefully word the proposals for the top-level source header issue here
- in order to solve the problem without unnecessarily constraining
freedom to develop in each of our own styles. 
28 Nov
28 Nov
2:22 p.m.
Seeing some of the comments in this thread, I think it might be wise to
have rules/standards for stuff that really matter and classify the rest
as something like recommendations.
In the end, if you don't have 100% agreement on how something should be
done (including when new people join the dev team) it won't get done
that way all of the time - and even with 100% agreement, I would bet
things like this get ignored any time someone is in a hurry.
I've been watching the current commercial project I'm working on bypass
the way stuff is supposed to be done time and time again just to get
things done faster. And in the end, it only gets fixed if it's going to
save time in the future and/or it really annoys one of the developers.
Dennis
6:04 p.m.
Frank, you'll need to unsubscribe from the mailing list, to not
receieve messages.
On 11/30/05, frank.marx(a)t-online.de <frank.marx(a)t-online.de> wrote:
Please dont send me further emails !
Frank Marx
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
"I had a handle on life, but then it broke"
5 Dec
5 Dec
6:44 p.m.
Casper Hornstrup wrote:
The discussion is located here:
http://www.reactos.org/archives/public/ros-dev/2005-October/005671.html
The voting period is now over. Proposal B from Alex Ionescu is the winner:
Proposal B from Alex Ionescu:
/*
* PROJECT: ReactOS Kernel
* LICENSE: GPL - See COPYING in the top level directory
* FILE: ntoskrnl/ex/mutant.c
* PURPOSE: Manages the Kernel-Mode Implementation of Fast Mutex.
* See /hal/halx86/generic/fmutex.c for the HAL implementation.
* PROGRAMMERS: Alex Ionescu (alex(a)reactos.org)
* Filip Navara (navaraf(a)reactos.org)
*/
Best regards,
Alex Ionescu
8:08 p.m.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex
Ionescu
Sent: 5. december 2005 19:45
To: ReactOS Development List
Subject: Re: [ros-dev] [Vote] Top-level source header
The voting period is now over. Proposal B from Alex Ionescu is the winner:
Proposal B from Alex Ionescu:
/*
* PROJECT: ReactOS Kernel
* LICENSE: GPL - See COPYING in the top level directory
* FILE: ntoskrnl/ex/mutant.c
* PURPOSE: Manages the Kernel-Mode Implementation of Fast Mutex.
* See /hal/halx86/generic/fmutex.c for the HAL implementation.
* PROGRAMMERS: Alex Ionescu (alex(a)reactos.org)
* Filip Navara (navaraf(a)reactos.org)
*/
Best regards,
Alex Ionescu
Documented here:
http://www.reactos.org/wiki/index.php/Voting/Top-level_source_header
Casper
9 Dec
9 Dec
11:33 a.m.
New subject: Top-level source header
From: Alex Ionescu
The voting period is now over. Proposal B from Alex Ionescu
is the winner:
/*
* PROJECT: ReactOS Kernel
* LICENSE: GPL - See COPYING in the top level directory
* FILE: ntoskrnl/ex/mutant.c
* PURPOSE: Manages the Kernel-Mode Implementation of Fast Mutex.
* See /hal/halx86/generic/fmutex.c for the HAL
implementation.
* PROGRAMMERS: Alex Ionescu (alex(a)reactos.org)
* Filip Navara (navaraf(a)reactos.org)
*/
Sorry to keep on rambling about this, I know the vote is over and of course
I accept the outcome, but the simple fact is that this header does not
contain valid copyright notices. It lists the license (telling you what the
copyright holders allow you to do with the work), it lists the programmers
(who most probably are the copyright holders) but it does not contain valid
copyright notices, which (according to the US Copyright Office
http://www.copyright.gov/circs/circ1.html#noc) should have the following
form:
[begin quote]
The notice for visually perceptible copies should contain all the following
three elements:
1. The symbol C (the letter C in a circle), or the word "Copyright," or the
abbreviation "Copr."; and
2. The year of first publication of the work. In the case of compilations or
derivative works incorporating previously published material, the year date
of first publication of the compilation or derivative work is sufficient.
The year date may be omitted where a pictorial, graphic, or sculptural work,
with accompanying textual matter, if any, is reproduced in or on greeting
cards, postcards, stationery, jewelry, dolls, toys, or any useful article;
and
3. The name of the owner of copyright in the work, or an abbreviation by
which the name can be recognized, or a generally known alternative
designation of the owner.
[end quote]
So in our case something like
/*
* COPYRIGHT: Copyright 2005 Alex Ionescu (alex(a)reactos.org)
* Copyright 2005 Filip Navara (navaraf(a)reactos.org)
*/
The GPL says you can't remove an appropriate copyright notice, it says
nothing about not removing a PROGRAMMERS line. It would be very rude to
remove a PROGRAMMERS line, but not against the GPL.
GvG
5:29 p.m.
New subject: Top-level source header
Hi,
Ge van Geldorp wrote:
So in our case something like
/*
* COPYRIGHT: Copyright 2005 Alex Ionescu (alex(a)reactos.org)
* Copyright 2005 Filip Navara (navaraf(a)reactos.org)
*/
The GPL says you can't remove an appropriate copyright notice, it says
nothing about not removing a PROGRAMMERS line. It would be very rude to
remove a PROGRAMMERS line, but not against the GPL.
GvG
In this case I will and the other developers will have to put a copyright in
every
file!
Thanks,
James
7:13 p.m.
New subject: Top-level source header
James Tabor wrote:
In this case I will and the other developers will have
to put a
copyright in every
file!
Thanks,
James
What's wrong with that?
Considering the amount of work that has gone into this project, the code
should be correctly copyrighted.
7:40 p.m.
New subject: Top-level source header
I think the copyright line for the source files of ReactOS should go
somthing like this:
Copyright (C) 2005 ReactOS Delopement Team
Parts Copyright (C) 2005 ReactOS Foundation
Then list contibuters somewhere else.
On 12/9/05, Ged Murphy <gedmurphy(a)gmail.com> wrote:
James Tabor wrote:
--
My DeviantArt.com page: http://crashfourit.deviantart.com/
My FanFiction.net bio page: http://www.fanfiction.net/u/726606/
My Blog: http://crashfourit.blogspot.com/
America's Debate: http://www.americasdebate.com/
In this case I will and the other developers will
have to put a
copyright in every
file!
Thanks,
James
What's wrong with that?
Considering the amount of work that has gone into this project, the code
should be correctly copyrighted.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
7:52 p.m.
New subject: Top-level source header
From: crashfourit
I think the copyright line for the source files of ReactOS should go
somthing like
this:
Copyright (C) 2005 ReactOS Delopement Team
Parts Copyright (C) 2005 ReactOS Foundation
Then list contibuters somewhere else.
We've been over this before. The developers individually hold the copyright,
not the ReactOS foundation (and "ReactOS Development Team" isn't a legal
entity). So the individual developers claiming copyright must be named.
GvG
7:54 p.m.
New subject: Top-level source header
ReactOS Development Team isn't a legal entity and ReactOS Foundation don't get
copyright until the copyright holder signs over the
copyright to the foundation.
Casper
_____
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of
crashfourit
Sent: 9. december 2005 20:40
To: ReactOS Development List
Subject: Re: [ros-dev] Top-level source header
I think the copyright line for the source files of ReactOS should go somthing like this:
Copyright (C) 2005 ReactOS Delopement Team
Parts Copyright (C) 2005 ReactOS Foundation
Then list contibuters somewhere else.
On 12/9/05, Ged Murphy <gedmurphy(a)gmail.com> wrote:
James Tabor wrote:
In this case I will and the other developers will have
to put a
copyright in every
file!
Thanks,
James
What's wrong with that?
Considering the amount of work that has gone into this project, the code
should be correctly copyrighted.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
My DeviantArt.com page: http://crashfourit.deviantart.com/
My FanFiction.net bio page: http://www.fanfiction.net/u/726606/
My Blog: http://crashfourit.blogspot.com/
America's Debate: http://www.americasdebate.com/
6955
days inactive
6967
days old
19 comments
12 participants
participants (12)
-
Alex Ionescu -
Casper Hornstrup -
crashfourit -
Dennis - Guardian -
frank.marx＠t-online.de -
Ge van Geldorp -
Ged Murphy -
James Tabor -
michael＠fritscher.net -
Royce Mitchell III -
Steven Edwards -
TwoTailedFox