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/07/13 16:22:58 UTC
[legal] Mailing list policy
I'm focused on bringing our legal framework issues to conclusion. (I
have a long flight today, so expect to see something COB today...)
However, there's an issue that's been brought to my attention from
several people, and I wish propose that we explicitly state our
mailing list policies, as they are now based on "general
understandING" rather than a written policy that's available to
everyone.
I propose the following is added to the top of the mailing list page
on the site (I've added and published, currently marked as proposed)
and included in the welcome message for each subscriber, and posted
once a month to all lists as part of a monthly FAQ :
Apache Harmony mailing lists operate under the following terms :
This forum has been created for public communication about projects
of The Apache Software Foundation (the "Foundation"), a Delaware
nonprofit corporation classified as a public charity under 501(c)(3).
All communication intentionally submitted to the Foundation on this
forum is considered a Contribution to the Foundation unless otherwise
noted in the communication. The terms and conditions that apply to
your Contributions are defined by either a contributor license
agreement (CLA) signed by you and/or your employer or, if no such CLA
is on file at the Foundation, by the terms and conditions of
Contributions as defined by the Apache License, Version 2.0.
Further :
1) If you do not wish your post to be a Contribution, please do not
post it. However, in the event that you do, please mark as "NOT A
CONTRIBUTION" at the top of the posting.
2) Do not post any code that is not your original work, or code that
you do not have clear authorization to contribute.
3) Do not engage in detailed discussion of any implementation that
you have been exposed to unless such implementation is available to
everyone under an open source license or is your own implementation.
4) Under no circumstances will any committer accept code for
inclusion in our SVN repository contributed on the mailing list
unless it is from an Authorized Contributor, as defined $link.
(I'm still working on the $link :)
Comments?
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Mailing list policy
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Wed, 2005-07-13 at 21:50 +0200, Leo Simons wrote:
> NOT A CONTRIBUTION*
LIKEWISE.
> Mark Wielaard wrote:
> > Just one little nitpick.
>
> Heh.
>
> > Could we not use the Apache License, Version 2.0. But state something
> > like "are in the public domain". (Or use APL/GPL-dual license, LGPL,
> > MIT/X, modern-BSD, etc.) So that we can all use such contributions.
> > Most of the existing projects, like gcj, kaffe, cacao, jamvm, GNU
> > Classpath, etc. cannot accept GPL-incompatible code.
>
> As the world currently spins, people that contribute to Apache do that
> with the common understanding that they're contributing stuff under the
> Apache License (makes some kind of sense doesn't it? :-)).
As one of the founders I was under the impression that Harmony is about
cooperation and building bridges first, and that we host the project
currently at Apache is just a happy coincidence. Apache is a nice
environment and infrastructure to have around a project. And it
certainly is of great marketing value. But half of the people that
signed the Harmony proposal don't have an Apache background. We all
joined because we wanted something that is more that just another Apache
project. We wanted to see GNU Classpath, gcj, kaffe, ikvm.net and all
the other free software projects to unite and work together with the
rest of the community, whether FSF, ASF, independent or corporate.
> I like the simplicity and I think we need that kind of simplicity.
That is why I proposed to explicitly state that public communication is
in the public domain.
> I don't want to think about the implications of something being
> submitted through e-mail having a different legal status than something
> submitted through an issue tracker or through SVN (and, heck, that stuff
> is submitted as e-mails automatically!)
Agreed. And Geir also stated that submissions to the mailinglist should
never be checked into a code base without all the necessary paperwork in
place.
> While I understand your rationale and goal, for the reason above I think
> such a move is a bad idea unless we actually dual-license all of Harmony
> and *all* contributions are under those terms. I'm not saying that's
> necessarily a bad idea (I'll be firmly keeping my non-existent opinion
> to myself on that topic, thank you very much! :-)), but it would
> certainly constitute, an, ehm, change.
But change is what Harmony is all about!
We are all changing because we are now cooperating.
So yes, my suggestion is that we make the rule for Harmony to only have
code contributions that are both GPL and APL compatible.
Whether we do that for now by explictly stating that all public works
are in the public domain, by dual licensing APL/GPL, using a modified
GPL-exception (like we do for GNU Classpath) or an APL with a Free
Software friendly patent retaliation exception (or just strike the
second half of clause 3), or use the license of Intel ORP or IKVM.NET as
compromise is just an implementation detail.
(Both of these last two licenses attached. I prefer the ikvm one.)
Just show that we are serious about cooperation by being clear about it
upfront. So that everybody can feel free to contribute to the
mailinglist of the code in the knowledge that it will be reusable by all
the projects out there and all the projects that want to cooperate on
this.
> * wonder how soon this becomes /really/ annoying ;)
I guess we can keep this up for months.
Just hack your mail client to have a TOP sig :)
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Re: [legal] Mailing list policy
Posted by Leo Simons <ma...@leosimons.com>.
NOT A CONTRIBUTION*
Mark Wielaard wrote:
> Just one little nitpick.
Heh.
> On Wed, 2005-07-13 at 10:22 -0400, Geir Magnusson Jr. wrote:
>
>>The terms and conditions that apply to
>>your Contributions are defined by either a contributor license
>>agreement (CLA) signed by you and/or your employer or, if no such CLA
>>is on file at the Foundation, by the terms and conditions of
>>Contributions as defined by the Apache License, Version 2.0.
>
> Could we not use the Apache License, Version 2.0. But state something
> like "are in the public domain". (Or use APL/GPL-dual license, LGPL,
> MIT/X, modern-BSD, etc.) So that we can all use such contributions.
> Most of the existing projects, like gcj, kaffe, cacao, jamvm, GNU
> Classpath, etc. cannot accept GPL-incompatible code.
As the world currently spins, people that contribute to Apache do that
with the common understanding that they're contributing stuff under the
Apache License (makes some kind of sense doesn't it? :-)).
I like the simplicity and I think we need that kind of simplicity.
I don't want to think about the implications of something being
submitted through e-mail having a different legal status than something
submitted through an issue tracker or through SVN (and, heck, that stuff
is submitted as e-mails automatically!)
While I understand your rationale and goal, for the reason above I think
such a move is a bad idea unless we actually dual-license all of Harmony
and *all* contributions are under those terms. I'm not saying that's
necessarily a bad idea (I'll be firmly keeping my non-existent opinion
to myself on that topic, thank you very much! :-)), but it would
certainly constitute, an, ehm, change.
cheers,
Leo
* wonder how soon this becomes /really/ annoying ;)
Re: [legal] Mailing list policy
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Fri, 2005-07-15 at 11:03 +1000, Peter Donald wrote:
> > For Harmony we can lead by example. We are starting here with a clean
> > slate. Lets not by default adopt a policy that would prevent adoption of
> > the code by most of the existing projects. I started this effort
> > together with the others to build bridges between the existing projects.
> > That is a long process with many steps. Lets not make the mistake to
> > close the bridge as the first step by adopting a default license policy
> > that prevents cooperation with the existing free software projects.
>
> I don't disagree with what you are saying but I am not sure there is any
> need for action at this time. Geir has said that there are people who
> are trying to work out the license issues between ASL/GPL code at the
> moment. (I assume people inside Apache foundation and FSF). I think it
> may be a good idea to assume that this will eventually work out and
> people who want to use ASL code in GPL-ed works are able to. If this is
> wrong feel free to speak up. Until such a time where these talks break
> down or "fail" I think it may be more productive to steer away from more
> license discussions. What do you think?
Yes, I would like to steer away from more license discussions. But I
would like to do it by adopting a default policy that we can all live
with now and not postpone things till some future time. I like to act
now and not have to negotiate on every code/discussion on the license so
we can try out and play with it in any of the existing efforts.
The Harmony project actually started from some of use being sick of the
constant back and forth between ASF and FSF on details of licensing. Not
that we think that these issues aren't important, or that we don't want
to see them solved. Far from it. But we wanted to do something together
now. That is why I don't really understand why some people are still
advocating a default license policy that prevents us from easily and
effectively work together.
I see the Apache/LGPL issue is on the board schedule for this month.
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200507.mbox/%
3cc5e6325505070416385617e4f@mail.gmail.com%3e
Hopefully that will indeed be the start of resolving all these license
incompatibility-silliness.
Cheers,
Mark
Re: [legal] Mailing list policy
Posted by Peter Donald <pe...@realityforge.org>.
Mark Wielaard wrote:
>>But shouldn't this go both ways - should not anything contributed to any
>>of those projects be able to be shared with Harmony? AFAIK many of the
>>contributors make a conscious decision about which licenses they will or
>>will not contribute their work under.
>
>
> We can clearly only decide about our own Harmony work. And what we
> accept as contributions in that space. I would love to go both ways with
> code from already free and hopefully soon liberated proprietary code
> bases, but that might not be possible in the short term.
right.
> For Harmony we can lead by example. We are starting here with a clean
> slate. Lets not by default adopt a policy that would prevent adoption of
> the code by most of the existing projects. I started this effort
> together with the others to build bridges between the existing projects.
> That is a long process with many steps. Lets not make the mistake to
> close the bridge as the first step by adopting a default license policy
> that prevents cooperation with the existing free software projects.
I don't disagree with what you are saying but I am not sure there is any
need for action at this time. Geir has said that there are people who
are trying to work out the license issues between ASL/GPL code at the
moment. (I assume people inside Apache foundation and FSF). I think it
may be a good idea to assume that this will eventually work out and
people who want to use ASL code in GPL-ed works are able to. If this is
wrong feel free to speak up. Until such a time where these talks break
down or "fail" I think it may be more productive to steer away from more
license discussions. What do you think?
---
Cheers,
Peter Donald
"I have never killed a man, but I have read
many obituaries with great pleasure."
- Clarence Darrow
Re: [legal] Mailing list policy
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Fri, 2005-07-15 at 03:11 +1000, Peter Donald wrote:
> Feel free to pretend I am dumb. Basically you want that anything that is
> contributed to Harmony via mailing list "can be shared with projects
> like GNU Classpath, GCC, Kaffe, CACAO, JamVM, etc." which is an
> admirable goal to be sure.
Yes. But lets drop the 'via the mailing list' part. As Leo said we want
clarity above all. So no differences in how things are contributed.
> But shouldn't this go both ways - should not anything contributed to any
> of those projects be able to be shared with Harmony? AFAIK many of the
> contributors make a conscious decision about which licenses they will or
> will not contribute their work under.
We can clearly only decide about our own Harmony work. And what we
accept as contributions in that space. I would love to go both ways with
code from already free and hopefully soon liberated proprietary code
bases, but that might not be possible in the short term.
For GNU Classpath we are willing to make a compromise to get larger
cooperation. And seeing that we have more then 20 compiler and runtime
projects around it I think we succeeded nicely there (*). Although it
has been said that we should clarify some of the language we use for our
exception to the GPL, so we are working on that.
For Harmony we can lead by example. We are starting here with a clean
slate. Lets not by default adopt a policy that would prevent adoption of
the code by most of the existing projects. I started this effort
together with the others to build bridges between the existing projects.
That is a long process with many steps. Lets not make the mistake to
close the bridge as the first step by adopting a default license policy
that prevents cooperation with the existing free software projects.
Cheers,
Mark
(*) http://www.gnu.org/software/classpath/stories.html
Re: [legal] Mailing list policy
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
Feel free to pretend I am dumb. Basically you want that anything that is
contributed to Harmony via mailing list "can be shared with projects
like GNU Classpath, GCC, Kaffe, CACAO, JamVM, etc." which is an
admirable goal to be sure.
But shouldn't this go both ways - should not anything contributed to any
of those projects be able to be shared with Harmony? AFAIK many of the
contributors make a conscious decision about which licenses they will or
will not contribute their work under.
Mark Wielaard wrote:
> On Thu, 2005-07-14 at 10:17 -0400, Geir Magnusson Jr. wrote:
>
>>I really understand where you are coming from, and really thought
>>about how to present this, because there is no intent to stir up the
>>license wars again :) I had just been receiving questions from many
>>people and organizations, and felt that we should just make it clear.
>
>
> Of course we need to make things clear.
> But these people need to voice their questions and opinions on the list.
> Just like we all do. And then we decide how we want to cooperate with
> each other. I would love to discuss and exchange ideas with people about
> core library issues. How to best setup interfaces between the native
> platform, runtime and core libraries. And I saw some suggestions that I
> was about to comment on. But clearly if we are going the ASLv2 or the
> high-way route I won't participate in that (or at least not through this
> list).
>
> What are the concerns of these people and organizations you have spoken
> with? And how can we solve those concerns so that all participants can
> freely exchange their knowledge so that all projects can adopt that
> code?
>
> You said that you wanted this policy to be an example for the rest of
> Apache. Lets do that. Lets make a policy that means contributions can be
> shared with projects like GNU Classpath, GCC, Kaffe, CACAO, JamVM, etc.
> It seems that is what a lot of people have been wanting for a long time.
> To build a bridge between GNU and Apache. And that is why we started
> this Harmony effort in the first place.
>
> I proposed a couple of ways to do that in my post. You propose that it
> will all be under ASLv2 and closed off for these projects. How do we
> resolve this conflict? Why are my suggestions not acceptable to you and
> the many people and organizations you talked to.
> Lets start by discussing that in the open.
>
> Cheers,
>
> Mark
Re: [legal] Mailing list policy
Posted by netsql <ne...@roomity.com>.
Mark Wielaard wrote:
> is like putting up a huge
> sign: "Proprietary software hoarders welcome! Long haired freaky GNU
> people stay out!". Which isn't fun since my best friends are long haired
> freaky GNU people :)
>
This is puting it in terms I understand ;-)
.V
Re: [legal] Mailing list policy
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Thu, 2005-07-21 at 05:52 -0400, Geir Magnusson Jr. wrote:
> What do you have to negotiate? We want to define an interface for
> the VM and Class library that is 100% usable by anyone and everyone.
> I always imagined that we'd define the interface, and then each do an
> independent implementation.
This is probably where we just don't agree on how to do a design,
interface and framework on the VM/Platform-level. At this low level you
cannot just define some interface. It isn't about defining something
that makes programming against nice and beautiful for the programmer
(although that is certainly a big plus!). It is about making minimal
assumptions and showing actual implementations are possible without too
high performance impacts. All problems can be solved by an extra
interface indirection, but at a certain point each extra indirection
costs you and you don't want to introduce them if not absolutely needed.
So you need to design against actual implementations.
Besides that we do have interfaces already for lots of components, class
libraries, runtimes, platforms for the 20 or so runtimes, compilers and
tools around GNU Classpath. It isn't a really compelling story for me to
go back to these people and show them the new interfaces they will have
to implement. And then tell them they cannot use any of the actual code
from the "harmony" project since almost all of them are incompatible
with the default license they use. I want them to participate in this
design process and pick up the bits and pieces we create to show they
actually are sane and can be used before we cast some magical interface
into stone.
Cheers,
Mark
Re: [legal] Mailing list policy
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 20, 2005, at 2:20 PM, Mark Wielaard wrote:
> Hi,
>
> On Fri, 2005-07-15 at 02:40 -0400, Geir Magnusson Jr. wrote:
>
>> On Jul 14, 2005, at 11:18 AM, Mark Wielaard wrote:
>>
>>> On Thu, 2005-07-14 at 10:17 -0400, Geir Magnusson Jr. wrote:
>>>
>>>> I really understand where you are coming from, and really thought
>>>> about how to present this, because there is no intent to stir up
>>>> the
>>>> license wars again :) I had just been receiving questions from
>>>> many
>>>> people and organizations, and felt that we should just make it
>>>> clear.
>>>>
>>>
>>> I would love to discuss and exchange ideas with people
>>> about core library issues. How to best setup interfaces between the
>>> native platform, runtime and core libraries. And I saw some
>>> suggestions that I was about to comment on. But clearly if we are
>>> going the ASLv2 or the high-way route I won't participate in that
>>> (or at least not through this list).
>>>
>>
>> Ok - before we jump to this conclusion, can I ask why? Can we come
>> up with some use-cases that illustrate the downside for you? Is it
>> just "I won't grant a copyright license for code under AL2"?
>>
>
> That and I cannot currently accept contributions under AL2 since
> almost
> all of the existing projects I work with cannot.
I understand that, but that only applies to code contributions made
explicitly on the mail list.
How about any other use cases?
>
>
>>> Lets do that. Lets make a policy that means contributions can be
>>> shared with projects like GNU Classpath, GCC, Kaffe, CACAO, JamVM,
>>> etc.
>>> It seems that is what a lot of people have been wanting for a long
>>> time.
>>> To build a bridge between GNU and Apache. And that is why we started
>>> this Harmony effort in the first place.
>>>
>>
>> Any contribution *can* be shared with any other project. If those
>> other projects don't like AL2, the contributor can be approached for
>> a license under GPL, for example.
>>
>
> But why would we want to make it hard for people to cooperate. We know
> people will want to use the results of harmony in the existing GPL
> projects. So why insist on a GPL-incompatible default policy and not
> just make MIT/X (or some other commonly accepted and compatible
> license)
> the default for contributions?
>
No one wants to make it hard for people to cooperate, but we needed
to clearly state the default policy.
That said, I'm certainly willing to work to accommodate. I can't
guarantee success, but I will work for it.
>
>> Now, given that we're rather attached to the Apache License
>> here at the ASF, I'm not sure we wish to tangle with getting dual
>> licenses for contributions *here*.
>>
>> However, that said, I would certainly encourage that the code also be
>> donated by the copyright holder under a mutually acceptable license
>> for use w/ GPL, although it would be done elsewhere.
>>
>> All of the above is hypothetical - me thinking out loud, at the end
>> of a long day, and I may have another opinion or a different idea in
>> the morning. However, I do want to discuss options...
>>
>> Lets illustrate with use cases?
>>
>
> The use case is simple. Graeme and Tim posted some interesting
> ideas on
> class library interfaces. Having worked on GNU Classpath I obviously
> have some experiences with that. And they do have nice ideas, and I do
> think we can prevent some pitfalls that we fell into with GNU
> Classpath.
So far, I can't grok why you can't discuss those pitfalls.
> Now I would love to exchange some larger code samples with them as
> Graeme suggested. And I would even like to do that as part of Harmony.
> But with the current "default" policy I have to negotiate about. I
> wish
> my time and energy was infinite. But since it isn't I like working and
> discussing code that I can actually use in my existing projects.
What do you have to negotiate? We want to define an interface for
the VM and Class library that is 100% usable by anyone and everyone.
I always imagined that we'd define the interface, and then each do an
independent implementation.
>
> Really using ASLv2 as default for this project is like putting up a
> huge
> sign: "Proprietary software hoarders welcome! Long haired freaky GNU
> people stay out!". Which isn't fun since my best friends are long
> haired
> freaky GNU people :)
You are one of my favorite long-haired freaky GNU people, and I'll
note that no one will ever suggest that Dalibor has long hair...
Seriously... yes, proprietary "software hoarders" are welcome -
remember, we're about freedom :) Your problem with the ALv2 isn't
that it allows hoarding, anyway...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: a harmonious and inclusive community
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Geir" == Geir Magnusson <ge...@apache.org> writes:
Geir> But on a serious note, would it be possible for someone to give a
Geir> good technical description of the GNU Classpath VM interface so that
Geir> people who aren't aware and for whatever reason can't read it on the
Geir> classpath site due to legal reasons can be brought up to speed?
The basic idea in Classpath is that all VM decisions are delegated to
a set of VM-specific classes. A reference set of classes are provided
to make it simpler for a VM to implement the necessary glue.
Exactly which things are considered "VM decisions" is decided in an ad
hoc way.
Typically a VM class will appear in the same package as its users and
will use package-private protections so that malicious code can't
circumvent security checks.
To take a simple example, ClassLoader.defineClass() is a wrapper
around VMClassLoader.defineClass(). The latter is a static
VM-specific method. In the reference implementation it is declared
'native' (we compile Classpath against the reference implementation).
The reason we went this route instead of just requiring each VM to
provide its own implementation of each core class (e.g. ClassLoader)
is that the classes in question are largely shared code with a very
small amount of VM-specific glue.
In fact we have a good case study that this tradeoff is the right one
in libgcj -- libgcj still provides its own versions of some core
classes like String and Object. We periodically have to merge over
bug fixes and javadoc and the like. It seems to me that the other
classpath-using VMs have it simpler here, as they just require the
occasional tweak to their VM classes.
Let me know if you want more info.
Tom
Re: a harmonious and inclusive community
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Sorry if this went off the rails a bit... I really was just teasing.
But on a serious note, would it be possible for someone to give a
good technical description of the GNU Classpath VM interface so that
people who aren't aware and for whatever reason can't read it on the
classpath site due to legal reasons can be brought up to speed?
I know the legal stuff gets tiring.... but it would be good for the
discussion that's been started.
geir
On Jul 24, 2005, at 2:01 PM, Sven de Marothy wrote:
> On Sun, 2005-07-24 at 04:19 +0200, Robert Schuster wrote:
>
>> Does 'them' mean the VM interface? If yes, then I do not see a
>> problem.
>> IMHO we (=Classpath) should release the interface as MIT/X11
>> license or
>> even place it in the public domain.
>>
>> Would that be a feasible option?
>>
>
> IANAL. But as far as I'm concerned, an API is not copyrightable* in
> itself, so it's in the public domain to begin with.
>
> I'd personally prefer not to put a license on this, not only because
> it's redundant, but because Sun has expressed the legal fantasy
> that an
> API is copyrightable. And I wouldn't want GNU Classpath to take an
> action supporting that view, because in the same view Classpath is
> infringing Sun's copyrights.
>
> A better solution would perhaps to simply make a statement or
> affidavit
> on the status of the API saying: "We do not believe this is
> copyrighted." But let's leave that to FSF-legal.
>
> Kaffe is under the GPL and implements a lot of the Java class library
> APIs. Does that mean Sun's implementation infringes on the GPL? Or
> is it
> Kaffe which is infringing? And Linux is infringing on The Open Group's
> POSIX license. And so on and so forth.
>
> *Computer Associates International, Inc. versus Altai, Inc., (US 2nd
> Circuit 1992) frames the issue squarely.
>
> /Sven
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: a harmonious and inclusive community
Posted by Sven de Marothy <sv...@physto.se>.
On Sun, 2005-07-24 at 04:19 +0200, Robert Schuster wrote:
> Does 'them' mean the VM interface? If yes, then I do not see a problem.
> IMHO we (=Classpath) should release the interface as MIT/X11 license or
> even place it in the public domain.
>
> Would that be a feasible option?
IANAL. But as far as I'm concerned, an API is not copyrightable* in
itself, so it's in the public domain to begin with.
I'd personally prefer not to put a license on this, not only because
it's redundant, but because Sun has expressed the legal fantasy that an
API is copyrightable. And I wouldn't want GNU Classpath to take an
action supporting that view, because in the same view Classpath is
infringing Sun's copyrights.
A better solution would perhaps to simply make a statement or affidavit
on the status of the API saying: "We do not believe this is
copyrighted." But let's leave that to FSF-legal.
Kaffe is under the GPL and implements a lot of the Java class library
APIs. Does that mean Sun's implementation infringes on the GPL? Or is it
Kaffe which is infringing? And Linux is infringing on The Open Group's
POSIX license. And so on and so forth.
*Computer Associates International, Inc. versus Altai, Inc., (US 2nd
Circuit 1992) frames the issue squarely.
/Sven
Re: a harmonious and inclusive community
Posted by Davanum Srinivas <da...@gmail.com>.
Robert,
yes, i believe Geir was referring to the "VM Interface". that would be awesome!
-- dims
On 7/23/05, Robert Schuster <th...@gmx.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >> And there are often interface design discussions on the classpath
> >> mailinglist, please monitor that list
> >> (http://lists.gnu.org/archive/html/classpath/).
> >> Andrew Hughes really worked hard to document our current interfaces as
> >> now published with the latest GNU Classpath release at:
> >> http://www.gnu.org/software/classpath/docs/vmintegration.html
> >> Please discuss what seems impractical in this design for adoption of GNU
> >> Classpath as core library set.
> >
> >
> > Any chance of making them available under Mit/X license? ;)
> Does 'them' mean the VM interface? If yes, then I do not see a problem.
> IMHO we (=Classpath) should release the interface as MIT/X11 license or
> even place it in the public domain.
>
> Would that be a feasible option?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFC4vrIG9cfwmwwEtoRAr8mAJ99pyIn5M01AmwOkjybw+yj2cY/cgCeNyoP
> oSlcWZKtesKgTl4rB0mEg5s=
> =Rs9w
> -----END PGP SIGNATURE-----
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: a harmonious and inclusive community
Posted by Robert Schuster <th...@gmx.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> And there are often interface design discussions on the classpath
>> mailinglist, please monitor that list
>> (http://lists.gnu.org/archive/html/classpath/).
>> Andrew Hughes really worked hard to document our current interfaces as
>> now published with the latest GNU Classpath release at:
>> http://www.gnu.org/software/classpath/docs/vmintegration.html
>> Please discuss what seems impractical in this design for adoption of GNU
>> Classpath as core library set.
>
>
> Any chance of making them available under Mit/X license? ;)
Does 'them' mean the VM interface? If yes, then I do not see a problem.
IMHO we (=Classpath) should release the interface as MIT/X11 license or
even place it in the public domain.
Would that be a feasible option?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFC4vrIG9cfwmwwEtoRAr8mAJ99pyIn5M01AmwOkjybw+yj2cY/cgCeNyoP
oSlcWZKtesKgTl4rB0mEg5s=
=Rs9w
-----END PGP SIGNATURE-----
Re: a harmonious and inclusive community
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 22, 2005, at 7:59 PM, Mark Wielaard wrote:
> Hi,
>
> On Fri, 2005-07-22 at 10:18 +0100, Tim Ellison wrote:
>
>> It seems that all roads lead back to the discussion of licensing and
>> philosophy. Even that has degenerated into name calling which is
>> unhelpful for building a harmonious and inclusive community.
>>
>> While I understand perfectly that unifying the existing efforts in
>> J2SE-space is a goal of Harmony, I believe we need more visibility on
>> this list of the progress and successes in this space. Without such
>> visibility we appear to be going in circles, and many people who
>> initially expressed great interest in the project will walk away.
>>
>
> Thanks for trying to move forward with a positive message.
> I was indeed about to give up, not really because I personally feel
> excluded, but because we seem to completely fail to reach out to the
> 50/80 people working on the existing free efforts. And I cannot do it
> without the support of these people. They have worked for years on all
> aspects of what Harmony wants to do. They are very bright, smart
> people.
> And they are clearly proud that things like Tomcat, Eclipse, Jonas,
> Lucene, Axis, etc and all those other large free programs actually
> work
> now on the free systems. The community around harmony seems to
> sometimes
> dismiss some of this work. And I do feel we won't have a healthy
> community if we cannot bridge the gap with all those existing hackers
> (some of which already work on all this stuff full time).
I don't think we dismiss this work - after all, we worked hared to
make sure that these communities were part of the start, and we're
working to chance standard apache policy to accommodate them (the
list policy, for example...)
>
> Some of the people around the GNU Classpath projects really don't
> feel that they are part of Harmony. And I do try to bring them in. But
> when some of these people tried to get a feeling how/what people
> thought
> about what they have been working on for the last few years there
> wasn't
> any real technical feedback. The only feedback given is that it wasn't
> distributed under the Apache License. Which a lot of people
> interpreted
> as being offensive and hostile.
IIRC, that wasn't in any way a community sentiment. I certainly wish
you would distribute under the AL :) but I respect your decision to
choose the license under which you wish to work.
> My mistake was that I kind of tried to
> show (probably too aggressively) how annoying and uncooperative
> that is.
> Almost every existing project has a problem with the Apache License
> just
> because it isn't compatible with the GPL. This is infuriating (to both
> sides!).
>
> I don't believe I got my point across and I believe people now
> think it
> is all about licensing. But it really was about dismissing (not
> properly
> investigating) the work already done this last decade by other free
> software groups. And those groups do have some really nice ideas in
> their designs. And it is backed up with real free code and real free
> runtimes on very different platforms that use it. And from working
> with
> these people for some years now I know they like comparing and
> discussing technical details. Show their own strengths were they
> can and
> cooperate on common code when it makes sense.
Well, lets be fair here. I think that the VM/classlib interface is
important and a good place to start discussions. I used "the work
already done this last decade by other free software groups" - namely
the GNU Classpath VM interface - as a starting point.
You have to give me credit - not only didn't I ignore it, I used it
as the basic starting point.
I did offer criticism, as I felt that extending java.lang was
problematic for both engineering reasons as well as legal ones, and I
seem to recall both dismissed out of hand. I'd like to put that
behind us and keep going, now that we have more good ideas and
experience through Tim and Graeme.
>
> Please investigate what people have been working on all these
> years, and
> please give real technical feedback. Maybe the designs of Kaffe, GCJ,
> IKVM, JCVM, JamVM, JikesRVM, SableVM, JNode, Kissme, CACAO, etc. are
> really bad. And maybe they are really completely unportable to
> different
> systems/platforms. But if so then I am sure the designers would
> like to
> know about that. Lets try to engage them into a discussion.
At the same time, I encourage getting real technical feedback FROM
those people too :)
>
> And there are often interface design discussions on the classpath
> mailinglist, please monitor that list
> (http://lists.gnu.org/archive/html/classpath/).
> Andrew Hughes really worked hard to document our current interfaces as
> now published with the latest GNU Classpath release at:
> http://www.gnu.org/software/classpath/docs/vmintegration.html
> Please discuss what seems impractical in this design for adoption
> of GNU
> Classpath as core library set.
Any chance of making them available under Mit/X license? ;)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: a harmonious and inclusive community
Posted by Zsejki Sorin Miklós <zs...@gmail.com>.
Mark Wielaard wrote:
>Please, please, please concentrate on the technical issues raised.
>Investigate all the technical proposals, the work done by all the groups
>that want to cooperate on this.
>
Great! Let's let then the IBM guys to show us their class library /
virtual machine interface (please).
Re: a harmonious and inclusive community
Posted by Mark Wielaard <ma...@klomp.org>.
On Sat, 2005-07-23 at 12:17 -0700, Martin Olsson wrote:
> Mark Wielaard wrote:
> > Almost every existing project has a problem with the Apache License just
> > because it isn't compatible with the GPL. This is infuriating (to both
> > sides!).
>
> I just joined the list so maybe I missed something, but
> could you clarify what you mean here?
No. :) ASLv2/GPLv2 are incompatible. It sucks. Kick the ASF/FSF legal
committee members to make progress to work that out.
Seriously, the whole point of that post was to get going and assume the
license problems will be worked out. We want a solution for the short
term for this project and I have brought a vote to that effect:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200507.mbox/%3c1122066085.7915.278.camel@localhost.localdomain%3e
When that or something similar is accepted we can assume things are OK
for harmony. Then there are some people who have some creative legal
hacks to hopefully get the ASL GPL compatible and that will be it.
Please, please, please concentrate on the technical issues raised.
Investigate all the technical proposals, the work done by all the groups
that want to cooperate on this. Try "Hello, World!", Eclipse, Jonas,
look at the gump results of kaffe, read the interface designs posted,
play with the tools available and read some of the archives. Give some
technical feedback based on that. The political/license issues will get
worked out. People are really motivated to get that done.
Cheers,
Mark
Re: a harmonious and inclusive community
Posted by Martin Olsson <mn...@minimum.se>.
Mark Wielaard wrote:
> Almost every existing project has a problem with the Apache License just
> because it isn't compatible with the GPL. This is infuriating (to both
> sides!).
I just joined the list so maybe I missed something, but
could you clarify what you mean here? See for instance;
http://www.apache.org/licenses/GPL-compatibility.html
mvh
martin
a harmonious and inclusive community
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Fri, 2005-07-22 at 10:18 +0100, Tim Ellison wrote:
> It seems that all roads lead back to the discussion of licensing and
> philosophy. Even that has degenerated into name calling which is
> unhelpful for building a harmonious and inclusive community.
>
> While I understand perfectly that unifying the existing efforts in
> J2SE-space is a goal of Harmony, I believe we need more visibility on
> this list of the progress and successes in this space. Without such
> visibility we appear to be going in circles, and many people who
> initially expressed great interest in the project will walk away.
Thanks for trying to move forward with a positive message.
I was indeed about to give up, not really because I personally feel
excluded, but because we seem to completely fail to reach out to the
50/80 people working on the existing free efforts. And I cannot do it
without the support of these people. They have worked for years on all
aspects of what Harmony wants to do. They are very bright, smart people.
And they are clearly proud that things like Tomcat, Eclipse, Jonas,
Lucene, Axis, etc and all those other large free programs actually work
now on the free systems. The community around harmony seems to sometimes
dismiss some of this work. And I do feel we won't have a healthy
community if we cannot bridge the gap with all those existing hackers
(some of which already work on all this stuff full time).
Some of the people around the GNU Classpath projects really don't
feel that they are part of Harmony. And I do try to bring them in. But
when some of these people tried to get a feeling how/what people thought
about what they have been working on for the last few years there wasn't
any real technical feedback. The only feedback given is that it wasn't
distributed under the Apache License. Which a lot of people interpreted
as being offensive and hostile. My mistake was that I kind of tried to
show (probably too aggressively) how annoying and uncooperative that is.
Almost every existing project has a problem with the Apache License just
because it isn't compatible with the GPL. This is infuriating (to both
sides!).
I don't believe I got my point across and I believe people now think it
is all about licensing. But it really was about dismissing (not properly
investigating) the work already done this last decade by other free
software groups. And those groups do have some really nice ideas in
their designs. And it is backed up with real free code and real free
runtimes on very different platforms that use it. And from working with
these people for some years now I know they like comparing and
discussing technical details. Show their own strengths were they can and
cooperate on common code when it makes sense.
Please investigate what people have been working on all these years, and
please give real technical feedback. Maybe the designs of Kaffe, GCJ,
IKVM, JCVM, JamVM, JikesRVM, SableVM, JNode, Kissme, CACAO, etc. are
really bad. And maybe they are really completely unportable to different
systems/platforms. But if so then I am sure the designers would like to
know about that. Lets try to engage them into a discussion.
And there are often interface design discussions on the classpath
mailinglist, please monitor that list
(http://lists.gnu.org/archive/html/classpath/).
Andrew Hughes really worked hard to document our current interfaces as
now published with the latest GNU Classpath release at:
http://www.gnu.org/software/classpath/docs/vmintegration.html
Please discuss what seems impractical in this design for adoption of GNU
Classpath as core library set.
Then I will stop mentioning the war^Wlicenses.
I talked to a couple of people who assured me that people really want to
work this out as soon as possible. I'll assume it will for now. And just
concentrate on the technical issues, goals and the roadmap.
> Hopefully we can all discuss something like the relative importance of
> tools and capabilities in an SDK (javac, javadoc, apt, browser plug-in,
> etc), which of these exists and what order to implement those that do
> not.
That is a good thing to start with. Lets go over the list:
- compiler: Several candidates.
- jikes http://www.jikes.org/
Fast an pretty compliant source to byte code compiler written in
C++. Ideal for bootstrapping a system quickly.
- ecj http://www.eclipse.org/
The compiler of the Eclipse project. Written in java. Some people
are surprised that this compiler can be used stand alone. But it
actually is the default compiler on Fedora Core systems now.
(Compiled with gcj no native code to make it as fast, if not faster
then jikes). Already supports most of the 1.5 language constructs.
- gcj(x) http://gcc.gnu.org/java/
This is not just a source to byte code compiler, but also a gcc
frontend so that it can produce native code. gcjx, the next
generation gcj, will also be able to generate jni and cni header
files from source. And will support the new 1.5 language constructs.
(Tom Tromey, who is on this list is the main developer, so I will
let him hype it some more.)
For GNU Classpath we support compiling with the latest releases of all
the above. We try to make sure that we don't depend on any of these
compilers, although gcj is the default. When a bug is found in the
latest version of any of the above we add a workaround (and clearly
mark that in the source, so it can be removed when the compilers get
fixed) to give people the freedom to choose their own preferred
compiler (on arm for example jikes has some problems, but gcj works
fine). The GNU Classpath generics branch can currently only be
compiled with ecj, but gcjx is catching up.
- javadoc replacement.
- gjdoc http://www.gnu.org/software/classpath/cp-tools/
This is the GNU documentation generation framework for java source
files. It should be command line compatible with javadoc and comes
with a full Taglet and Doclet interface. We use it to generate the
documentation on http://developer.classpath.org/doc/
(Julian Scheid does most of the work on this these days.)
There is also texidoclet A "doclet" for converting comments into GNU
TexInfo source.
- browser plug-in.
- gcjwebplugin and gcjappletviewer http://www.nongnu.org/gcjwebplugin/
Despite the name it isn't gcj specific. I have been told the name
actually stands for "Groovy Cool Jive". It works nicely with mozilla.
It does depend on the GNU EmbeddedWindow awt extensions that GNU
Classpath provides.
(Michael Koch and Thomas Fitzsimmons work on this. Sven de Marothy is
writing Qt-AWT-peers to make embedding into konqueror on the KDE
platform nicer.)
- jar replacement.
- fastjar as shipped with gcc.
- kaffe jar.
Both seem pretty complete. What seems to be missing is a good
testsuite for all the corner cases.
- javah replacement.
- gcjh as shipped with gcc. Written in C which makes bootstrapping
easier in some cases.
- kaffeh as shipped with kaffe. There were recently lots of bug fixes
here. Written in java.
- javah as shipped with GNU Classpath Tools, written in java.
- gcjx (as mentioned above) will be able to generate jni and cni
headers from java source files. Written in C++.
- native2ascii replacement.
- Kaffe, GNU Classpath Tools and gcc have this.
All written in java. The one that comes with gcc is called jv-convert.
- javap replacement.
- GNU Classpath Tools comes with a javap implementation in java.
- GCC comes with jcf-dump written in C, which is a bit more powerful
then the one in GNU Classpath Tools and is a really nice tool when
bootstrapping stuff.
- serialver replacement.
- GNU Classpath Tools comes with a very simple one written in java.
- rmic and rmiregistry
- GNU Classpath Tools comes with grmic and grmiregistry.
(These were recently rewritten by Archit Shah)
Both are also shipped with gcc and kaffe.
I probably forget something. But I these are the tools that I know of
from the top of my head. We don't have most of the sercurity tools yet
(jarsigner, keytool and policytool), although the support classes for
these are already available in GNU Classpath so if written in java these
should not be such big tasks.
Cheers,
Mark
Re: [legal] Mailing list policy
Posted by Tim Ellison <t....@gmail.com>.
It seems that all roads lead back to the discussion of licensing and
philosophy. Even that has degenerated into name calling which is
unhelpful for building a harmonious and inclusive community.
While I understand perfectly that unifying the existing efforts in
J2SE-space is a goal of Harmony, I believe we need more visibility on
this list of the progress and successes in this space. Without such
visibility we appear to be going in circles, and many people who
initially expressed great interest in the project will walk away.
To maintain interest and momentum we need to identify some aspect of the
*technology* that we can progress in parallel. I'd love to have a full
and open discussion on the inter-VM and VM / Class libraries interface.
If people feel excluded from that discussion then we need a clear
indication that the collaboration blocks will be resolved shortly, or we
propose an alternative topic where we can work together.
Hopefully we can all discuss something like the relative importance of
tools and capabilities in an SDK (javac, javadoc, apt, browser plug-in,
etc), which of these exists and what order to implement those that do
not. If that doesn't suit, how about a discussion of the classlib
modularity?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Mark Wielaard wrote:
> Hi,
>
> On Fri, 2005-07-15 at 02:40 -0400, Geir Magnusson Jr. wrote:
>
>>On Jul 14, 2005, at 11:18 AM, Mark Wielaard wrote:
>>
>>>On Thu, 2005-07-14 at 10:17 -0400, Geir Magnusson Jr. wrote:
>>>
>>>>I really understand where you are coming from, and really thought
>>>>about how to present this, because there is no intent to stir up the
>>>>license wars again :) I had just been receiving questions from many
>>>>people and organizations, and felt that we should just make it clear.
>>>
>>>I would love to discuss and exchange ideas with people
>>>about core library issues. How to best setup interfaces between the
>>>native platform, runtime and core libraries. And I saw some
>>>suggestions that I was about to comment on. But clearly if we are
>>>going the ASLv2 or the high-way route I won't participate in that
>>>(or at least not through this list).
>>
>>Ok - before we jump to this conclusion, can I ask why? Can we come
>>up with some use-cases that illustrate the downside for you? Is it
>>just "I won't grant a copyright license for code under AL2"?
>
>
> That and I cannot currently accept contributions under AL2 since almost
> all of the existing projects I work with cannot.
>
>
>>>Lets do that. Lets make a policy that means contributions can be
>>>shared with projects like GNU Classpath, GCC, Kaffe, CACAO, JamVM,
>>>etc.
>>>It seems that is what a lot of people have been wanting for a long
>>>time.
>>>To build a bridge between GNU and Apache. And that is why we started
>>>this Harmony effort in the first place.
>>
>>Any contribution *can* be shared with any other project. If those
>>other projects don't like AL2, the contributor can be approached for
>>a license under GPL, for example.
>
>
> But why would we want to make it hard for people to cooperate. We know
> people will want to use the results of harmony in the existing GPL
> projects. So why insist on a GPL-incompatible default policy and not
> just make MIT/X (or some other commonly accepted and compatible license)
> the default for contributions?
>
>
>>Now, given that we're rather attached to the Apache License
>>here at the ASF, I'm not sure we wish to tangle with getting dual
>>licenses for contributions *here*.
>>
>>However, that said, I would certainly encourage that the code also be
>>donated by the copyright holder under a mutually acceptable license
>>for use w/ GPL, although it would be done elsewhere.
>>
>>All of the above is hypothetical - me thinking out loud, at the end
>>of a long day, and I may have another opinion or a different idea in
>>the morning. However, I do want to discuss options...
>>
>>Lets illustrate with use cases?
>
>
> The use case is simple. Graeme and Tim posted some interesting ideas on
> class library interfaces. Having worked on GNU Classpath I obviously
> have some experiences with that. And they do have nice ideas, and I do
> think we can prevent some pitfalls that we fell into with GNU Classpath.
> Now I would love to exchange some larger code samples with them as
> Graeme suggested. And I would even like to do that as part of Harmony.
> But with the current "default" policy I have to negotiate about. I wish
> my time and energy was infinite. But since it isn't I like working and
> discussing code that I can actually use in my existing projects.
>
> Really using ASLv2 as default for this project is like putting up a huge
> sign: "Proprietary software hoarders welcome! Long haired freaky GNU
> people stay out!". Which isn't fun since my best friends are long haired
> freaky GNU people :)
>
> Cheers,
>
> Mark
Re: [legal] Mailing list policy
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Fri, 2005-07-15 at 02:40 -0400, Geir Magnusson Jr. wrote:
> On Jul 14, 2005, at 11:18 AM, Mark Wielaard wrote:
> > On Thu, 2005-07-14 at 10:17 -0400, Geir Magnusson Jr. wrote:
> >> I really understand where you are coming from, and really thought
> >> about how to present this, because there is no intent to stir up the
> >> license wars again :) I had just been receiving questions from many
> >> people and organizations, and felt that we should just make it clear.
> >
> > I would love to discuss and exchange ideas with people
> > about core library issues. How to best setup interfaces between the
> > native platform, runtime and core libraries. And I saw some
> > suggestions that I was about to comment on. But clearly if we are
> > going the ASLv2 or the high-way route I won't participate in that
> > (or at least not through this list).
>
> Ok - before we jump to this conclusion, can I ask why? Can we come
> up with some use-cases that illustrate the downside for you? Is it
> just "I won't grant a copyright license for code under AL2"?
That and I cannot currently accept contributions under AL2 since almost
all of the existing projects I work with cannot.
> > Lets do that. Lets make a policy that means contributions can be
> > shared with projects like GNU Classpath, GCC, Kaffe, CACAO, JamVM,
> > etc.
> > It seems that is what a lot of people have been wanting for a long
> > time.
> > To build a bridge between GNU and Apache. And that is why we started
> > this Harmony effort in the first place.
>
> Any contribution *can* be shared with any other project. If those
> other projects don't like AL2, the contributor can be approached for
> a license under GPL, for example.
But why would we want to make it hard for people to cooperate. We know
people will want to use the results of harmony in the existing GPL
projects. So why insist on a GPL-incompatible default policy and not
just make MIT/X (or some other commonly accepted and compatible license)
the default for contributions?
> Now, given that we're rather attached to the Apache License
> here at the ASF, I'm not sure we wish to tangle with getting dual
> licenses for contributions *here*.
>
> However, that said, I would certainly encourage that the code also be
> donated by the copyright holder under a mutually acceptable license
> for use w/ GPL, although it would be done elsewhere.
>
> All of the above is hypothetical - me thinking out loud, at the end
> of a long day, and I may have another opinion or a different idea in
> the morning. However, I do want to discuss options...
>
> Lets illustrate with use cases?
The use case is simple. Graeme and Tim posted some interesting ideas on
class library interfaces. Having worked on GNU Classpath I obviously
have some experiences with that. And they do have nice ideas, and I do
think we can prevent some pitfalls that we fell into with GNU Classpath.
Now I would love to exchange some larger code samples with them as
Graeme suggested. And I would even like to do that as part of Harmony.
But with the current "default" policy I have to negotiate about. I wish
my time and energy was infinite. But since it isn't I like working and
discussing code that I can actually use in my existing projects.
Really using ASLv2 as default for this project is like putting up a huge
sign: "Proprietary software hoarders welcome! Long haired freaky GNU
people stay out!". Which isn't fun since my best friends are long haired
freaky GNU people :)
Cheers,
Mark
Re: [legal] Mailing list policy
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 15, 2005, at 3:44 AM, Leo Simons wrote:
> On 15-07-2005 08:40, "Geir Magnusson Jr." <ge...@apache.org> wrote:
>
>> For code samples, we want to take them in via JIRA, for tracking
>> reasons. Now, given that we're rather attached to the Apache License
>> here at the ASF, I'm not sure we wish to tangle with getting dual
>> licenses for contributions *here*.
>>
>
> Ha! That'd be cool. I mean, it can't be that hard to have a
>
> [X] I submit this Contribution under the terms of the Apache CLA
> [X] I submit this Contribution under the terms of the FSF CLA
> [X] I submit this Contribution under the terms of the Apache License
> [X] I submit this Contribution under the terms of the GNU GPL
> [X] I submit this Contribution under the terms of the GNU LGPL
> [ ] I submit this Contribution under the terms of the MIT License
You'd probably want to have a dropdown that is populated by a
webservices call to an OSI database.
>
> kind of form, similarly a commit template for SVN and a pre-commit
> hook
> that requires that kind of info. Then we have 7 different SVN
> repositories
> (a master and 6 others for each license), and commits that fall
> under any
> particular license get mirrored to the relevant repository.
Maybe a pop-quiz on pre-commit?
>
>
>> Lets illustrate with use cases?
>>
[SNIP]
In all seriousness, I was trying to find cases where mark would have
a problem with the normal discussion flow now that we've stated
explicitly the default licensing for contributions made via the list.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: [legal] Mailing list policy
Posted by Renaud BECHADE <re...@numerix.com>.
＞My name is Bob. I work on Apache Harmony fulltime. I am employed by a
company ＞that has a really big licensing firewall. I am not allowed to look
at anything ＞in the GPL,CDDL,NPL1.0 eg copyleft licensing corner. Our
lawyer has to approve ＞my open source mailing list subscriptions. He
questions whether I should be ＞reading dev@harmony. Help!
"""
But you don’t have right to read text from sites that promote any form of
opensource, so you should not know about harmony, hence you are guilty!
"""
-----Original Message-----
From: Leo Simons [mailto:mail@leosimons.com]
Sent: Friday, July 15, 2005 4:45 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [legal] Mailing list policy
On 15-07-2005 08:40, "Geir Magnusson Jr." <ge...@apache.org> wrote:
> For code samples, we want to take them in via JIRA, for tracking
> reasons. Now, given that we're rather attached to the Apache License
> here at the ASF, I'm not sure we wish to tangle with getting dual
> licenses for contributions *here*.
Ha! That'd be cool. I mean, it can't be that hard to have a
[X] I submit this Contribution under the terms of the Apache CLA
[X] I submit this Contribution under the terms of the FSF CLA
[X] I submit this Contribution under the terms of the Apache License
[X] I submit this Contribution under the terms of the GNU GPL
[X] I submit this Contribution under the terms of the GNU LGPL
[ ] I submit this Contribution under the terms of the MIT License
kind of form, similarly a commit template for SVN and a pre-commit hook
that requires that kind of info. Then we have 7 different SVN repositories
(a master and 6 others for each license), and commits that fall under any
particular license get mirrored to the relevant repository.
> Lets illustrate with use cases?
My name is Joe. I work on Apache Tomcat. I find a problem in the Harmony JDK
that causes tomcat to crash. I route around the problem. I send an e-mail to
dev@tomcat and CC the e-mail to dev@harmony. I assume the patch lives under
the terms of my existing Apache CLA and will be under the AL. I don't want
to think about this stuff.
My name is John. I work on GNU Classpath. I change a little bit of the
Classpath VM interface. I'm a nice guy so I write patches for half a dozen
VMs. I send an email to classpath@gnu and CC the e-mail to dev@harmony. I
assume the patch lives under the terms of my existing FSF CLA and will be
under the GPL+Exception. I don't want to think about this stuff.
My name is Bob. I work on Apache Harmony fulltime. I am employed by a
company that has a really big licensing firewall. I am not allowed to look
at anything in the GPL,CDDL,NPL1.0 eg copyleft licensing corner. Our lawyer
has to approve my open source mailing list subscriptions. He questions
whether I should be reading dev@harmony. Help!
My name is Kees. I work on KeesVM fulltime (its an embedded product for
mobile phones). KeesVM uses GNU Classpath. I am interested in discussing how
a VM should use GNU Classpath with the Apache Harmony community, they have a
lot to learn from me. I believe all software should be Free, and I only
release my software and knowledge under the terms of the GNU GPL. I must
say, I get a little tired of marking my emails with NOT A CONTRIBUTION.
My name is Leo. I couldn't care less about software licenses. I just want to
share code and ideas with people all over the world and not get sued for
doing so nor break any laws.
- LSD
Re: [legal] Mailing list policy
Posted by Leo Simons <ma...@leosimons.com>.
On 15-07-2005 08:40, "Geir Magnusson Jr." <ge...@apache.org> wrote:
> For code samples, we want to take them in via JIRA, for tracking
> reasons. Now, given that we're rather attached to the Apache License
> here at the ASF, I'm not sure we wish to tangle with getting dual
> licenses for contributions *here*.
Ha! That'd be cool. I mean, it can't be that hard to have a
[X] I submit this Contribution under the terms of the Apache CLA
[X] I submit this Contribution under the terms of the FSF CLA
[X] I submit this Contribution under the terms of the Apache License
[X] I submit this Contribution under the terms of the GNU GPL
[X] I submit this Contribution under the terms of the GNU LGPL
[ ] I submit this Contribution under the terms of the MIT License
kind of form, similarly a commit template for SVN and a pre-commit hook
that requires that kind of info. Then we have 7 different SVN repositories
(a master and 6 others for each license), and commits that fall under any
particular license get mirrored to the relevant repository.
> Lets illustrate with use cases?
My name is Joe. I work on Apache Tomcat. I find a problem in the Harmony JDK
that causes tomcat to crash. I route around the problem. I send an e-mail to
dev@tomcat and CC the e-mail to dev@harmony. I assume the patch lives under
the terms of my existing Apache CLA and will be under the AL. I don't want
to think about this stuff.
My name is John. I work on GNU Classpath. I change a little bit of the
Classpath VM interface. I'm a nice guy so I write patches for half a dozen
VMs. I send an email to classpath@gnu and CC the e-mail to dev@harmony. I
assume the patch lives under the terms of my existing FSF CLA and will be
under the GPL+Exception. I don't want to think about this stuff.
My name is Bob. I work on Apache Harmony fulltime. I am employed by a
company that has a really big licensing firewall. I am not allowed to look
at anything in the GPL,CDDL,NPL1.0 eg copyleft licensing corner. Our lawyer
has to approve my open source mailing list subscriptions. He questions
whether I should be reading dev@harmony. Help!
My name is Kees. I work on KeesVM fulltime (its an embedded product for
mobile phones). KeesVM uses GNU Classpath. I am interested in discussing how
a VM should use GNU Classpath with the Apache Harmony community, they have a
lot to learn from me. I believe all software should be Free, and I only
release my software and knowledge under the terms of the GNU GPL. I must
say, I get a little tired of marking my emails with NOT A CONTRIBUTION.
My name is Leo. I couldn't care less about software licenses. I just want to
share code and ideas with people all over the world and not get sued for
doing so nor break any laws.
- LSD
Re: [legal] Mailing list policy
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 14, 2005, at 11:18 AM, Mark Wielaard wrote:
> On Thu, 2005-07-14 at 10:17 -0400, Geir Magnusson Jr. wrote:
>
>> I really understand where you are coming from, and really thought
>> about how to present this, because there is no intent to stir up the
>> license wars again :) I had just been receiving questions from many
>> people and organizations, and felt that we should just make it clear.
>>
>
> Of course we need to make things clear.
> But these people need to voice their questions and opinions on the
> list.
> Just like we all do. And then we decide how we want to cooperate with
> each other. I would love to discuss and exchange ideas with people
> about
> core library issues. How to best setup interfaces between the native
> platform, runtime and core libraries. And I saw some suggestions
> that I
> was about to comment on. But clearly if we are going the ASLv2 or the
> high-way route I won't participate in that (or at least not through
> this
> list).
Ok - before we jump to this conclusion, can I ask why? Can we come
up with some use-cases that illustrate the downside for you? Is it
just "I won't grant a copyright license for code under AL2"?
>
> What are the concerns of these people and organizations you have
> spoken
> with? And how can we solve those concerns so that all participants can
> freely exchange their knowledge so that all projects can adopt that
> code?
The concern I heard was "what are the rules behind contributions made
on the mailing list - it isn't clear". So I just spelled it out.
Why can't you freely exchange knowledge under these terms? Any code
you contribute is some that you can put under any other license as
well, and we certainly can encourage others to do the same. I mean,
I assume that it would be a rare case, and it would be cases where
you take an active interest in the code...
>
> You said that you wanted this policy to be an example for the rest of
> Apache.
The example is the explicit statement. Apache lists operate with
this as the understanding. Given our sensitivity to IP issues,
clarity is good.
> Lets do that. Lets make a policy that means contributions can be
> shared with projects like GNU Classpath, GCC, Kaffe, CACAO, JamVM,
> etc.
> It seems that is what a lot of people have been wanting for a long
> time.
> To build a bridge between GNU and Apache. And that is why we started
> this Harmony effort in the first place.
Any contribution *can* be shared with any other project. If those
other projects don't like AL2, the contributor can be approached for
a license under GPL, for example.
I certainly will advocate a policy that any code coming into our SVN
come through JIRA, and we can certainly suggest that along with AL2,
contributors also grant [elsewhere] a copyright license under another
license that hasn't been interpreted to be in conflict with the GPL.
I assume that would solve the problem? I'm interested in finding
ways that anything that's contributed here is usable also by other
projects, even GPL-ed projects. That costs us nothing, and has great
upside for the whole community.
>
> I proposed a couple of ways to do that in my post. You propose that it
> will all be under ASLv2 and closed off for these projects. How do we
> resolve this conflict? Why are my suggestions not acceptable to you
> and
> the many people and organizations you talked to.
> Lets start by discussing that in the open.
>
Ok - first, we figure out what the problem is here on the mail list.
For anything but code samples, there should be no issue?
For code samples, we want to take them in via JIRA, for tracking
reasons. Now, given that we're rather attached to the Apache License
here at the ASF, I'm not sure we wish to tangle with getting dual
licenses for contributions *here*.
However, that said, I would certainly encourage that the code also be
donated by the copyright holder under a mutually acceptable license
for use w/ GPL, although it would be done elsewhere.
All of the above is hypothetical - me thinking out loud, at the end
of a long day, and I may have another opinion or a different idea in
the morning. However, I do want to discuss options...
Lets illustrate with use cases?
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Mailing list policy
Posted by Mark Wielaard <ma...@klomp.org>.
On Thu, 2005-07-14 at 10:17 -0400, Geir Magnusson Jr. wrote:
> I really understand where you are coming from, and really thought
> about how to present this, because there is no intent to stir up the
> license wars again :) I had just been receiving questions from many
> people and organizations, and felt that we should just make it clear.
Of course we need to make things clear.
But these people need to voice their questions and opinions on the list.
Just like we all do. And then we decide how we want to cooperate with
each other. I would love to discuss and exchange ideas with people about
core library issues. How to best setup interfaces between the native
platform, runtime and core libraries. And I saw some suggestions that I
was about to comment on. But clearly if we are going the ASLv2 or the
high-way route I won't participate in that (or at least not through this
list).
What are the concerns of these people and organizations you have spoken
with? And how can we solve those concerns so that all participants can
freely exchange their knowledge so that all projects can adopt that
code?
You said that you wanted this policy to be an example for the rest of
Apache. Lets do that. Lets make a policy that means contributions can be
shared with projects like GNU Classpath, GCC, Kaffe, CACAO, JamVM, etc.
It seems that is what a lot of people have been wanting for a long time.
To build a bridge between GNU and Apache. And that is why we started
this Harmony effort in the first place.
I proposed a couple of ways to do that in my post. You propose that it
will all be under ASLv2 and closed off for these projects. How do we
resolve this conflict? Why are my suggestions not acceptable to you and
the many people and organizations you talked to.
Lets start by discussing that in the open.
Cheers,
Mark
Re: [legal] Mailing list policy
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 13, 2005, at 2:24 PM, Mark Wielaard wrote:
> Hi,
>
> Most of this seems common sense. And I am a bit surprised people feel
> that it needs to be spelled out. But it is probably good to make the
> intentions completely clear even for a public list.
>
> Just one little nitpick.
>
> On Wed, 2005-07-13 at 10:22 -0400, Geir Magnusson Jr. wrote:
>
>> The terms and conditions that apply to
>> your Contributions are defined by either a contributor license
>> agreement (CLA) signed by you and/or your employer or, if no such CLA
>> is on file at the Foundation, by the terms and conditions of
>> Contributions as defined by the Apache License, Version 2.0.
>>
>
> Could we not use the Apache License, Version 2.0. But state something
> like "are in the public domain". (Or use APL/GPL-dual license, LGPL,
> MIT/X, modern-BSD, etc.) So that we can all use such contributions.
> Most of the existing projects, like gcj, kaffe, cacao, jamvm, GNU
> Classpath, etc. cannot accept GPL-incompatible code.
Any code that is contributed *via the list* will be deemed to be
under the AL, both for the purposes of rules of contribution (so that
any applicable patent licenses are granted) as well as default
license for recipient. This is exactly the same as if it came in
through JIRA. I'm just trying to keep things clear and clean.
As as recipient, you can choose to take under the AL, or just go to
the contributor of the code, and ask for another arrangement, like a
license under the GPL or whatever makes one happy.
I really understand where you are coming from, and really thought
about how to present this, because there is no intent to stir up the
license wars again :) I had just been receiving questions from many
people and organizations, and felt that we should just make it clear.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Mailing list policy
Posted by usman bashir <gr...@gmail.com>.
But i would say these are few things that are though to common to all of us
but it is better to be arranged that if some novice are coming then they can
not damage our intentions and put us into some legal issues.
thnx again geir
On 7/13/05, Mark Wielaard <ma...@klomp.org> wrote:
>
> Hi,
>
> Most of this seems common sense. And I am a bit surprised people feel
> that it needs to be spelled out. But it is probably good to make the
> intentions completely clear even for a public list.
>
> Just one little nitpick.
>
> On Wed, 2005-07-13 at 10:22 -0400, Geir Magnusson Jr. wrote:
> > The terms and conditions that apply to
> > your Contributions are defined by either a contributor license
> > agreement (CLA) signed by you and/or your employer or, if no such CLA
> > is on file at the Foundation, by the terms and conditions of
> > Contributions as defined by the Apache License, Version 2.0.
>
> Could we not use the Apache License, Version 2.0. But state something
> like "are in the public domain". (Or use APL/GPL-dual license, LGPL,
> MIT/X, modern-BSD, etc.) So that we can all use such contributions.
> Most of the existing projects, like gcj, kaffe, cacao, jamvm, GNU
> Classpath, etc. cannot accept GPL-incompatible code.
>
> Thanks,
>
> Mark
>
>
> BodyID:60059176.2.n.logpart (stored separately)
>
>
--
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] Mailing list policy
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
Most of this seems common sense. And I am a bit surprised people feel
that it needs to be spelled out. But it is probably good to make the
intentions completely clear even for a public list.
Just one little nitpick.
On Wed, 2005-07-13 at 10:22 -0400, Geir Magnusson Jr. wrote:
> The terms and conditions that apply to
> your Contributions are defined by either a contributor license
> agreement (CLA) signed by you and/or your employer or, if no such CLA
> is on file at the Foundation, by the terms and conditions of
> Contributions as defined by the Apache License, Version 2.0.
Could we not use the Apache License, Version 2.0. But state something
like "are in the public domain". (Or use APL/GPL-dual license, LGPL,
MIT/X, modern-BSD, etc.) So that we can all use such contributions.
Most of the existing projects, like gcj, kaffe, cacao, jamvm, GNU
Classpath, etc. cannot accept GPL-incompatible code.
Thanks,
Mark
Re: [legal] Mailing list policy
Posted by Dalibor Topic <ro...@kaffe.org>.
Geir Magnusson Jr. wrote:
>
> I propose the following is added to the top of the mailing list page on
> the site (I've added and published, currently marked as proposed) and
> included in the welcome message for each subscriber, and posted once a
> month to all lists as part of a monthly FAQ :
+1. thanks for writing it, geir.
cheers,
dalibor topic
Re: [legal] Mailing list policy
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 13, 2005, at 1:32 PM, Leo Simons wrote:
> NOT A CONTRIBUTION
>
> Geir Magnusson Jr. wrote:
>
>> I propose the following is added to the top of the mailing list
>> page on
>> the site (I've added and published, currently marked as proposed)
>> and
>> included in the welcome message for each subscriber, and posted
>> once a
>> month to all lists as part of a monthly FAQ :
>>
> <snip what followed/>
>
>> Comments?
>>
>
> Sure, why not. Pretty much sounds like what I believe current
> policy to
> be already around here :-)
>
That certainly is the understanding, but it's not clearly spelled
out. We get it right, we'll promote ASF-wide :)
geir
>
> cheers,
>
>
> Leo "NOT A CONTRIBUTION" Simons
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Mailing list policy
Posted by Leo Simons <ma...@leosimons.com>.
NOT A CONTRIBUTION
Geir Magnusson Jr. wrote:
> I propose the following is added to the top of the mailing list page on
> the site (I've added and published, currently marked as proposed) and
> included in the welcome message for each subscriber, and posted once a
> month to all lists as part of a monthly FAQ :
<snip what followed/>
> Comments?
Sure, why not. Pretty much sounds like what I believe current policy to
be already around here :-)
cheers,
Leo "NOT A CONTRIBUTION" Simons
Re: [legal] Mailing list policy
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 13, 2005, at 11:26 AM, Tim Ellison wrote:
> I agree with doing this. Ideally it is something that would appear on
> the Foundation website, i.e. not just for Project Harmony, but
> making it
> a clear policy is certainly the right thing to do.
>
Yes - I'm going to help get an ASF-wide policy on this, but we can
get it sorted out here first.
> FWIW the IETF do an equivalent thing (http://www.ietf.org/
> maillist.html)
> and even have it written on a piece of paper that is thrust into your
> hand at the group meetings.
>
> The tiniest nit:
>
>> If you do not wish your post to be a Contribution, please do not
>> post it. However, in the event that you do, ...
>>
>
> how about
> If you do not wish your post to be a Contribution, we would prefer
> that
> you do not post it. However, in the event that you do, ...
>
done
> Regards,
> Tim
>
> Geir Magnusson Jr. wrote:
>
>> I'm focused on bringing our legal framework issues to conclusion. (I
>> have a long flight today, so expect to see something COB today...)
>>
>> However, there's an issue that's been brought to my attention from
>> several people, and I wish propose that we explicitly state our
>> mailing
>> list policies, as they are now based on "general understandING"
>> rather
>> than a written policy that's available to everyone.
>>
>> I propose the following is added to the top of the mailing list
>> page on
>> the site (I've added and published, currently marked as proposed)
>> and
>> included in the welcome message for each subscriber, and posted
>> once a
>> month to all lists as part of a monthly FAQ :
>>
>> Apache Harmony mailing lists operate under the following terms :
>>
>> This forum has been created for public communication about
>> projects of
>> The Apache Software Foundation (the "Foundation"), a Delaware
>> nonprofit
>> corporation classified as a public charity under 501(c)(3). All
>> communication intentionally submitted to the Foundation on this
>> forum
>> is considered a Contribution to the Foundation unless otherwise
>> noted
>> in the communication. The terms and conditions that apply to your
>> Contributions are defined by either a contributor license agreement
>> (CLA) signed by you and/or your employer or, if no such CLA is on
>> file
>> at the Foundation, by the terms and conditions of Contributions as
>> defined by the Apache License, Version 2.0.
>>
>>
>> Further :
>>
>> 1) If you do not wish your post to be a Contribution, please do not
>> post it. However, in the event that you do, please mark as "NOT A
>> CONTRIBUTION" at the top of the posting.
>>
>> 2) Do not post any code that is not your original work, or code that
>> you do not have clear authorization to contribute.
>>
>> 3) Do not engage in detailed discussion of any implementation
>> that you
>> have been exposed to unless such implementation is available to
>> everyone under an open source license or is your own implementation.
>>
>> 4) Under no circumstances will any committer accept code for
>> inclusion
>> in our SVN repository contributed on the mailing list unless it
>> is from
>> an Authorized Contributor, as defined $link.
>>
>> (I'm still working on the $link :)
>>
>> Comments?
>>
>>
>>
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Mailing list policy
Posted by Tim Ellison <t....@gmail.com>.
I agree with doing this. Ideally it is something that would appear on
the Foundation website, i.e. not just for Project Harmony, but making it
a clear policy is certainly the right thing to do.
FWIW the IETF do an equivalent thing (http://www.ietf.org/maillist.html)
and even have it written on a piece of paper that is thrust into your
hand at the group meetings.
The tiniest nit:
> If you do not wish your post to be a Contribution, please do not
> post it. However, in the event that you do, ...
how about
If you do not wish your post to be a Contribution, we would prefer that
you do not post it. However, in the event that you do, ...
Regards,
Tim
Geir Magnusson Jr. wrote:
> I'm focused on bringing our legal framework issues to conclusion. (I
> have a long flight today, so expect to see something COB today...)
>
> However, there's an issue that's been brought to my attention from
> several people, and I wish propose that we explicitly state our mailing
> list policies, as they are now based on "general understandING" rather
> than a written policy that's available to everyone.
>
> I propose the following is added to the top of the mailing list page on
> the site (I've added and published, currently marked as proposed) and
> included in the welcome message for each subscriber, and posted once a
> month to all lists as part of a monthly FAQ :
>
> Apache Harmony mailing lists operate under the following terms :
>
> This forum has been created for public communication about projects of
> The Apache Software Foundation (the "Foundation"), a Delaware nonprofit
> corporation classified as a public charity under 501(c)(3). All
> communication intentionally submitted to the Foundation on this forum
> is considered a Contribution to the Foundation unless otherwise noted
> in the communication. The terms and conditions that apply to your
> Contributions are defined by either a contributor license agreement
> (CLA) signed by you and/or your employer or, if no such CLA is on file
> at the Foundation, by the terms and conditions of Contributions as
> defined by the Apache License, Version 2.0.
>
>
> Further :
>
> 1) If you do not wish your post to be a Contribution, please do not
> post it. However, in the event that you do, please mark as "NOT A
> CONTRIBUTION" at the top of the posting.
>
> 2) Do not post any code that is not your original work, or code that
> you do not have clear authorization to contribute.
>
> 3) Do not engage in detailed discussion of any implementation that you
> have been exposed to unless such implementation is available to
> everyone under an open source license or is your own implementation.
>
> 4) Under no circumstances will any committer accept code for inclusion
> in our SVN repository contributed on the mailing list unless it is from
> an Authorized Contributor, as defined $link.
>
> (I'm still working on the $link :)
>
> Comments?
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [legal] Mailing list policy
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 13, 2005, at 8:59 PM, Renaud BECHADE wrote:
>
> Seems good to me.
> One question as I am curious: isn't it enough just to state "by the
> terms
> and conditions of Contributions as defined by the Apache License,
> Version
> 2.0."?
I don't understand - what would you remove?
geir
>
> Cheers,
>
> RB
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@apache.org]
> Sent: Wednesday, July 13, 2005 11:23 PM
> To: harmony-dev@incubator.apache.org
> Subject: [legal] Mailing list policy
>
> I'm focused on bringing our legal framework issues to conclusion. (I
> have a long flight today, so expect to see something COB today...)
>
> However, there's an issue that's been brought to my attention from
> several people, and I wish propose that we explicitly state our
> mailing list policies, as they are now based on "general
> understandING" rather than a written policy that's available to
> everyone.
>
> I propose the following is added to the top of the mailing list page
> on the site (I've added and published, currently marked as proposed)
> and included in the welcome message for each subscriber, and posted
> once a month to all lists as part of a monthly FAQ :
>
> Apache Harmony mailing lists operate under the following terms :
>
> This forum has been created for public communication about projects
> of The Apache Software Foundation (the "Foundation"), a Delaware
> nonprofit corporation classified as a public charity under 501(c)(3).
> All communication intentionally submitted to the Foundation on this
> forum is considered a Contribution to the Foundation unless otherwise
> noted in the communication. The terms and conditions that apply to
> your Contributions are defined by either a contributor license
> agreement (CLA) signed by you and/or your employer or, if no such CLA
> is on file at the Foundation, by the terms and conditions of
> Contributions as defined by the Apache License, Version 2.0.
>
>
> Further :
>
> 1) If you do not wish your post to be a Contribution, please do not
> post it. However, in the event that you do, please mark as "NOT A
> CONTRIBUTION" at the top of the posting.
>
> 2) Do not post any code that is not your original work, or code that
> you do not have clear authorization to contribute.
>
> 3) Do not engage in detailed discussion of any implementation that
> you have been exposed to unless such implementation is available to
> everyone under an open source license or is your own implementation.
>
> 4) Under no circumstances will any committer accept code for
> inclusion in our SVN repository contributed on the mailing list
> unless it is from an Authorized Contributor, as defined $link.
>
> (I'm still working on the $link :)
>
> Comments?
>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
RE: [legal] Mailing list policy
Posted by Renaud BECHADE <re...@numerix.com>.
Seems good to me.
One question as I am curious: isn't it enough just to state "by the terms
and conditions of Contributions as defined by the Apache License, Version
2.0."?
Cheers,
RB
-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@apache.org]
Sent: Wednesday, July 13, 2005 11:23 PM
To: harmony-dev@incubator.apache.org
Subject: [legal] Mailing list policy
I'm focused on bringing our legal framework issues to conclusion. (I
have a long flight today, so expect to see something COB today...)
However, there's an issue that's been brought to my attention from
several people, and I wish propose that we explicitly state our
mailing list policies, as they are now based on "general
understandING" rather than a written policy that's available to
everyone.
I propose the following is added to the top of the mailing list page
on the site (I've added and published, currently marked as proposed)
and included in the welcome message for each subscriber, and posted
once a month to all lists as part of a monthly FAQ :
Apache Harmony mailing lists operate under the following terms :
This forum has been created for public communication about projects
of The Apache Software Foundation (the "Foundation"), a Delaware
nonprofit corporation classified as a public charity under 501(c)(3).
All communication intentionally submitted to the Foundation on this
forum is considered a Contribution to the Foundation unless otherwise
noted in the communication. The terms and conditions that apply to
your Contributions are defined by either a contributor license
agreement (CLA) signed by you and/or your employer or, if no such CLA
is on file at the Foundation, by the terms and conditions of
Contributions as defined by the Apache License, Version 2.0.
Further :
1) If you do not wish your post to be a Contribution, please do not
post it. However, in the event that you do, please mark as "NOT A
CONTRIBUTION" at the top of the posting.
2) Do not post any code that is not your original work, or code that
you do not have clear authorization to contribute.
3) Do not engage in detailed discussion of any implementation that
you have been exposed to unless such implementation is available to
everyone under an open source license or is your own implementation.
4) Under no circumstances will any committer accept code for
inclusion in our SVN repository contributed on the mailing list
unless it is from an Authorized Contributor, as defined $link.
(I'm still working on the $link :)
Comments?
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org