You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@apache.org> on 2005/06/08 00:08:15 UTC
[Legal] Requirements for Committers
NOTE : THE FOLLOWING IS FOR DISCUSSION PURPOSES. THIS PROPOSAL GOES
BEYOND STANDARD APACHE PRACTICE, AND WILL HAVE TO BE REVIEWED - IF WE
CHOOSE TO FOLLOW THIS ROUTE - BY THE ASF.
There are many legal and political concerns about the Apache Harmony
project, and it behooves us to do the best job we can at all times in
ensuring that the software contributed or created by the community is
as "clean" (in the IP sense) as possible. We do this to protect the
ASF, the committers, and the users of the software.
There are are few issues that come to mind when thinking about
committers :
1) What IP has the committer been exposed to,
and what is the position of the owner of that IP
with respect to the committer's participation?
For example, has the committer been exposed to
copyrighted or patented material, in which an
accidental re-creation would put the project
or users at risk of legal action from the
IP owner?
2) If people have been exposed to code that would be
problematic for us, what can we do to allow the maximum
participation with the minimal risk?
3) How do we ensure that we carefully track our
committers and what they've been exposed to?
To solve, consider the following :
I. Division of Repository
-------------------------
For starters, we can divide our SVN repository into parts :
1) JVM
- VM
- JIT
- GC
- etc
2) Class library
- VM/lib interface :-b
3) Website and Documentation
and we limit access to the SVN to which your contributions have no
"taint" as we understand it at the moment. Because attitudes will
change over time, I think that "taint" can go away as an individual's
issue that causes the 'taint' gets resolved.
We can start with access for website and docs immediately w/o much
consideration for 'taint'.
II. Specific Access Control Lists
----------------------------------
Through fine-grained (as necessary) access control lists for the SVN
repo, we'll allow committers into repos for project components for
which they have no "taint". If they've worked on Sun's class
libraries in the past but no exposure to VM, we keep them from any
class library work we do (if any) and allow them into VM-related code.
I think for simplicity in accounting, we should be conservative and
explicit about access. You are granted access only to repos that you
ask to be granted access to (although with the exception of the
"taint" issue, we should grant to anything asked for...) and
encourage people to keep their personal list small, and ask for
access to be removed if they no longer need it.
III. Strict Limits on Committer Contribution
---------------------------------------------
Committers can only commit contributions to the repositories that
they personally created specifically for contribution to Apache
Harmony. This is the standard stream of fresh original work, small
enhancements and patches that are the normal flow of project life.
The purpose of this rule is to explicitly prohibit re-purposed "bulk"
code that the contributor believes is their original work. We can
still accept those, but wish to track them explicitly.
IV. Be Proactive in Committer Education
---------------------------------------
People sometimes forget or don't understand the intricacies of
copyright and authorhsip, and just want to get work done. Therefore,
we should make a special effort to remind the committers of the
limits, give them clear information on what to do if a commit isn't w/
in the rules, and where to ask questions (and a list of answered
questions for reference).
We could have this as part of a standard svn commit message template,
for example. Other ideas welcome.
V. Required Committer Paperwork
-------------------------------
Each committer is required to complete an standard Apache Individual
Contributor License Agreement. This document asserts that the
contributor is licensing their material to the ASF under the Apache
license and is their original work (there's some other details).
For employed committers where it's appropriate, I'm interested in
what we can do to get validation that the employer doesn't own the
rights to the employee's work in the project. While this is not
applicable to many legal jurisdictions, it is applicable to the US,
and an element of concern here for Apache Harmony. We don't want
code to be contributed that will later be deemed to be a work for
hire or other kind of property of the employer, and thus give a third
party some claim on us or our users.
We would like to know who is contributing to the project. To this
end, we might consider a form asking information like the following.
This goes beyond standard ASF practice, and we would of course have
this reviewed and approved by ASF lawyers and other interested
members of the community (yes, it's fairly conservative...) :
-------------------------------------------
1) Identification
Please provide the following information
- Name (real name, please)
- E-mail and other electronic contact information
- Mailing address (include Country)
- If you have an employer, include name and address of employer
2) Access to Repositories :
Apache Harmony would like to limit write access to repositories
to those that need it, but will grant all that is asked for as long
as there are no 'taint' issues.
- Which components are you interested in working on?
3) Taint
The Project is committed to producing an implementation of Java that
can be licensed freely under the Apache License. To do this,
only those who have not accessed the source code for other
implementations of the applicable project components (or the
source code for the corresponding classes from other Java platforms)
will be permitted to commit to those components.
The following activities are not considered “accessing’ the
source code and would not generally disqualify you from
committing to the related repository here at Apache Harmony
a) Having a copy of src.jar on a computer as long as you never
viewed or edited the contents of the file.
b) While running a debugger on a Java language program, having
had occasion to step into the source code for the implementation
as long as you did not attempt to understand or debug the
implementation code itself.
c) Having implemented "plug-ins" or other component software which
interact with an implementation, but doing so only with
reference
to the published service provider interfaces.
d) Have written or executed test cases that probed the behavior
of an implementation as long as you did so with reference
only to published specifications and interfaces.
With those activities in mind, have you done any of the following
to an
implementation of one or more of the components you listed in
item (2)
above :
- Read some or all the source code for an implementation?
- Fixed defects or performed other maintenance activity on an
implementation?
- Enhanced the source code for an implementation with additional
function,
performance or other qualities of service?
- Ported an implementation to a different operating system or
hardware platform?
- Reverse compiled or otherwise reverse engineered an
implementation?
If you have answered yes to any question above, you may not be
an contributor to
the related component of Apache Harmony unless the copyright
owner of that
implementation either:
a) submits the implementation to this project under the
Software Grant or
the Corporate Contribution License Agreement (the CCLA);
b) if the copyright owner is your current employer, signs a
CCLA and
lists you as a designated employee; or
c) if the copyright owner is not your current employer, submits
a written authorization disclaiming any copyright or
confidentiality
interest in your current or future contributions to this
project.
4) Bulk Contribution
Have you personally written all of the code or other material
that you are intending to contribute to this project?
If not, you need to satisfy both a) and b) below.
a) All of the other authors are committers for the component and
b) You have a written agreement with those who wrote the material
that either gives you ownership of the material or otherwise
provides you sufficient rights to submit this material to the
project on their behalf. (please provide the details of this
agreement)
5) Confidential Exposure
Have you had access to any information regarding a proprietary
implementation of a component that could be considered
confidential? If so, you may be a committer for that component only
if the owner of that potential confidential information submits
a written authorization disclaiming any confidentiality interest
in your current or future contributions to this project.
6) Non-Compete Restrictions
Are you subject to a non-compete agreement that covers the
development of software? If so, you may be an committer only if
the other party submits a written authorization acknowledging that
your participation in the project is not in conflict with the
non-compete agreement.
7) ICLA
Please execute a Individual Contributor License Agreement.
8) Employment Limitations
Are you employed as a programmer, systems analyst, or other
IT professional? If so, you may be an commiter
only if your employer either:
a) signs a Corporate Contribution License Agreement with Apache
and lists you as a designated employee or
b) submits a written authorization for your participation in this
project and disclaims any copyright or confidentiality interest
in your current or future contributions to this project.
-------------------
Comments?
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [Legal] Requirements for Committers
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Steven Gong wrote:
>Tor, is it legal to for you to contribute the API of this JNI programming
>framework? IMHO the API is as valuable as the implementation.
>
>
To me personally, I don't see any problem, whether donating the API, nor
the contribution, but that won't work if you stick with the original
requirements suggested by Geir. I can't expect my employer to waste time
setting up a legal document to allow this, as long as the document would
be meaningless in the juristiction I am employed.
Tor
Re: [Legal] Requirements for Committers
Posted by Steven Gong <st...@gmail.com>.
On 6/8/05, Tor-Einar Jarnbjo <To...@jarnbjo.de> wrote:
>
> Geir Magnusson Jr. wrote:
>
> > What are you working on?
>
> It's a framework to ease JNI programming, or more precisely to make it
> possible to call native, e.g. OS functions without writing wrapper code
> in C to do type conversions etc.
Tor, is it legal to for you to contribute the API of this JNI programming
framework? IMHO the API is as valuable as the implementation.
--
Best Regards
Steven Gong
Re: [Legal] Requirements for Committers
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Geir Magnusson Jr. wrote:
> What are you working on?
It's a framework to ease JNI programming, or more precisely to make it
possible to call native, e.g. OS functions without writing wrapper code
in C to do type conversions etc.
For example, invoking the Windows MessageBox function in user32.dll can
be done like this:
EasyJni jni = EasyJni.getInstance();
NativeLibrary user32 = jni.loadNativeLibrary("user32");
long ctext = jni.createCString("Message box text", "UTF-16LE");
long ctitle = jni.createCString("Message box title", "UTF-16LE");
int res = (int)user32.invokeLong(
"MessageBoxW", 0, ctext, ctitle, MessageBoxConstants.MB_OKCANCEL);
jni..free(ctext);
jni.free(ctitle);
C structs can be mapped to Java classes using annotations, as here with
the WAVEFORMAT struct used by the Windows audio API:
@NativeStruct(endian=Endian.little, size=16)
public class WaveFormat implements Modifiable {
@NativeField(type=FieldType.int16, offset=0)
private int formatTag;
@NativeField(type=FieldType.int16, offset=2)
private int channels;
@NativeField(type=FieldType.int32, offset=4)
private int samplesPerSecond;
@NativeField(type=FieldType.int32, offset=8)
private int avgBytesPerSecond;
@NativeField(type=FieldType.int32, offset=12)
private int blockAlign;
// getter and setter methods ...
}
I needed this for some audio functionality, which is not available
through JavaSound. The JNI library could probably be used in several
fields, and seeing that Classpath does not implement any parts of
JavaSound, my Windows media API wrappers are probably a good starting
point for a new JavaSound implementation (at least targetted for Windows).
Tor
Re: [Legal] Requirements for Committers
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 7, 2005, at 7:00 PM, Tor-Einar Jarnbjo wrote:
> Geir Magnusson Jr. wrote:
>
>
>> 8) Employment Limitations
>>
>> Are you employed as a programmer, systems analyst, or other
>> IT professional? If so, you may be an commiter
>> only if your employer either:
>>
>> a) signs a Corporate Contribution License Agreement with Apache
>> and lists you as a designated employee or
>>
>> b) submits a written authorization for your participation in this
>> project and disclaims any copyright or confidentiality interest
>> in your current or future contributions to this project.
>>
>
> IANAL, but this is a really tricky part, as different laws apply
> depending on where the contributor lives. Most countries have a
> different approach on this subject than the anglo-american
> copyright, namely the "author's right".
I know :)
We have to iterate on this (via competent legal advice) to do what's
appropriate for contributions to us, a U.S. corporation.
>
> For my part, living in Germany, there is no way for my employer
> (even though I'm employed as a software developer) to claim any
> rights on work I'm doing in my spare time and there is no legal way
> for me to disclaim or overdraw my author's right on any work I've
> done. Even the author's right on the work I'm doing for my employer
> stays with me, all they can claim is an exclusive right to _use_
> the code.
Ok - so that's the kind of thing we'll have to tweak.
>
> I have been working on a few smaller projects lately, which may be
> of interest to the Harmony project, and I would find it a pity, if
> your legal requirements makes it difficult for me to contribute.
It would be a pity, and we'll work to fix. Note that these aren't
arbitrary requirements - we want to make it so that we're protected
in case some other "small project" of interest to the Harmony project
doesn't put us in a position where the whole thing has to be shut
down :)
What are you working on?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: [Legal] Requirements for Committers
Posted by Renaud BECHADE <re...@numerix.com>.
Right,
I forgot to mention what happens in the case of a working contract... Sorry.
(But we are not linked with a working contract and the derogative article of
the intellectual property right you cite contains the very word "employees"
/ art. L113-9)
After checking a few sources it seems though that there are many pitfalls
when doing the "rights" transfer after the soft is written... I'll try to
check more sources.
Regards,
RB
Ex: (in French below, sorry)
Basically a guy sold a soft to a company before he was employed. This was
restated by the judge as a use right lease for a given, limited duration.
http://www.pifrance.com/rechercher.php
-----
TGI Paris, 26 novembre 2002, M. Demont c/ SARL Forever Living Products
2004-12-09
Thème : TIC
Dossier : Salarié
La personne physique qui cède "en pleine propriété" deux logiciels conçus
avant son embauche obtient la requalification de la cession en droit d'usage
à durée déterminée. Le TGI rappelle le caractère nécessairement explicite de
la cession de droits...
Mots clés : logiciel ; progiciel ; droits d'auteur ; contrat de travail ;
transaction ; droit d'usage ; exploitation ; cession des droits (non) ;
atteinte au droit moral (non) ; articles L.113-9 et L.131-3 du CPI ;
requalification ; cession ; gestion d'entreprise.
-----Original Message-----
From: Emmanuel Lecharny [mailto:elecharny@apache.org]
Sent: Wednesday, June 08, 2005 3:41 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [Legal] Requirements for Committers
On Wed, 2005-06-08 at 10:34 +0900, Renaud BECHADE wrote:
> It is quite similar in French law (soft copyright law being a derivative
of
> usual author copyright law: "author's right belongs to the author, period;
> usage right can be granted/sold/etc. but NOT the author's property").
Hi, be aware that in France, when your are working for companies, they
are the Author of what you are working on during your working hours. So,
either do it during your spare time, or have a signed agreement with
your company which specifically name you as the Author...
Cheers,
Emmanuel Lécharny
RE: [Legal] Requirements for Committers
Posted by Emmanuel Lecharny <el...@apache.org>.
On Wed, 2005-06-08 at 10:34 +0900, Renaud BECHADE wrote:
> It is quite similar in French law (soft copyright law being a derivative of
> usual author copyright law: "author's right belongs to the author, period;
> usage right can be granted/sold/etc. but NOT the author's property").
Hi, be aware that in France, when your are working for companies, they
are the Author of what you are working on during your working hours. So,
either do it during your spare time, or have a signed agreement with
your company which specifically name you as the Author...
Cheers,
Emmanuel Lécharny
Re: [Legal] Requirements for Committers
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 7, 2005, at 9:34 PM, Renaud BECHADE wrote:
>
> It is quite similar in French law (soft copyright law being a
> derivative of
> usual author copyright law: "author's right belongs to the author,
> period;
> usage right can be granted/sold/etc. but NOT the author's
> property"). Not
> sure about Japanese law (I am living in Japan and France :-)).
>
> I guess we should not try to have legal stances that are just too
> obscure or
> absolute (and hence just not compatible with some countries laws).
>
> Sorry this is more like a problem than a solution, but it would be
> a pity to
> be deep in the XXXX because we ignore laws diversity.
Which aspect? We're not ignoring diversity here. We're trying to
get started figuring out what to do. We'll have to consult the ASF
legal team, but the issues of the CCLA is universal at the ASF anyway.
The issues won't go away if we just try and ignore them.
geir
>
> -----Original Message-----
> From: Tor-Einar Jarnbjo [mailto:Tor-Einar@Jarnbjo.de]
> Sent: Wednesday, June 08, 2005 8:01 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [Legal] Requirements for Committers
>
> Geir Magnusson Jr. wrote:
>
>
>> 8) Employment Limitations
>>
>> Are you employed as a programmer, systems analyst, or other
>> IT professional? If so, you may be an commiter
>> only if your employer either:
>>
>> a) signs a Corporate Contribution License Agreement with Apache
>> and lists you as a designated employee or
>>
>> b) submits a written authorization for your participation in this
>> project and disclaims any copyright or confidentiality interest
>> in your current or future contributions to this project.
>>
>
> IANAL, but this is a really tricky part, as different laws apply
> depending on where the contributor lives. Most countries have a
> different approach on this subject than the anglo-american copyright,
> namely the "author's right".
>
> For my part, living in Germany, there is no way for my employer (even
> though I'm employed as a software developer) to claim any rights on
> work
> I'm doing in my spare time and there is no legal way for me to
> disclaim
> or overdraw my author's right on any work I've done. Even the author's
> right on the work I'm doing for my employer stays with me, all they
> can
> claim is an exclusive right to _use_ the code.
>
> I have been working on a few smaller projects lately, which may be of
> interest to the Harmony project, and I would find it a pity, if your
> legal requirements makes it difficult for me to contribute.
>
> Tor
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: [Legal] Requirements for Committers
Posted by Renaud BECHADE <re...@numerix.com>.
It is quite similar in French law (soft copyright law being a derivative of
usual author copyright law: "author's right belongs to the author, period;
usage right can be granted/sold/etc. but NOT the author's property"). Not
sure about Japanese law (I am living in Japan and France :-)).
I guess we should not try to have legal stances that are just too obscure or
absolute (and hence just not compatible with some countries laws).
Sorry this is more like a problem than a solution, but it would be a pity to
be deep in the XXXX because we ignore laws diversity.
-----Original Message-----
From: Tor-Einar Jarnbjo [mailto:Tor-Einar@Jarnbjo.de]
Sent: Wednesday, June 08, 2005 8:01 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [Legal] Requirements for Committers
Geir Magnusson Jr. wrote:
> 8) Employment Limitations
>
> Are you employed as a programmer, systems analyst, or other
> IT professional? If so, you may be an commiter
> only if your employer either:
>
> a) signs a Corporate Contribution License Agreement with Apache
> and lists you as a designated employee or
>
> b) submits a written authorization for your participation in this
> project and disclaims any copyright or confidentiality interest
> in your current or future contributions to this project.
IANAL, but this is a really tricky part, as different laws apply
depending on where the contributor lives. Most countries have a
different approach on this subject than the anglo-american copyright,
namely the "author's right".
For my part, living in Germany, there is no way for my employer (even
though I'm employed as a software developer) to claim any rights on work
I'm doing in my spare time and there is no legal way for me to disclaim
or overdraw my author's right on any work I've done. Even the author's
right on the work I'm doing for my employer stays with me, all they can
claim is an exclusive right to _use_ the code.
I have been working on a few smaller projects lately, which may be of
interest to the Harmony project, and I would find it a pity, if your
legal requirements makes it difficult for me to contribute.
Tor
Re: [Legal] Requirements for Committers
Posted by Wi...@sybase.com.
Good
Best Regards,
William Wu
Software Engineer
Sybase Shanghai R&D Center
Room 1202-1206, Building One,
Zhangjiang Semiconductor Industry Park
3000 Longdong Avenue
Pudong, Shanghai 201203
Tel: 8621-68799918 ext 3081
Fax: 8621-68790199
Email: William.wu@sybase.com
Re: [Legal] Requirements for Committers
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Geir Magnusson Jr. wrote:
> 8) Employment Limitations
>
> Are you employed as a programmer, systems analyst, or other
> IT professional? If so, you may be an commiter
> only if your employer either:
>
> a) signs a Corporate Contribution License Agreement with Apache
> and lists you as a designated employee or
>
> b) submits a written authorization for your participation in this
> project and disclaims any copyright or confidentiality interest
> in your current or future contributions to this project.
IANAL, but this is a really tricky part, as different laws apply
depending on where the contributor lives. Most countries have a
different approach on this subject than the anglo-american copyright,
namely the "author's right".
For my part, living in Germany, there is no way for my employer (even
though I'm employed as a software developer) to claim any rights on work
I'm doing in my spare time and there is no legal way for me to disclaim
or overdraw my author's right on any work I've done. Even the author's
right on the work I'm doing for my employer stays with me, all they can
claim is an exclusive right to _use_ the code.
I have been working on a few smaller projects lately, which may be of
interest to the Harmony project, and I would find it a pity, if your
legal requirements makes it difficult for me to contribute.
Tor
Re: [Legal] Requirements for Committers
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 23, 2005, at 3:36 AM, usman bashir wrote:
> Hi!
> gier! i m from Pakistan and here and in even our some neigbouring
> counteries like INDIA etc , the employer has the right over only those
> things that we write for them. but not for those whom we write for
> us , so
> even it is possible to do parrallel work for others.
> but as u suggested a letter from our contractor, i can provide but
> it ll
> certainly raise some eyebrowse here even though it is not going to
> help
> harmory me or my company:)
> as for as other restrcition are concern i am free from them as i
> have never
> feel concern what the Sun writes for us. so even though having more
> then
> onse src.zip (as due to several JDKs on my machine) , i never dig
> into their
> codes.
> so i request u either reiterate over ur statment about company
> statement
> and if u r still looking over it then i have to mess up with my PM.
>
We'll have a new version of this out here on the list soon that
addresses this. I think that you won't have to go hassle your
manager or employer if there is clearly no right over the work you
would be doing for Harmony.
geir
> On 6/14/05, Ben Laurie <be...@algroup.co.uk> wrote:
>
>>
>> Geir Magnusson Jr. wrote:
>>
>>>
>>> On Jun 9, 2005, at 3:48 AM, Robin Garner wrote:
>>>
>>>
>>>>> 8) Employment Limitations
>>>>>
>>>>> Are you employed as a programmer, systems analyst, or other
>>>>> IT professional? If so, you may be an commiter
>>>>> only if your employer either:
>>>>>
>>>>> a) signs a Corporate Contribution License Agreement with Apache
>>>>> and lists you as a designated employee or
>>>>>
>>>>> b) submits a written authorization for your participation in this
>>>>> project and disclaims any copyright or confidentiality interest
>>>>> in your current or future contributions to this project.
>>>>>
>>>>>
>>>>
>>>> To me, this is _way_ too restructive.
>>>>
>>>
>>>
>>> It is very restrictive, and is a starting point for the discussion.
>>>
>>> This is a real problem, I think. I believe that people don't
>>> understand the restrictions they are working under, and the
>>> ramifications of what can happen.
>>>
>>>
>>>
>>>> While this kind of statement
>>>> wouldn't be a problem for me currently, from time to time I've been
>>>> employeed by either a large company or the Australian Government,
>>>> neither
>>>> of which have any legal rights to anything I do out of hours,
>>>> but who
>>>> would have conniptions if asked to sign an agreement like this.
>>>> Simply
>>>> because the pointy haired bosses wouldn't understand what it was
>>>> about,
>>>> and would go into knee-jerk abnegation-of-responsibility mode.
>>>>
>>>
>>>
>>> LOL. "KJAORM"
>>>
>>> Well, what do we do? I'm not sure we can punt here, but clearly we
>>> want to make it so the broadest community can participate.
>>>
>>
>> Clearly your requirements only apply if the contributor's employer
>> has
>> rights to their contribution. If the employer has no rights, then all
>> the contributor need do is to state that.
>>
>> Cheers,
>>
>> Ben.
>>
>> --
>>
>>>>> ApacheCon Europe<<< http://www.apachecon.com/
>>>>>
>>
>> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>>
>> "There is no limit to what a man can do or how far he can go if he
>> doesn't mind who gets the credit." - Robert Woodruff
>>
>>
>
>
>
> --
> Usman Bashir
> Certified IBM XML Solution Developer
> Certified UML Developer
> Brainbench Certified Internet Perfessional[advance](BCIP)
> Brainbench Certified Java Perfessional (BCJP)
> Brainbench Certified .NET Perfessional
> Brainbench Ceritified C++ Perfessional (BCCP)
> Software engineer IT24
> Faculty Member Operation Badar Lahore
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [Legal] Requirements for Committers
Posted by usman bashir <gr...@gmail.com>.
Hi!
gier! i m from Pakistan and here and in even our some neigbouring
counteries like INDIA etc , the employer has the right over only those
things that we write for them. but not for those whom we write for us , so
even it is possible to do parrallel work for others.
but as u suggested a letter from our contractor, i can provide but it ll
certainly raise some eyebrowse here even though it is not going to help
harmory me or my company:)
as for as other restrcition are concern i am free from them as i have never
feel concern what the Sun writes for us. so even though having more then
onse src.zip (as due to several JDKs on my machine) , i never dig into their
codes.
so i request u either reiterate over ur statment about company statement
and if u r still looking over it then i have to mess up with my PM.
On 6/14/05, Ben Laurie <be...@algroup.co.uk> wrote:
>
> Geir Magnusson Jr. wrote:
> >
> > On Jun 9, 2005, at 3:48 AM, Robin Garner wrote:
> >
> >>> 8) Employment Limitations
> >>>
> >>> Are you employed as a programmer, systems analyst, or other
> >>> IT professional? If so, you may be an commiter
> >>> only if your employer either:
> >>>
> >>> a) signs a Corporate Contribution License Agreement with Apache
> >>> and lists you as a designated employee or
> >>>
> >>> b) submits a written authorization for your participation in this
> >>> project and disclaims any copyright or confidentiality interest
> >>> in your current or future contributions to this project.
> >>>
> >>
> >> To me, this is _way_ too restructive.
> >
> >
> > It is very restrictive, and is a starting point for the discussion.
> >
> > This is a real problem, I think. I believe that people don't
> > understand the restrictions they are working under, and the
> > ramifications of what can happen.
> >
> >
> >> While this kind of statement
> >> wouldn't be a problem for me currently, from time to time I've been
> >> employeed by either a large company or the Australian Government,
> >> neither
> >> of which have any legal rights to anything I do out of hours, but who
> >> would have conniptions if asked to sign an agreement like this. Simply
> >> because the pointy haired bosses wouldn't understand what it was about,
> >> and would go into knee-jerk abnegation-of-responsibility mode.
> >
> >
> > LOL. "KJAORM"
> >
> > Well, what do we do? I'm not sure we can punt here, but clearly we
> > want to make it so the broadest community can participate.
>
> Clearly your requirements only apply if the contributor's employer has
> rights to their contribution. If the employer has no rights, then all
> the contributor need do is to state that.
>
> Cheers,
>
> Ben.
>
> --
> >>>ApacheCon Europe<<< http://www.apachecon.com/
>
> http://www.apache-ssl.org/ben.html http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
--
Usman Bashir
Certified IBM XML Solution Developer
Certified UML Developer
Brainbench Certified Internet Perfessional[advance](BCIP)
Brainbench Certified Java Perfessional (BCJP)
Brainbench Certified .NET Perfessional
Brainbench Ceritified C++ Perfessional (BCCP)
Software engineer IT24
Faculty Member Operation Badar Lahore
Re: [Legal] Requirements for Committers
Posted by Ben Laurie <be...@algroup.co.uk>.
Geir Magnusson Jr. wrote:
>
> On Jun 9, 2005, at 3:48 AM, Robin Garner wrote:
>
>>> 8) Employment Limitations
>>>
>>> Are you employed as a programmer, systems analyst, or other
>>> IT professional? If so, you may be an commiter
>>> only if your employer either:
>>>
>>> a) signs a Corporate Contribution License Agreement with Apache
>>> and lists you as a designated employee or
>>>
>>> b) submits a written authorization for your participation in this
>>> project and disclaims any copyright or confidentiality interest
>>> in your current or future contributions to this project.
>>>
>>
>> To me, this is _way_ too restructive.
>
>
> It is very restrictive, and is a starting point for the discussion.
>
> This is a real problem, I think. I believe that people don't
> understand the restrictions they are working under, and the
> ramifications of what can happen.
>
>
>> While this kind of statement
>> wouldn't be a problem for me currently, from time to time I've been
>> employeed by either a large company or the Australian Government,
>> neither
>> of which have any legal rights to anything I do out of hours, but who
>> would have conniptions if asked to sign an agreement like this. Simply
>> because the pointy haired bosses wouldn't understand what it was about,
>> and would go into knee-jerk abnegation-of-responsibility mode.
>
>
> LOL. "KJAORM"
>
> Well, what do we do? I'm not sure we can punt here, but clearly we
> want to make it so the broadest community can participate.
Clearly your requirements only apply if the contributor's employer has
rights to their contribution. If the employer has no rights, then all
the contributor need do is to state that.
Cheers,
Ben.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: [Legal] Requirements for Committers
Posted by Onno Kluyt <On...@Sun.COM>.
What I meant was there is little one can do against someone signing a
license in bad faith. You can do, and should do, certain due diligence
beforehand but there is a point where you just have to assume someone
will live up to the promise he or she is making by agreeing to a
license.
On Jun 9, 2005, at 3:51 PM, Onno Kluyt wrote:
> That is what courts are for .....
>
> (at least the bad faith part)
>
> On Jun 9, 2005, at 6:23 AM, Geir Magnusson Jr. wrote:
>
>> Worse is someone signing in bad faith or in ignorance.
>
Re: [Legal] Requirements for Committers
Posted by Onno Kluyt <On...@Sun.COM>.
That is what courts are for .....
(at least the bad faith part)
On Jun 9, 2005, at 6:23 AM, Geir Magnusson Jr. wrote:
> Worse is someone signing in bad faith or in ignorance.
Re: [Legal] Requirements for Committers
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 9, 2005, at 3:48 AM, Robin Garner wrote:
>> 8) Employment Limitations
>>
>> Are you employed as a programmer, systems analyst, or other
>> IT professional? If so, you may be an commiter
>> only if your employer either:
>>
>> a) signs a Corporate Contribution License Agreement with Apache
>> and lists you as a designated employee or
>>
>> b) submits a written authorization for your participation in this
>> project and disclaims any copyright or confidentiality
>> interest
>> in your current or future contributions to this project.
>>
>
> To me, this is _way_ too restructive.
It is very restrictive, and is a starting point for the discussion.
This is a real problem, I think. I believe that people don't
understand the restrictions they are working under, and the
ramifications of what can happen.
> While this kind of statement
> wouldn't be a problem for me currently, from time to time I've been
> employeed by either a large company or the Australian Government,
> neither
> of which have any legal rights to anything I do out of hours, but who
> would have conniptions if asked to sign an agreement like this.
> Simply
> because the pointy haired bosses wouldn't understand what it was
> about,
> and would go into knee-jerk abnegation-of-responsibility mode.
LOL. "KJAORM"
Well, what do we do? I'm not sure we can punt here, but clearly we
want to make it so the broadest community can participate.
>
> What is wrong with a personal statement confirming that no third
> party has
> a claim on the IP of the contribution. Seems to work for the CPL, but
> then IANAL ...
The CPL is just a license, not an organization that would be creating
and distributing software under that license.
The scenario that I fear is someone confirming that no third party
has a claim, in perfectly good faith. Then, after some time goes by,
they get involved with a big company as an employee, contractor or
such, and as part of the paperwork, sign a document that changes that
situation. They may not remember their claim, and thus any work
after that puts the project at some level of risk we didn't have before.
Worse is someone signing in bad faith or in ignorance.
We're open to any and all suggestions.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: [Legal] Requirements for Committers
Posted by Renaud BECHADE <re...@numerix.com>.
>> Are you employed as a programmer, systems analyst, or other
>> IT professional? If so, you may be an commiter
>> only if your employer either:
>>
>> a) signs a Corporate Contribution License Agreement with Apache
>> and lists you as a designated employee or
>>
>> b) submits a written authorization for your participation in this
>> project and disclaims any copyright or confidentiality interest
>> in your current or future contributions to this project.
>
>>To me, this is _way_ too restructive.
... Same in France. Besides, by default, the employer cannot take property
on what is done out of the scope of work [A]; and even in the case when an
employee writes some code out of the scope of his job and at work, some
French justice cases [1] say the work is the employee's. (although it seems
this is up to the judge to decide it...)
All the same, the author's 'droit moral' (moral right [?]) and its most
restrictive interpretation, 'droit de paternite' (paternity right [?]) is
'perpetuel, inalienable et imprescriptible' (perpetual, not cessible,
unprescriptible; art L212-1, French Intellectual Property Code).
I think we really need to rephrase correctly the legal aspect of the
committer's conditions because such very blatantly impossible to defend kind
of stances are amongst the best ways to have a judge angry...
Also, "contrats de cession" (sort of "copyright agreements") must be very
precisely phrased but limited in scope [2] lest French courts decide to
break them [3].
All the same with subsequent lease or copyleft, of course [4].
Sorry these are more problems than solutions.
(please note I am not a lawyer, so you should trust it and die - if you are
interested I can try to find good references in France. As I live in Japan I
leave to our Japanese colleagues the honor to expose the situation in Japan,
which I would be very interested to hear about)
Regards,
RB
[A] When writing code as an employee, French law says the author is not you
but your employer, only and only if it is done under the employer's
directions (this last point being of course spicy to prove or falsify :-) ).
Technically the "property" (droit moral, droit de paternite) is
unprescriptible.
[1] arret Pachot, 7 fev. 1986
[2] L131-3
"La validite d'une trasmission est subordonnee
a la distinction des droits transferes et a la
delimitation de leur domaine d'exploitation
dans l'acte"
[3] TGI Paris, 26 novembre 2002, M. Demont c/ SARL Forever Living Products
2004-12-09
Dossier : Salarié
La personne physique qui cède "en pleine propriété" deux logiciels conçus
avant son embauche obtient la requalification de la cession en droit d'usage
à durée déterminée. Le TGI rappelle le caractère nécessairement explicite de
la cession de droits...
[4] TGI Paris 4 oct 1983
"une sous-license de droit d'auteur sur le logiciel
consentie en l'absence d'autorisation du titulaire
du droit constitue une contrefacon".
Other sources:
[Droit de la propriete intellectuelle,
2eme ed. Jonanna Schmidt-Szalewski,
Jean-Luc Pierre Ed. Litec]
[Propriete Litteraire
et artistique Pierre-Yves Gautier
4eme ed. PUF Droit]
-----Original Message-----
From: Robin Garner [mailto:robin.garner@anu.edu.au]
Sent: Thursday, June 09, 2005 4:49 PM
To: harmony-dev@incubator.apache.org
Cc: harmony-dev@incubator.apache.org
Subject: Re: [Legal] Requirements for Committers
> 8) Employment Limitations
>
> Are you employed as a programmer, systems analyst, or other
> IT professional? If so, you may be an commiter
> only if your employer either:
>
> a) signs a Corporate Contribution License Agreement with Apache
> and lists you as a designated employee or
>
> b) submits a written authorization for your participation in this
> project and disclaims any copyright or confidentiality interest
> in your current or future contributions to this project.
To me, this is _way_ too restructive. While this kind of statement
wouldn't be a problem for me currently, from time to time I've been
employeed by either a large company or the Australian Government, neither
of which have any legal rights to anything I do out of hours, but who
would have conniptions if asked to sign an agreement like this. Simply
because the pointy haired bosses wouldn't understand what it was about,
and would go into knee-jerk abnegation-of-responsibility mode.
What is wrong with a personal statement confirming that no third party has
a claim on the IP of the contribution. Seems to work for the CPL, but
then IANAL ...
robin
Re: [Legal] Requirements for Committers
Posted by Robin Garner <ro...@anu.edu.au>.
> 8) Employment Limitations
>
> Are you employed as a programmer, systems analyst, or other
> IT professional? If so, you may be an commiter
> only if your employer either:
>
> a) signs a Corporate Contribution License Agreement with Apache
> and lists you as a designated employee or
>
> b) submits a written authorization for your participation in this
> project and disclaims any copyright or confidentiality interest
> in your current or future contributions to this project.
To me, this is _way_ too restructive. While this kind of statement
wouldn't be a problem for me currently, from time to time I've been
employeed by either a large company or the Australian Government, neither
of which have any legal rights to anything I do out of hours, but who
would have conniptions if asked to sign an agreement like this. Simply
because the pointy haired bosses wouldn't understand what it was about,
and would go into knee-jerk abnegation-of-responsibility mode.
What is wrong with a personal statement confirming that no third party has
a claim on the IP of the contribution. Seems to work for the CPL, but
then IANAL ...
robin
Re: [Legal] Requirements for Committers
Posted by Peter Donald <pe...@realityforge.org>.
Geir Magnusson Jr. wrote:
> Comments?
Seems reasonable.
Re: [Legal] Requirements for Committers
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 8, 2005, at 8:54 AM, Nacho G. Mac Dowell wrote:
> Hi all,
>
> Geir Magnusson Jr. wrote:
>
>
>> a) Having a copy of src.jar on a computer as long as you never
>> viewed or edited the contents of the file.
>>
>>
> How many people on this list have NEVER looked (not edited) at,
> say, java.lang.String?
I've seen it via the debugger, but no - I've never opened src.jar and
edited String.java
Thats said, this is an important issue. We do need to figure out
what the ramifications of exposure to src.jar code are. (The
statement you are commenting on was just the first of what I suspect
will be an iteration or two...)
We want to start with the most conservative definition of "taint" and
work our way out of it. I believe that we can work with Sun (or any
other copyright holder) to clarify the position on this matter.
>
> If you want people with extensive java knowledge to contribute to
> Harmony this requirement seems like a dead-end to me. Not for the
> VM internals, but for the class libraries. I suppose that, at
> least, any curious java developer using eclipse (I don't know about
> other IDE's) has. Something else would be pretending no one ever
> looked at src.jar... Don't flame me, please. I'm just trying to
> address one of my major concerns about Harmony. If this is a MUST
> requirement, then Sun did a great job when releasing src.jar...
No one will flame you - this is a valid point.
I'm pretty sure that wasn't Sun's intention, and I also believe that
Sun has no desire to assert that casual exposure to the contents of
src.jar by developers creating, debugging or running Java
applications "taints" those developers. However, we do need to find
a clear way for them to express this, if they are interested or we
must remain conservative on this issue. (I don't speak for Sun, of
course...)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [Legal] Requirements for Committers
Posted by Sven de Marothy <sv...@physto.se>.
On Wed, 2005-06-08 at 14:54 +0200, Nacho G. Mac Dowell wrote:
> How many people on this list have NEVER looked (not edited) at, say,
> java.lang.String?
Me. And all other GNU Classpath contributors on this list. At least 3 of
the 9 listed in the proposal as possible commiters.
> If you want people with extensive java knowledge to contribute to
> Harmony this requirement seems like a dead-end to me.
I view myself as having extensive java knowledge.
> Not for the VM internals, but for the class libraries.
I already addressed this. It's a fallacy to believe you need to look at
Sun's code to do a good implementation of the class libraries. In fact,
I belive it will lead to a better implementation.
/Sven
Re: [Legal] Requirements for Committers
Posted by Ulrich Kunitz <ku...@deine-taler.de>.
On Wed, 8 Jun 2005, Dalibor Topic wrote:
> > Geir Magnusson Jr. wrote:
> >
> > > a) Having a copy of src.jar on a computer as long as you never
> > > viewed or edited the contents of the file.
At least in the Linux versions 1.5.0_03 and 1.4.2_05 of the J2SE
SDK there is no file src.jar. However there seems to be a file
src.zip. Maybe it is a good sign, that most folks here don't
actually know, how the file is named.
Uli
Re: [Legal] Requirements for Committers
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 8, 2005, at 4:37 PM, Steve Blackburn wrote:
> Dalibor Topic wrote:
>
>
>> Many people don't see the need to look at non-free software in
>> general, and chances are pretty slim that anyone I know will ever
>> get that bored and out of reading material to accept the 'Read
>> only' license, for an example of a very funny non-free software
>> license.
>>
>
> I have never looked at non-free implementations, but I am
> interested to know what this means for those of us who have
> extensive exposure to implementations such as Kaffe (GPL) or Jikes
> RVM (CPL). My reading of it is that I can't work on any part of
> Harmony for which I am tainted by my Jikes RVM exposure without
> permission from the copyright holder of Jikes RVM. Is that right?
I suppose that we can start thinking about some kind of exception
that carves out exposure to any open source VM or class library (or
something like that...)
There still are problems in terms of patent, but we have that anyway.
Here's one of the risks of current practice in patent grant, I
think.. Suppose I have a patent, contribute code that infringes on
that patent under the Apache License to some project Foo, and thus
also grant Foo a patent license covering that infringement of my
patent. So as far as Foo and users of Foo go, all is fine.
Now you come and take that code from Foo, which is perfectly fine
because it's an OSS project under the Apache License, and drop it
into Harmony. Putting aside the proposed rules for "bulk"
contributions of repurposed code, Harmony now has a problem - we are
a derivative work of Foo (not a problem in itself) and thus have no
patent rights.
Hm.
I guess the solution there is that we can't take code from Foo
without all authors being Authorized Committers, so you'd have to get
me to agree to the contribution, under the Apache License to Harmony,
and thus get the same patent rights?
Paging lawyers... paging lawyers.... I know you're reading this... :)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for
Committers)
Posted by Dalibor Topic <ro...@kaffe.org>.
Dalibor Topic wrote:
[hot stuff]
Holy cow, with a bit of hindsight, that was one little emotional
firebrand speech without harmonic undertones. I am afraid I pressed the
send button way too soon, so sorry about that, and I hope to avoid
turning the list into a legal speculative fest. After some experience on
debian-legal, I should know better than to send firebrand speeches to
mailing lists. ;(
Instead of sheepishly feeding the speculations further myself, I'll take
it up with some friendly folks at the parents of the JRL, and try to
figure out what the JRL is really meant to mean, and see if all of my
fears regarding the JRL covering other things really are as unfounded as
everyone would/should hope. If they are unfounded, well, awesome,
everyone wins. If they are not unfounded, well, the JRL could be fixed
to make them unfounded, and everyone wins. Let's be winners.
love, peace and understanding,
dalibor topic
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for
Committers)
Posted by Dalibor Topic <ro...@kaffe.org>.
Bruno F. Souza wrote:
> Dalibor Topic wrote:
>
>>
>> You can look at free software and work on other software as much as
>> you want to, as free software licenses do not claim further rights
>> beyound the rights granted to the author through copyright laws. I.e.
>> if you copy or modify free software works, you are bound by their
>> license terms, as the copyright laws grant the authors a say in
>> derivative works. If you don't do that, then the author has no say in
>> your own, original work. You are allowed to study free software
>> (freedom 1 [1]). You can do what you want with that knowledge, modulo
>> patents and creating derived works.[0]
>>
>
> Well, the "tainting" (if that can be said that way) on open source
> licenses only have any effect if the original license has some
> reciprocity rules (like the GPL/LGPL for example) that prevents you to
> use the code anyway you want. Under copyright, you cannot simply copy
> the code, and as such, Harmony's code should not bear any resemblance to
> other free J2SE implementations to which the license is not Apache
> compatible. As seen in the JBoss vs Geronimo legal discussion, we should
> probably be careful here as well.
Yep, copying the code verbatim, or copying a derived work of the code is
covered by Free Software licenses, and some of them have stricter rules
than the Apache Software License v2, so that code can not be used in
Harmony unless relicensed. Note that one would want to have copyright
disclaimers on all the code going into Harmony, to avoid funny
misunderstandings (cheers to everyone's friends in SCO) later.
Otoh, you are fine to look at Kaffe's source code (GPLd), for example,
decide that it does some things not that well, and go on to implement
your own, better runtime/jit/gc/verifier/whatever (just listen to Miguel
for a while, to hear how many things Mono does better than Kaffe :), and
license it as you wish (Mono is not GPLd), as it is your own original
work, that does not share copyrightable portions with GPLd code.
Copyright protects an expression, patents protect ideas. Ideas expressed
in Free Software can be learned and reused freely, modulo any weird
software patents. The literal, tangible expressions of those ideas,
though, can be copied and modified only according to the liberal, OSI
certified rules set forth by the authors.
> And another can or worms is Sun's research license (JRL), that
> specifically says:
>
> B. Residual Rights. You may use any information in
> intangible form that you remember after accessing the
> Technology, except when such use violates Sun's copyrights
> or patent rights.
>
> That pretty much spells out the same as what Dalibor said:
>
> > You can do what you want with that knowledge, modulo
> > patents [rights] and creating derived works [copyright rights].
Well, there is a major difference: the JRL claims copyright rights for
any code implementing any part of the specifications, no matter whether
that new code actually contains a copyrightable portion of the JRL code
or not. As Harmony would be writing new code, it should avoid getting
under such claims from the JRL. See
http://www.mail-archive.com/classpath@gnu.org/msg09825.html for details.
quoting from it:
"As long as Sun says that anything that implements the specs for J2SE,
without actually being derived from Sun's JRLd code, is nevertheless a
modification of their work, the FAQ is pretty misleading, in my opinion,
though it may be factually correct:
Yes, the JRL-bound developer probably can *create* your own independent
implementation, but she can't distribute it without violating Sun's
claimed rights, unless she distributes it under the JRL or an
equivalent, which is very, very far from being open source. Yes, she
probably can *work* on an open source implementation, but she can't
distribute the results of her work under an open-source license.
That means the Residual Rights section, while well-meant, is not useful
in real life. Most people writing open source software also happen to
like to distribute their own, independant works to other people, under
open source licenses, even. :)"
Copyright does not work the way the JRL-modification-clause works: for
copyright claims to work, a work must somehow derive from another work,
usually by incorporating a modified or verbatim copy of it. What the JRL
gives the copyright holder is a
'copyright-claim-through-wishful-thinking', i.e. a claim on works that
do not contain any copyrightable portion of their original work. The JRL
(and other 'Bride of SCSL' licenses) essentially tries to give the
copyright holder an easy way to slap software patent-like protection of
ideas embodied in an interface on their source code, without actually
going through the cumbersome process of acquiring software patents.
That is extremely different from OSI-certified licenses: those must
constrain themselves to just the works that are derived (in the sense of
copyright law) from them, and can make no claims to unrelated works,
that happen to implement the same interface. Which is why some software
vendors can legally ship their Java(TM) desktop systems on both
GNU/Linux and on non-free operating systems: Free Software does not
claim their independent non-free software as covered by the free
software licenses, just because it happens to do the same thing using
the same ideas.
> So, if we're allowing (with the mentioned care to not infringe copyright
> rights) anyone to work on Harmony that have worked on the open source
> implementations, should we allow those that have read or worked on Sun's
> code under the JRL the same treatment? Or for the sake of extra care, we
> should avoid both or one of the situations? Maybe that would be going
> too far? Geronimo did not avoid contributions from people that worked at
> JBoss, and I understand that besides some trouble along the way, it all
> turned out OK in the end.
The JRL, and other similar Java(TM) technology licenses, unfortunately
try to make it very hard for someone who agrees to them to both work on
*and* release a free software implementation of the specs without
violating the license, afaict, despite well-meant comments from some
executives and marketing staff to the contrary.
If the JRL did not make any claims to new, original code calling it a
modification (see Modifications(b)), then the Residual Rights section
*may* work as advertised, if the termination clause is fixed [1]. On the
other hand, I'd be surprised if there were not too many legal mines
buried in it to make fixing it a dull and pointless excercise. :(
cheers,
dalibor topic
[1] Yeah, termination is broken, as well, as it does not preserve your
Residual Rights, just section V, which covers Trademarks, Export Control
and similarly useless things. Residual Rights, for your JRL-trapped
inconvenience, are under section III, which does not survive
termination, afaict.
Not that it is really easy to terminate the JRL anyway, as it does not
tell you where to send your written notice of termination. And so on,
and so on. Short story: don't touch non-free source code with licenses
from the legal team that gave us such gems like the 'Read-only' license,
without spending some serious time with your lawyers.
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for Committers)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 13, 2005, at 6:43 PM, acoliver@apache.org wrote:
> I've had different answers on legal-discuss to some of these
> questions.
Feel free to share.
> I would encourage folks to avoid these kinds of detailed legal
> discussions here in favor of discussions with generally more
> qualified people on that list.
I'm not sure anything is detailed. We're just calling out the issues
that will need competent legal review.
> I would merely like to state that the issue of "derivative work"
> is NOT straightforward and the issue of the JRL is not even as
> straighforward as it seems unfortunately and encourage further
> discussion take place on legal-discuss.
Yep - but we need to bring that back here for our policy.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for
Committers)
Posted by ac...@apache.org.
I've had different answers on legal-discuss to some of these questions.
I would encourage folks to avoid these kinds of detailed legal
discussions here in favor of discussions with generally more qualified
people on that list. I would merely like to state that the issue of
"derivative work" is NOT straightforward and the issue of the JRL is not
even as straighforward as it seems unfortunately and encourage further
discussion take place on legal-discuss.
Moreover, it is my personal opinion that the JBoss-Geronimo issue was a
very specific set of circumstances that have no real lessons to learn
for this project (though I speak only for myself).
-Andy
Geir Magnusson Jr. wrote:
>
> On Jun 9, 2005, at 8:10 AM, Bruno F. Souza wrote:
>
>> Dalibor Topic wrote:
>>
>>> You can look at free software and work on other software as much as
>>> you want to, as free software licenses do not claim further rights
>>> beyound the rights granted to the author through copyright laws.
>>> I.e. if you copy or modify free software works, you are bound by
>>> their license terms, as the copyright laws grant the authors a say
>>> in derivative works. If you don't do that, then the author has no
>>> say in your own, original work. You are allowed to study free
>>> software (freedom 1 [1]). You can do what you want with that
>>> knowledge, modulo patents and creating derived works.[0]
>>>
>>>
>>
>> Well, the "tainting" (if that can be said that way) on open source
>> licenses only have any effect if the original license has some
>> reciprocity rules (like the GPL/LGPL for example) that prevents you
>> to use the code anyway you want. Under copyright, you cannot simply
>> copy the code, and as such, Harmony's code should not bear any
>> resemblance to other free J2SE implementations to which the license
>> is not Apache compatible. As seen in the JBoss vs Geronimo legal
>> discussion, we should probably be careful here as well.
>>
>
> To be clear, there never was any JBoss code copied for Geronimo. One
> issue from that discussion was similarity of design approach, but I
> think that's ok. If we see that Kaffe has a great trick of caching the
> $foo objects to solve the problem of constantly reloading from disk,
> then I don't see a problem with us using the same strategy as long as
> we don't use the source code from Kaffe.
>
> This is how fields of knowledge grow - people learn from each other.
>
>> And another can or worms is Sun's research license (JRL), that
>> specifically says:
>>
>> B. Residual Rights. You may use any information in
>> intangible form that you remember after accessing the
>> Technology, except when such use violates Sun's copyrights
>> or patent rights.
>>
>> That pretty much spells out the same as what Dalibor said:
>>
>> > You can do what you want with that knowledge, modulo
>> > patents [rights] and creating derived works [copyright rights].
>>
>> So, if we're allowing (with the mentioned care to not infringe
>> copyright rights) anyone to work on Harmony that have worked on the
>> open source implementations, should we allow those that have read or
>> worked on Sun's code under the JRL the same treatment?
>
>
> This non-lawyer says yes, but there may be some clarification needed.
>
>> Or for the sake of extra care, we should avoid both or one of the
>> situations? Maybe that would be going too far? Geronimo did not avoid
>> contributions from people that worked at JBoss, and I understand that
>> besides some trouble along the way, it all turned out OK in the end.
>
>
> Yes. One of the key lessons from Geronimo (which had nothing to do
> with JBoss, actually) was that we should track the "bulk"
> contributions, even from committers. These can be a small as a
> developers favorite little string library or something, and if that
> person has been doing OSS for a while, has probably licensed that under
> other licenses to other projects. That dev is free to relicense if
> they choose, of course. The problem is when someone does a source code
> comparison and gets a match, questions are asked, and it's much easier
> to answer the question when you have a database of contributions you
> can refer to rather than "um, lets go look..."
>
> geir
>
>
>>
>> More food for though...
>>
>> --
>> Bruno.
>> ______________________________________________________________________
>> Bruno Peres Ferreira de Souza Brazil's JavaMan
>> http://www.javaman.com.br bruno at javaman.com.br
>> if I fail, if I succeed, at least I live as I believe
>>
>>
>
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for Committers)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 9, 2005, at 8:10 AM, Bruno F. Souza wrote:
> Dalibor Topic wrote:
>
>> You can look at free software and work on other software as much
>> as you want to, as free software licenses do not claim further
>> rights beyound the rights granted to the author through copyright
>> laws. I.e. if you copy or modify free software works, you are
>> bound by their license terms, as the copyright laws grant the
>> authors a say in derivative works. If you don't do that, then the
>> author has no say in your own, original work. You are allowed to
>> study free software (freedom 1 [1]). You can do what you want with
>> that knowledge, modulo patents and creating derived works.[0]
>>
>>
>
> Well, the "tainting" (if that can be said that way) on open source
> licenses only have any effect if the original license has some
> reciprocity rules (like the GPL/LGPL for example) that prevents you
> to use the code anyway you want. Under copyright, you cannot simply
> copy the code, and as such, Harmony's code should not bear any
> resemblance to other free J2SE implementations to which the license
> is not Apache compatible. As seen in the JBoss vs Geronimo legal
> discussion, we should probably be careful here as well.
>
To be clear, there never was any JBoss code copied for Geronimo. One
issue from that discussion was similarity of design approach, but I
think that's ok. If we see that Kaffe has a great trick of caching
the $foo objects to solve the problem of constantly reloading from
disk, then I don't see a problem with us using the same strategy as
long as we don't use the source code from Kaffe.
This is how fields of knowledge grow - people learn from each other.
> And another can or worms is Sun's research license (JRL), that
> specifically says:
>
> B. Residual Rights. You may use any information in
> intangible form that you remember after accessing the
> Technology, except when such use violates Sun's copyrights
> or patent rights.
>
> That pretty much spells out the same as what Dalibor said:
>
> > You can do what you want with that knowledge, modulo
> > patents [rights] and creating derived works [copyright rights].
>
> So, if we're allowing (with the mentioned care to not infringe
> copyright rights) anyone to work on Harmony that have worked on the
> open source implementations, should we allow those that have read
> or worked on Sun's code under the JRL the same treatment?
This non-lawyer says yes, but there may be some clarification needed.
> Or for the sake of extra care, we should avoid both or one of the
> situations? Maybe that would be going too far? Geronimo did not
> avoid contributions from people that worked at JBoss, and I
> understand that besides some trouble along the way, it all turned
> out OK in the end.
Yes. One of the key lessons from Geronimo (which had nothing to do
with JBoss, actually) was that we should track the "bulk"
contributions, even from committers. These can be a small as a
developers favorite little string library or something, and if that
person has been doing OSS for a while, has probably licensed that
under other licenses to other projects. That dev is free to
relicense if they choose, of course. The problem is when someone
does a source code comparison and gets a match, questions are asked,
and it's much easier to answer the question when you have a database
of contributions you can refer to rather than "um, lets go look..."
geir
>
> More food for though...
>
> --
> Bruno.
> ______________________________________________________________________
> Bruno Peres Ferreira de Souza Brazil's JavaMan
> http://www.javaman.com.br bruno at javaman.com.br
> if I fail, if I succeed, at least I live as I believe
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for
Committers)
Posted by "Bruno F. Souza" <br...@javaman.com.br>.
Dalibor Topic wrote:
>
> You can look at free software and work on other software as much as you
> want to, as free software licenses do not claim further rights beyound
> the rights granted to the author through copyright laws. I.e. if you
> copy or modify free software works, you are bound by their license
> terms, as the copyright laws grant the authors a say in derivative
> works. If you don't do that, then the author has no say in your own,
> original work. You are allowed to study free software (freedom 1 [1]).
> You can do what you want with that knowledge, modulo patents and
> creating derived works.[0]
>
Well, the "tainting" (if that can be said that way) on open source
licenses only have any effect if the original license has some
reciprocity rules (like the GPL/LGPL for example) that prevents you to
use the code anyway you want. Under copyright, you cannot simply copy
the code, and as such, Harmony's code should not bear any resemblance to
other free J2SE implementations to which the license is not Apache
compatible. As seen in the JBoss vs Geronimo legal discussion, we should
probably be careful here as well.
And another can or worms is Sun's research license (JRL), that
specifically says:
B. Residual Rights. You may use any information in
intangible form that you remember after accessing the
Technology, except when such use violates Sun's copyrights
or patent rights.
That pretty much spells out the same as what Dalibor said:
> You can do what you want with that knowledge, modulo
> patents [rights] and creating derived works [copyright rights].
So, if we're allowing (with the mentioned care to not infringe copyright
rights) anyone to work on Harmony that have worked on the open source
implementations, should we allow those that have read or worked on Sun's
code under the JRL the same treatment? Or for the sake of extra care, we
should avoid both or one of the situations? Maybe that would be going
too far? Geronimo did not avoid contributions from people that worked at
JBoss, and I understand that besides some trouble along the way, it all
turned out OK in the end.
More food for though...
--
Bruno.
______________________________________________________________________
Bruno Peres Ferreira de Souza Brazil's JavaMan
http://www.javaman.com.br bruno at javaman.com.br
if I fail, if I succeed, at least I live as I believe
Re: On Tainting/Residual Rights (Was: Re: [Legal] Requirements for
Committers)
Posted by Ben Laurie <be...@algroup.co.uk>.
Dalibor Topic wrote:
> Steve Blackburn wrote:
>
>> Dalibor Topic wrote:
>>
>>> Many people don't see the need to look at non-free software in
>>> general, and chances are pretty slim that anyone I know will ever get
>>> that bored and out of reading material to accept the 'Read only'
>>> license, for an example of a very funny non-free software license.
>>
>>
>>
>> I have never looked at non-free implementations, but I am interested
>> to know what this means for those of us who have extensive exposure to
>> implementations such as Kaffe (GPL) or Jikes RVM (CPL). My reading of
>> it is that I can't work on any part of Harmony for which I am tainted
>> by my Jikes RVM exposure without permission from the copyright holder
>> of Jikes RVM. Is that right?
>
>
> Nope. :)
>
> You can look at free software and work on other software as much as you
> want to, as free software licenses do not claim further rights beyound
> the rights granted to the author through copyright laws. I.e. if you
> copy or modify free software works, you are bound by their license
> terms, as the copyright laws grant the authors a say in derivative
> works. If you don't do that, then the author has no say in your own,
> original work. You are allowed to study free software (freedom 1 [1]).
> You can do what you want with that knowledge, modulo patents and
> creating derived works.[0]
Its not quite as simple as that (I happen to have been taking legal
advice recently on this question) - if I look at your implementation,
then I write my own, and my own is substantially similar to yours, then
I may be infringing your copyright, even if I wrote mine from scratch.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
On Tainting/Residual Rights (Was: Re: [Legal] Requirements for Committers)
Posted by Dalibor Topic <ro...@kaffe.org>.
Steve Blackburn wrote:
> Dalibor Topic wrote:
>
>> Many people don't see the need to look at non-free software in
>> general, and chances are pretty slim that anyone I know will ever get
>> that bored and out of reading material to accept the 'Read only'
>> license, for an example of a very funny non-free software license.
>
>
> I have never looked at non-free implementations, but I am interested to
> know what this means for those of us who have extensive exposure to
> implementations such as Kaffe (GPL) or Jikes RVM (CPL). My reading of
> it is that I can't work on any part of Harmony for which I am tainted by
> my Jikes RVM exposure without permission from the copyright holder of
> Jikes RVM. Is that right?
Nope. :)
You can look at free software and work on other software as much as you
want to, as free software licenses do not claim further rights beyound
the rights granted to the author through copyright laws. I.e. if you
copy or modify free software works, you are bound by their license
terms, as the copyright laws grant the authors a say in derivative
works. If you don't do that, then the author has no say in your own,
original work. You are allowed to study free software (freedom 1 [1]).
You can do what you want with that knowledge, modulo patents and
creating derived works.[0]
Non-free software licenses, though, like the SCSL-derivatives covering
large portions of core Java technology, make claims that go wildly
beyound the rights given to the copyright holders through copyright law.
For example, the SCSL claims all sorts of rights on 'Modifications',
defining Modifications for the purpose of the license way beyound the
scope of the copyright law.
" GLOSSARY, 13. "Modification(s)" means (i) any change to Covered Code;
(ii) any new file or other representation of computer program statements
that contains any portion of Covered Code; and/or (iii) any new Source
Code implementing any portion of the Specifications.
13(i) is your normal copyright law. 13(ii) is your normal copyright law
with an extra spin: it tries to prohibit fair use by claiming that
containing *any portion* of SCSL covered code turns your code into a
modification of SCSL covered code.
Given that you're writing your code in java, chances are that any class
you write shares a certain amount of text with some SCSLd covered code,
simply because they are written in the same programming language. So
13(ii) covers pretty much all java code ever written by anyone who
licensed code under SCSL. To put more graphically, GLOSSARY,13(ii) ==
All your Java are belong to us
Let's get to 13(iii), which is a little more convulted. It says any
*new* Source Code implementing *any portion* of the *Specifications*.
New code is quite obvious, so it coveres all new code you write. Then we
have a clarification, it's any new code you write that implements any
portion of some specs. "implementing any portion of specs" doesn't say
'extending Object is OK', it says "there are some specs, you implement
any single bit out of them, your code is covered". Both the JDK API spec
and the JLS cover java.lang.Object's method signatures. If your code
extends java.lang.Object, it implements "a portion" of the JLS and JDK
API, since you can call the methods covered by the Object API on it. If
that's too far fetched for you, take classes implementing the
Serializable interface, or your classes extending SCSL covered classes,
and overriding methods in them.
But the really convulted part of 13(iii) is in the reference to
"Specifications". If we look up "Specifications" in the glossary, we'll find
GLOSSARY, 21. "Specifications" means the specifications for the
Technology and other documentation, as designated on the Technology
Download Site, as may be revised by Original Contributor from time to time.
This clause gives the copyright owner (or whoever hacks the site) a
backdoor to revise the specifications, and claim violation afterwards,
even if you were compliant originally. The license does not specify the
"Technology download site" precisely (with some URL) anywhere. It does
specify the community source download site, but that one has no JDK
specs. Beautyful."
From my blog on just a few of the hidden gems of tragicomical legalese
buried in the SCSL available on
http://advogato.org/person/robilad/diary.html?start=46.
Free Software licenses don't start from the maximal 'we now fully own
you, period' position. They start from the minimal 'we own our work,
copyright law is cute, this license and copyright law together grant you
broad rights, use them wisely and have fun' position and simply rely on
copyright law, permissions for dervied works and common sense to sort
out the authorship rights rather than claiming everything and all you
come up with by default as covered by them.
You still own your own brain after studying Free software. Free Software
licenses need not to explicitely tell you that, as they make no claims
to your memory, or other body parts. Non-free software licenses, otoh,
that make fancy claims to own you, need to somehow make sure that
thinking in public is still legal after you signed them, so they have to
disclaim ownership to your memory, at least :)
cheers,
dalibor topic
[0] For the record, I don't own any software patents, and regard them as
a mild, cureable form of mass insanity.
[1] The freedom to study how the program works, and adapt it to your
needs (freedom 1).
Re: [Legal] Requirements for Committers
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 9, 2005, at 7:51 AM, Ahmed Saad wrote:
> On 6/8/05, Steve Blackburn <St...@anu.edu.au> wrote:
>
>
>> I have never looked at non-free implementations, but I am
>> interested to
>> know what this means for those of us who have extensive exposure to
>> implementations such as Kaffe (GPL) or Jikes RVM (CPL). My
>> reading of
>> it is that I can't work on any part of Harmony for which I am
>> tainted by
>> my Jikes RVM exposure without permission from the copyright holder of
>> Jikes RVM. Is that right?
>>
>
> Same goes here!! here is the story.. i got two books (Programming the
> Java Virtual Machine and Inside the Java Virtual Machine).. i started
> reading about VM internals... and i thought i'd download kaffe or
> jikes RVM source code to look at their implementation and to play a
> little after reading some chapters from one of these books... will i
> be able to contribute to harmony vm if i do such?
That is our intention, yes. We just need to work out how we do this.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [Legal] Requirements for Committers
Posted by Ahmed Saad <my...@gmail.com>.
On 6/8/05, Steve Blackburn <St...@anu.edu.au> wrote:
> I have never looked at non-free implementations, but I am interested to
> know what this means for those of us who have extensive exposure to
> implementations such as Kaffe (GPL) or Jikes RVM (CPL). My reading of
> it is that I can't work on any part of Harmony for which I am tainted by
> my Jikes RVM exposure without permission from the copyright holder of
> Jikes RVM. Is that right?
Same goes here!! here is the story.. i got two books (Programming the
Java Virtual Machine and Inside the Java Virtual Machine).. i started
reading about VM internals... and i thought i'd download kaffe or
jikes RVM source code to look at their implementation and to play a
little after reading some chapters from one of these books... will i
be able to contribute to harmony vm if i do such?
(as for the classlibrary i never looked at the implementation but i
step in it when debugging some web applications. and i'm still a
student so no employers or whatever)
-ahmed
Re: [Legal] Requirements for Committers
Posted by Steve Blackburn <St...@anu.edu.au>.
Dalibor Topic wrote:
> Many people don't see the need to look at non-free software in
> general, and chances are pretty slim that anyone I know will ever get
> that bored and out of reading material to accept the 'Read only'
> license, for an example of a very funny non-free software license.
I have never looked at non-free implementations, but I am interested to
know what this means for those of us who have extensive exposure to
implementations such as Kaffe (GPL) or Jikes RVM (CPL). My reading of
it is that I can't work on any part of Harmony for which I am tainted by
my Jikes RVM exposure without permission from the copyright holder of
Jikes RVM. Is that right?
--Steve
Re: [Legal] Requirements for Committers
Posted by Dalibor Topic <ro...@kaffe.org>.
Nacho G. Mac Dowell wrote:
> Hi all,
>
> Geir Magnusson Jr. wrote:
>
>> a) Having a copy of src.jar on a computer as long as you never
>> viewed or edited the contents of the file.
>>
> How many people on this list have NEVER looked (not edited) at, say,
> java.lang.String?
Many, I'd think. To avoid the temptation, you should simply delete
src.jar from your computer.
> If you want people with extensive java knowledge to contribute to
> Harmony this requirement seems like a dead-end to me. Not for the VM
> internals, but for the class libraries. I suppose that, at least, any
> curious java developer using eclipse (I don't know about other IDE's)
> has. Something else would be pretending no one ever looked at src.jar...
There actually are people that have not looked at Sun's code out there.
Everyone coming new to the language, for example.
Many people don't see the need to look at non-free software in general,
and chances are pretty slim that anyone I know will ever get that bored
and out of reading material to accept the 'Read only' license, for an
example of a very funny non-free software license.
> Don't flame me, please. I'm just trying to address one of my major
> concerns about Harmony. If this is a MUST requirement, then Sun did a
> great job when releasing src.jar...
The current licensing terms of a popular non-free implementation(SCSL,
JRL, JIUL, JDL), despite all the various FAQs, and enthousiastic
statements by some marketing staff at the respective company, do not
address the issues at hand in a clear enough fashion.
See http://lists.gnu.org/archive/html/classpath/2005-05/msg00014.html
for one of many, many problems with the JRL, for example.
Yes, a certain company's legal team is pretty good at not helping what
they perceive as potential threats to their status. If that is an itch
you need to scratch, get in touch with *them* and get it fixed, as they
are the only ones who can.
cheers,
dalibor topic
Re: [Legal] Requirements for Committers
Posted by "Nacho G. Mac Dowell" <ig...@informa.es>.
Hi all,
Geir Magnusson Jr. wrote:
> a) Having a copy of src.jar on a computer as long as you never
> viewed or edited the contents of the file.
>
How many people on this list have NEVER looked (not edited) at, say,
java.lang.String?
If you want people with extensive java knowledge to contribute to
Harmony this requirement seems like a dead-end to me. Not for the VM
internals, but for the class libraries. I suppose that, at least, any
curious java developer using eclipse (I don't know about other IDE's)
has. Something else would be pretending no one ever looked at src.jar...
Don't flame me, please. I'm just trying to address one of my major
concerns about Harmony. If this is a MUST requirement, then Sun did a
great job when releasing src.jar...
best regards,
nacho
Re: [Legal] Requirements for Committers
Posted by "Ian F. Darwin" <ia...@darwinsys.com>.
+1
Ian
Re: [Legal] Requirements for Committers
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 8, 2005, at 5:16 AM, Leo Simons wrote:
> On 08-06-2005 00:08, "Geir Magnusson Jr." <ge...@apache.org> wrote:
>
>> I. Division of Repository
>>
>
> +1
>
>
>> II. Specific Access Control Lists
>>
>
> +1
>
> We could consider setting up a totally separate SVN repo for this,
> because
> the svn-authorization file would be the authoritive source of
> "tainting
> info" and we may want to publish that file.
Yes, good idea
>
>
>> III. Strict Limits on Committer Contribution
>>
>
> +1
>
>
>> IV. Be Proactive in Committer Education
>>
>
> +1
>
>
>> We could have [a legal form] as part of a standard svn commit message
>> template, for example. Other ideas welcome.
>>
>
> Perhaps employ a post-commit hook that rejects commits that don't
> have a
> filled-out template.
Well, I was thinking more of an informational message, but a short,
simple set of Y/N questions might help. OTOH, people might just get
in the habit of just doing the right answers, and not reading...
>
>
>> we might consider a form asking information like the following.
>>
>
> There's a lot in there. I don't feel qualified to comment.
>
>
>> Comments?
>>
>
> Expanding on what I said in my other e-mail, "committer" is
> something that
> has many non-legal connotations here at the ASF. It might make
> sense to
> define all or most of this in terms of contributors. WDYT?
Yes - "Authorized Contributor" as a defined term as one who has
executed the form.
geir
>
> - Leo
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [Legal] Requirements for Committers
Posted by Leo Simons <ma...@leosimons.com>.
On 08-06-2005 00:08, "Geir Magnusson Jr." <ge...@apache.org> wrote:
> I. Division of Repository
+1
> II. Specific Access Control Lists
+1
We could consider setting up a totally separate SVN repo for this, because
the svn-authorization file would be the authoritive source of "tainting
info" and we may want to publish that file.
> III. Strict Limits on Committer Contribution
+1
> IV. Be Proactive in Committer Education
+1
> We could have [a legal form] as part of a standard svn commit message
> template, for example. Other ideas welcome.
Perhaps employ a post-commit hook that rejects commits that don't have a
filled-out template.
> we might consider a form asking information like the following.
There's a lot in there. I don't feel qualified to comment.
> Comments?
Expanding on what I said in my other e-mail, "committer" is something that
has many non-legal connotations here at the ASF. It might make sense to
define all or most of this in terms of contributors. WDYT?
- Leo
Re: [Legal] Requirements for Committers
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 30, 2005, at 2:11 PM, Ricardo Morin wrote:
> Hi,
>
> I have some comments on Section I, Division of the
> Repository. In the current proposal, it appears as if
> the partitioning of the repository is three big
> chunks: JVM, Class library and Website/Documentation.
>
> Due to the very large size of this project, I would
> like to propose to break down the Class library part
> into the following more discrete modules:
>
> - GUI – Essentially swing
> - Client – Awt, java2D, etc
> - Core – lang, util, networking, io
> - Enterprise – jdbc, corba, jmx, etc
> - Security – security and crypto
> - XML – Xerces/Xalan
> - Tools – javac, jar, jdb, etc
If we ever have to do a class library, this is fine by me.
>
> This will move the project more in the modular
> direction, which was stated as one of main goals for
> Harmony. I believe that communities of interest are
> most likely to form around these projects.
Yes, indeed. But for now, until we have a compelling reason to
consider our own class library, we're working out how to work with
GNU Classpath.
>
> So Section I would look like:
>
> I. Division of Repository
> -------------------------
>
> 1) JVM
> 2) GUI class libraries
> 3) Client class libraries
> 4) Core class libraries
> 5) Enterprise class libraries
> 6) Security class libraries
> 7) XML class libraries
> 8) Tools
> 9) Website and Documentation
>
I'd rather see, if we did classlib :
1) JVM
a) core
b) mm
c) JIT
i) interpreter
ii) compiler
2) ClassLibrary
a) GUI
b) Client
c) core
d) ....
.....
z) tools
3) Website and documentation
This is a minor restructuring, but one that seems to make more
hierarchical sense to me.
> I would also like to propose to update Section II to
> clarify the granularity of the access control list to
> the division of the repository above.
That or finer, because we may need to partition some of the large
grain down, such as having a person who has to be kept out of
jvm.jit.compiler but can work in interpreter.
Right?
geir
>
> Thoughts? Comments?
>
> Thanks,
>
> Ricardo
>
> --- "Geir Magnusson Jr." <ge...@apache.org> wrote:
>
>
>> NOTE : THE FOLLOWING IS FOR DISCUSSION PURPOSES.
>> THIS PROPOSAL GOES
>> BEYOND STANDARD APACHE PRACTICE, AND WILL HAVE TO BE
>> REVIEWED - IF WE
>> CHOOSE TO FOLLOW THIS ROUTE - BY THE ASF.
>>
>> There are many legal and political concerns about
>> the Apache Harmony
>> project, and it behooves us to do the best job we
>> can at all times in
>> ensuring that the software contributed or created by
>> the community is
>> as "clean" (in the IP sense) as possible. We do
>> this to protect the
>> ASF, the committers, and the users of the software.
>>
>> There are are few issues that come to mind when
>> thinking about
>> committers :
>>
>> 1) What IP has the committer been exposed to,
>> and what is the position of the owner of that
>> IP
>> with respect to the committer's
>> participation?
>> For example, has the committer been exposed
>> to
>> copyrighted or patented material, in which an
>> accidental re-creation would put the project
>> or users at risk of legal action from the
>> IP owner?
>>
>> 2) If people have been exposed to code that
>> would be
>> problematic for us, what can we do to allow
>> the maximum
>> participation with the minimal risk?
>>
>> 3) How do we ensure that we carefully track our
>> committers and what they've been exposed to?
>>
>> To solve, consider the following :
>>
>> I. Division of Repository
>> -------------------------
>>
>> For starters, we can divide our SVN repository into
>> parts :
>>
>> 1) JVM
>> - VM
>> - JIT
>> - GC
>> - etc
>>
>> 2) Class library
>> - VM/lib interface :-b
>>
>> 3) Website and Documentation
>>
>> and we limit access to the SVN to which your
>> contributions have no
>> "taint" as we understand it at the moment. Because
>> attitudes will
>> change over time, I think that "taint" can go away
>> as an individual's
>> issue that causes the 'taint' gets resolved.
>>
>> We can start with access for website and docs
>> immediately w/o much
>> consideration for 'taint'.
>>
>> II. Specific Access Control Lists
>> ----------------------------------
>>
>> Through fine-grained (as necessary) access control
>> lists for the SVN
>> repo, we'll allow committers into repos for project
>> components for
>> which they have no "taint". If they've worked on
>> Sun's class
>> libraries in the past but no exposure to VM, we keep
>> them from any
>> class library work we do (if any) and allow them
>> into VM-related code.
>>
>> I think for simplicity in accounting, we should be
>> conservative and
>> explicit about access. You are granted access only
>> to repos that you
>> ask to be granted access to (although with the
>> exception of the
>> "taint" issue, we should grant to anything asked
>> for...) and
>> encourage people to keep their personal list small,
>> and ask for
>> access to be removed if they no longer need it.
>>
>> III. Strict Limits on Committer Contribution
>> ---------------------------------------------
>>
>> Committers can only commit contributions to the
>> repositories that
>> they personally created specifically for
>> contribution to Apache
>> Harmony. This is the standard stream of fresh
>> original work, small
>> enhancements and patches that are the normal flow of
>> project life.
>> The purpose of this rule is to explicitly prohibit
>> re-purposed "bulk"
>> code that the contributor believes is their original
>> work. We can
>> still accept those, but wish to track them
>> explicitly.
>>
>> IV. Be Proactive in Committer Education
>> ---------------------------------------
>>
>> People sometimes forget or don't understand the
>> intricacies of
>> copyright and authorhsip, and just want to get work
>> done. Therefore,
>> we should make a special effort to remind the
>> committers of the
>> limits, give them clear information on what to do if
>> a commit isn't w/
>> in the rules, and where to ask questions (and a list
>> of answered
>> questions for reference).
>>
>> We could have this as part of a standard svn commit
>> message template,
>> for example. Other ideas welcome.
>>
>> V. Required Committer Paperwork
>> -------------------------------
>>
>> Each committer is required to complete an standard
>> Apache Individual
>> Contributor License Agreement. This document
>> asserts that the
>> contributor is licensing their material to the ASF
>> under the Apache
>> license and is their original work (there's some
>> other details).
>>
>> For employed committers where it's appropriate, I'm
>> interested in
>> what we can do to get validation that the employer
>> doesn't own the
>> rights to the employee's work in the project. While
>> this is not
>> applicable to many legal jurisdictions, it is
>> applicable to the US,
>> and an element of concern here for Apache Harmony.
>> We don't want
>> code to be contributed that will later be deemed to
>> be a work for
>> hire or other kind of property of the employer, and
>> thus give a third
>> party some claim on us or our users.
>>
>> We would like to know who is contributing to the
>> project. To this
>> end, we might consider a form asking information
>> like the following.
>> This goes beyond standard ASF practice, and we would
>> of course have
>> this reviewed and approved by ASF lawyers and other
>> interested
>> members of the community (yes, it's fairly
>> conservative...) :
>>
>> -------------------------------------------
>>
>> 1) Identification
>>
>> Please provide the following information
>>
>> - Name (real name, please)
>> - E-mail and other electronic contact
>> information
>> - Mailing address (include Country)
>> - If you have an employer, include name and
>> address of employer
>>
>> 2) Access to Repositories :
>>
>> Apache Harmony would like to limit write access
>> to repositories
>> to those that need it, but will grant all that
>> is asked for as long
>> as there are no 'taint' issues.
>>
>> - Which components are you interested in
>> working on?
>>
>> 3) Taint
>>
>> The Project is committed to producing an
>> implementation
>>
> === message truncated ===
>
>
>
>
> ____________________________________________________
> Yahoo! Sports
> Rekindle the Rivalries. Sign up for Fantasy Football
> http://football.fantasysports.yahoo.com
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [Legal] Requirements for Committers
Posted by Ricardo Morin <mo...@yahoo.com>.
Hi,
I have some comments on Section I, Division of the
Repository. In the current proposal, it appears as if
the partitioning of the repository is three big
chunks: JVM, Class library and Website/Documentation.
Due to the very large size of this project, I would
like to propose to break down the Class library part
into the following more discrete modules:
- GUI Essentially swing
- Client Awt, java2D, etc
- Core lang, util, networking, io
- Enterprise jdbc, corba, jmx, etc
- Security security and crypto
- XML Xerces/Xalan
- Tools javac, jar, jdb, etc
This will move the project more in the modular
direction, which was stated as one of main goals for
Harmony. I believe that communities of interest are
most likely to form around these projects.
So Section I would look like:
I. Division of Repository
-------------------------
1) JVM
2) GUI class libraries
3) Client class libraries
4) Core class libraries
5) Enterprise class libraries
6) Security class libraries
7) XML class libraries
8) Tools
9) Website and Documentation
I would also like to propose to update Section II to
clarify the granularity of the access control list to
the division of the repository above.
Thoughts? Comments?
Thanks,
Ricardo
--- "Geir Magnusson Jr." <ge...@apache.org> wrote:
> NOTE : THE FOLLOWING IS FOR DISCUSSION PURPOSES.
> THIS PROPOSAL GOES
> BEYOND STANDARD APACHE PRACTICE, AND WILL HAVE TO BE
> REVIEWED - IF WE
> CHOOSE TO FOLLOW THIS ROUTE - BY THE ASF.
>
> There are many legal and political concerns about
> the Apache Harmony
> project, and it behooves us to do the best job we
> can at all times in
> ensuring that the software contributed or created by
> the community is
> as "clean" (in the IP sense) as possible. We do
> this to protect the
> ASF, the committers, and the users of the software.
>
> There are are few issues that come to mind when
> thinking about
> committers :
>
> 1) What IP has the committer been exposed to,
> and what is the position of the owner of that
> IP
> with respect to the committer's
> participation?
> For example, has the committer been exposed
> to
> copyrighted or patented material, in which an
> accidental re-creation would put the project
> or users at risk of legal action from the
> IP owner?
>
> 2) If people have been exposed to code that
> would be
> problematic for us, what can we do to allow
> the maximum
> participation with the minimal risk?
>
> 3) How do we ensure that we carefully track our
> committers and what they've been exposed to?
>
> To solve, consider the following :
>
> I. Division of Repository
> -------------------------
>
> For starters, we can divide our SVN repository into
> parts :
>
> 1) JVM
> - VM
> - JIT
> - GC
> - etc
>
> 2) Class library
> - VM/lib interface :-b
>
> 3) Website and Documentation
>
> and we limit access to the SVN to which your
> contributions have no
> "taint" as we understand it at the moment. Because
> attitudes will
> change over time, I think that "taint" can go away
> as an individual's
> issue that causes the 'taint' gets resolved.
>
> We can start with access for website and docs
> immediately w/o much
> consideration for 'taint'.
>
> II. Specific Access Control Lists
> ----------------------------------
>
> Through fine-grained (as necessary) access control
> lists for the SVN
> repo, we'll allow committers into repos for project
> components for
> which they have no "taint". If they've worked on
> Sun's class
> libraries in the past but no exposure to VM, we keep
> them from any
> class library work we do (if any) and allow them
> into VM-related code.
>
> I think for simplicity in accounting, we should be
> conservative and
> explicit about access. You are granted access only
> to repos that you
> ask to be granted access to (although with the
> exception of the
> "taint" issue, we should grant to anything asked
> for...) and
> encourage people to keep their personal list small,
> and ask for
> access to be removed if they no longer need it.
>
> III. Strict Limits on Committer Contribution
> ---------------------------------------------
>
> Committers can only commit contributions to the
> repositories that
> they personally created specifically for
> contribution to Apache
> Harmony. This is the standard stream of fresh
> original work, small
> enhancements and patches that are the normal flow of
> project life.
> The purpose of this rule is to explicitly prohibit
> re-purposed "bulk"
> code that the contributor believes is their original
> work. We can
> still accept those, but wish to track them
> explicitly.
>
> IV. Be Proactive in Committer Education
> ---------------------------------------
>
> People sometimes forget or don't understand the
> intricacies of
> copyright and authorhsip, and just want to get work
> done. Therefore,
> we should make a special effort to remind the
> committers of the
> limits, give them clear information on what to do if
> a commit isn't w/
> in the rules, and where to ask questions (and a list
> of answered
> questions for reference).
>
> We could have this as part of a standard svn commit
> message template,
> for example. Other ideas welcome.
>
> V. Required Committer Paperwork
> -------------------------------
>
> Each committer is required to complete an standard
> Apache Individual
> Contributor License Agreement. This document
> asserts that the
> contributor is licensing their material to the ASF
> under the Apache
> license and is their original work (there's some
> other details).
>
> For employed committers where it's appropriate, I'm
> interested in
> what we can do to get validation that the employer
> doesn't own the
> rights to the employee's work in the project. While
> this is not
> applicable to many legal jurisdictions, it is
> applicable to the US,
> and an element of concern here for Apache Harmony.
> We don't want
> code to be contributed that will later be deemed to
> be a work for
> hire or other kind of property of the employer, and
> thus give a third
> party some claim on us or our users.
>
> We would like to know who is contributing to the
> project. To this
> end, we might consider a form asking information
> like the following.
> This goes beyond standard ASF practice, and we would
> of course have
> this reviewed and approved by ASF lawyers and other
> interested
> members of the community (yes, it's fairly
> conservative...) :
>
> -------------------------------------------
>
> 1) Identification
>
> Please provide the following information
>
> - Name (real name, please)
> - E-mail and other electronic contact
> information
> - Mailing address (include Country)
> - If you have an employer, include name and
> address of employer
>
> 2) Access to Repositories :
>
> Apache Harmony would like to limit write access
> to repositories
> to those that need it, but will grant all that
> is asked for as long
> as there are no 'taint' issues.
>
> - Which components are you interested in
> working on?
>
> 3) Taint
>
> The Project is committed to producing an
> implementation
=== message truncated ===
____________________________________________________
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
http://football.fantasysports.yahoo.com