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/10/11 00:08:20 UTC
[legal] Bulk contribution barrier to entry
We've now accepted three contributions so far, and I think we have a
small problem that isn't easy to solve.
The problem is that for a bulk contribution - something created
elsewhere and being contributed to harmony - we require that all
authors of that work are Authorized Contributors, meaning that they
hadn't been exposed to implementations of Java that weren't either
available under an open source license, or were owned by an entity
willing to give the author permission to work on other
implementations elsewhere.
See http://incubator.apache.org/harmony/
bulk_contribution_checklist.html Part III
This is a very high standard, one that helps ensure clean IP
provenance for our codebase.
However, I suspect it will be too high of a standard. For example,
suppose the Kaffe project wanted to offer a copyright license to
their codebase to Harmony? I bet it can't be done - we'd have to
chase down every contributor to the codebase and get the signed
agreement. Suppose Sun wanted to donate J2SE? :) I'm betting they
couldn't provide the necessary documentation either...
So what do we do?
We need to balance a few things:
1) Make this flexible enough that the project can choose to accept
software for which ACQs aren't obtainable from all authors.
2) Make this strong enough that we don't put the project at
unreasonable risk, and that the consumers of the software have
confidence that the codebase is clean.
Suggestions? One possibility is that for those that can't satisfy
the status quo framework, we have a set of questions that allow us to
understand the source of the code and the manner in which it was
developed. We'd like this to be somewhat objective yet still give
the project room to reject if it doesn't "feel right", we want the
process used and information obtained to be available to the public
so that any interested consumer of our software can understand where
it came from.
Ideas?
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Bulk contribution barrier to entry
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Tue, 2005-10-11 at 08:52 -0500, Archie Cobbs wrote:
> Same with the FSF. E.g., Classpath hackers must sign a document
> granting the FSF copyright. This is so the FSF can be allowed to
> distribute Classpath without getting explicit permission from
> every author (which would be very unweildy). But the original
> authors still are allowed to distribute their own work too,
> even under a non-free license, if they want to.
Yes. The idea is that the contribution is a gift to the Free Software
community in the first place. So the standard contract has a clause that
permits you to use your code even in proprietary programs. The FSF does
ask to get a 30 days' notice so they know and have a record of all code
they distribute that a contributor also distributes under another
license. You don't need to invoke this clause in order to distribute
copies as free software under the GNU GPL, since everyone is allowed to
do that of course.
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] Bulk contribution barrier to entry
Posted by Archie Cobbs <ar...@dellroad.org>.
Dermot Dunnion wrote:
> It seems to me that you don't need the permission of every author, what
> you need is permission of every copyright owner.
I could be wrong here, but typically I think you only need permission
of *any* copyright owner, not every one (although I'm sure you could
also structure things that way).
E.g., person A writes software X and therefore has copyright.
Person A donates X to Apache, and in the process assigns copyright
rights to the Apache project. Now Apache is free to distribute X
without getting explicit permission from A every time.
Same with the FSF. E.g., Classpath hackers must sign a document
granting the FSF copyright. This is so the FSF can be allowed to
distribute Classpath without getting explicit permission from
every author (which would be very unweildy). But the original
authors still are allowed to distribute their own work too,
even under a non-free license, if they want to.
Disclaimer: I ain't no lawyer :-)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [legal] Bulk contribution barrier to entry
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 11, 2005, at 4:53 AM, Dermot Dunnion wrote:
> Ooh, my first post. I've been lurking for a few weeks.
>
> It seems to me that you don't need the permission of every author,
> what you need is permission of every copyright owner.
> So, if Sun gave you full rights to use J2SE source in any fashion,
> you would not also need permission from every Sun employee and
> contractor that ever wrote any code for J2SE. The permission from
> each author is more applicable to an OSS-developed codebase.
You are absolutely right that we require the permission of the
copyright owner - that's standard ASF practice - but we got a step
further in Harmomny : we want to be sure that the software we receive
_for Harmony_ was written by people with acceptable exposure to other
implementations.
We do this latter step to ensure that we can produce software that
truly is an independent implementation of J2SE, and contains no code
improperly obtained from other implementations, or have code that
could be subject to come kind of claim by the copyright holder of
another implementation.
We are interested in protecting both other copyright holders by
respecting their rights, and our downstream users by ensuring that
what they receive under the Apache License has no unforeseen or
unknown encumbrance, or at least do the best job we can. (The
absolute "best job we can" would involve taking monks or some other
group of people that have been living in isolation, training them to
be programmers, and getting them to write a full, clean
implementation from scratch. That may have it's advantages if said
monks produced good wine or beer or something, but probably not
something in scope for this project)
>
> This distinction may help to define what we need to accept code.
>
> My personal viewpoint is that if we receive code for which we can't
> get clear permission, it's a significant risk to use it and we
> shouldn't.
> However, other may be less risk-averse and therefore we should vote.
Understand that not having copyright owner permission is a total non-
starter. We won't even get as far as a vote if we don't have that.
geir
>
> My idea of an outline process is:
> - get code
> - verify our right to use
> - one of the following:
> accept (clear right to use)
> reject (tainted code or (unclear permissions and moderate-
> value) )
> vote(valuable code and unclear permissions)
>
> Dermot Dunnion
> ddunnion@cryptall.com
>
>
> Geir Magnusson Jr. wrote:
>
>
>> We've now accepted three contributions so far, and I think we have
>> a small problem that isn't easy to solve.
>>
>> The problem is that for a bulk contribution - something created
>> elsewhere and being contributed to harmony - we require that all
>> authors of that work are Authorized Contributors, meaning that
>> they hadn't been exposed to implementations of Java that weren't
>> either available under an open source license, or were owned by
>> an entity willing to give the author permission to work on other
>> implementations elsewhere.
>>
>> See http://incubator.apache.org/harmony/
>> bulk_contribution_checklist.html Part III
>>
>> This is a very high standard, one that helps ensure clean IP
>> provenance for our codebase.
>>
>> However, I suspect it will be too high of a standard. For
>> example, suppose the Kaffe project wanted to offer a copyright
>> license to their codebase to Harmony? I bet it can't be done -
>> we'd have to chase down every contributor to the codebase and get
>> the signed agreement. Suppose Sun wanted to donate J2SE? :)
>> I'm betting they couldn't provide the necessary documentation
>> either...
>>
>> So what do we do?
>>
>> We need to balance a few things:
>>
>> 1) Make this flexible enough that the project can choose to
>> accept software for which ACQs aren't obtainable from all authors.
>> 2) Make this strong enough that we don't put the project at
>> unreasonable risk, and that the consumers of the software have
>> confidence that the codebase is clean.
>>
>> Suggestions? One possibility is that for those that can't
>> satisfy the status quo framework, we have a set of questions that
>> allow us to understand the source of the code and the manner in
>> which it was developed. We'd like this to be somewhat objective
>> yet still give the project room to reject if it doesn't "feel
>> right", we want the process used and information obtained to be
>> available to the public so that any interested consumer of our
>> software can understand where it came from.
>>
>> Ideas?
>>
>>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.14/128 - Release Date:
> 10/10/2005
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Bulk contribution barrier to entry
Posted by Dermot Dunnion <dd...@cryptall.com>.
Ooh, my first post. I've been lurking for a few weeks.
It seems to me that you don't need the permission of every author, what
you need is permission of every copyright owner.
So, if Sun gave you full rights to use J2SE source in any fashion, you
would not also need permission from every Sun employee and contractor
that ever wrote any code for J2SE. The permission from each author is
more applicable to an OSS-developed codebase.
This distinction may help to define what we need to accept code.
My personal viewpoint is that if we receive code for which we can't get
clear permission, it's a significant risk to use it and we shouldn't.
However, other may be less risk-averse and therefore we should vote.
My idea of an outline process is:
- get code
- verify our right to use
- one of the following:
accept (clear right to use)
reject (tainted code or (unclear permissions and moderate-value) )
vote(valuable code and unclear permissions)
Dermot Dunnion
ddunnion@cryptall.com
Geir Magnusson Jr. wrote:
> We've now accepted three contributions so far, and I think we have a
> small problem that isn't easy to solve.
>
> The problem is that for a bulk contribution - something created
> elsewhere and being contributed to harmony - we require that all
> authors of that work are Authorized Contributors, meaning that they
> hadn't been exposed to implementations of Java that weren't either
> available under an open source license, or were owned by an entity
> willing to give the author permission to work on other
> implementations elsewhere.
>
> See http://incubator.apache.org/harmony/
> bulk_contribution_checklist.html Part III
>
> This is a very high standard, one that helps ensure clean IP
> provenance for our codebase.
>
> However, I suspect it will be too high of a standard. For example,
> suppose the Kaffe project wanted to offer a copyright license to
> their codebase to Harmony? I bet it can't be done - we'd have to
> chase down every contributor to the codebase and get the signed
> agreement. Suppose Sun wanted to donate J2SE? :) I'm betting they
> couldn't provide the necessary documentation either...
>
> So what do we do?
>
> We need to balance a few things:
>
> 1) Make this flexible enough that the project can choose to accept
> software for which ACQs aren't obtainable from all authors.
> 2) Make this strong enough that we don't put the project at
> unreasonable risk, and that the consumers of the software have
> confidence that the codebase is clean.
>
> Suggestions? One possibility is that for those that can't satisfy
> the status quo framework, we have a set of questions that allow us to
> understand the source of the code and the manner in which it was
> developed. We'd like this to be somewhat objective yet still give
> the project room to reject if it doesn't "feel right", we want the
> process used and information obtained to be available to the public
> so that any interested consumer of our software can understand where
> it came from.
>
> Ideas?
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.14/128 - Release Date: 10/10/2005
Re: [legal] Bulk contribution barrier to entry
Posted by Dalibor Topic <ro...@kaffe.org>.
Geir Magnusson Jr. wrote:
> The issue is "did those that write this have access to an
> implementation for which the owner of that implementation could claim
> an interest in our code if written by those people." For example,
> suppose some key Sun HotSpot people came to work on a JIT here....
They'd be welcome to, afaict, as long as they don't break their
contracts with Sun Microsystems, violate their employer's trade secrets,
and do other unreasonable things, which I'd assume noone would really
want to do anyway.
Since an outsider can hardly know what the employment contracts of Sun
Microsystems and a particular individual contain, it'd be hard for them
to make the call which behaviour is legally fine, and which is not.
There is no way the outsider can be completely sure that the other party
is not acting outside of their legal framework. Somewhere trust needs to
come into the game, since it is impossible to prove that a person has
not ever looked at proprietary source code, for example, with the
current state of neural technology. :)
I believe the problem you're trying to adress has to do with 'transitive
trust': we have to trust that all pieces of a contribution chain are
legally fine. One way to get the trust is to make sure that people sign
contribution agreements, where they state that they actually have the
right to contribute the code. One also needs to trust them that their
decisions are OK.
That's somewhat simple when people are contributing their own code
they've written without looking at proprietary implementations.
It can get nicely complicated for $BIGCORP , with different licensing
schemes for different proprietary source code bases, employee migration
between different teams etc.
Again, trust has to be somewhere in the process: you have to eventually
trust either the $BIGCORP that their contribution is fine, legally, or
to trust one step further, that the copyright holders of the proprietary
source code bases potentially used by $BIGCORP are fine with $BIGCORP's
ASL2.0 licensed contribution. I don't think there is a 100% certainity
to be achieved there, without essentially knowing everything about the
legal arrangements of $BIGCORP and copyright holders of proprietary
source code bases, who worked for whom when under which contracts, etc.
I think there are two ways to deal with that (hypothetical so far, since
no $BIGCORP has donated any code, afaik) situation:
a) trust $BIGCORP to know what they are doing, and remove their code if
they screw up. Trust that the proprietary copyright holders will speak
up when they see stuff hapenning that they have doubts about. Same
procedure as usual.
Pro: Stuff happens now. $BIGCORP has skilled legal staff that can figure
out their own contractual obligations best.
Con: Possible legal issues later, may have to pull sour code, if
$BIGCORP turns out to have screwed up.
b) Get $BIGCORP to get a document from proprietary copyright holders
that says that their contribution is not infringing, and trust
proprietary copyright holders on that. For example, Sun Microsystems has
been improving on one of their source code licenses to draw a clearer
line between infringing and non-infringing use of their code, so it may
be possible for $BIGCORP to get such a statement without too much fuss.
Pro: Proprietary copyright holders give their thumbs up for
contributions, making them safe from potential submarine issues.
Con: Gives proprietary copyright holders an effective veto over what
goes into the project. Proprietary copyright holders may have no
financial interest in digging through piles of third party code and old
contracts to figure out what's OK and what's not, so they may prefer a
laissez-faire approach until they are aware of an actual, provable
violation of their contracts.
I'd suggest going with a) and relying on the proprietary copyright
holders to know best how to protect their own interests, while relying
on contributing $BIGCORP to know best what their legal arrangements
allow them to do. If code turns out to be sour, it would be purged out
of subversion repo and rewritten. There is no shortage of good runtime
code out there, or people able to (re)write it.
Something unpredictable, bad and unlikely from an unrelated third party
can happen anyhow, anytime (WWIII, Microsoft starting nuclear software
patent winter, Star Wars VII).
cheers,
dalibor topic
Re: [legal] Bulk contribution barrier to entry
Posted by Dalibor Topic <ro...@kaffe.org>.
Richard Nienaber wrote:
> What are the implications in the following scenario:
>
> Person A contributes completely original code X
> Independent reviewer compares X code to copyrighted code Y from $BIGCORP and
> finds them extremely similar
>
> Now, I'm not saying that Person A was lying, they just solved the problem
> in the same way. Does that mean that Person A's contribution has to be
> scrapped and rewritten?
>
No, as long as the work is Person A's own work.
If, for example, the task at hand is to enumerate the letters of the
alphabet in the increasing order, x% of people would get the same
solution, without necessarily copying it from each other. There are only
so many ways to reasonably write a getter/setter pair in Java, for example.
For how blindly trusting 'independent reviewers' to detect copyright
infringement in similar code, without thinking really hard about the
issues involved (copyright law, scenes-a-faire, copyrightability, is my
code really my own, do we have any clue about the pedigree of the code
at hand) can be pretty harmful to a $BIGCORP's bottom line, see SCO vs.
The World. [1]
cheers,
dalibor topic
[1] http://perens.com/Articles/SCO/SCOSlideShow.html
Re: [legal] Bulk contribution barrier to entry
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 29, 2005, at 9:22 AM, Mark Wielaard wrote:
> Hi Geir,
>
> On Wed, 2005-10-12 at 10:11 -0400, Geir Magnusson Jr. wrote:
>
>> For example, create a new subclass of Exception that doesn't look
>> like ...
>>
>> public class FooException extends Exception {
>> public FooException() {
>> }
>>
>> public FooException(String message) {
>> super(message);
>> }
>>
>> public FooException(String message, Throwable cause) {
>> super(message, cause);
>> }
>>
>> public FooException(Throwable cause) {
>> super(cause);
>> }
>> }
>>
>> I've actually been in a situation where a lawyer flagged something
>> like this as a problem.
>>
>
> Yes, the problem your lawyer has is that if you say you studied an
> implementation of FooException from a proprietary implementation and
> then come up with a almost similar implementation you have
> something to
> explain in court if you ever end up in a lawsuit. You may still get
> away
> with it if you can proof that the implementation the only "obvious"
> way
> to implement that piece of code. But suddenly you are the person
> having
> to proof something. That is why projects like GNU Classpath have a
> rule
> that you cannot study any proprietary implementation. That makes such
> potential court cases a lot easier.
It's more subtle than that. It's isn't that you need to have seen
the other code before, the simple fact that it's the same as
something else would be a problem. Yes, it's much easier when a)
you've never seen the code and b) what you are looking at is the
"standard for the trade" way of doing things...
>
> You might also want to look at what Lawrence Rosen said about the
> problems with "Residual Rights" and looking at proprietary source code
> while working on a Free Software project. See for example his online
> book http://www.rosenlaw.com/oslbook.htm page 258 deals with the
> case of
> implementing 'competing' open source software after looking at
> 'Shared
> Source' code (in this case Microsoft code, but some of the SCSL, JRL,
> etc covered code released by Sun have similar issues)
>
>
>> "If you are a software developer who intends to write software that
>> might potentially compete with Microsoft's copyrights or patents,
>> there is great risk in looking at Microsoft's source code. Under the
>> copyright law in the United States, if Microsoft proves that there is
>> "substantial similarity" between your commercial software and theirs,
>> you may be an infringer. You may have to prove that you saw and read
>> Microsoft's source code but that you relied only on intangibles and
>> only on your memory when you wrote your own software.
>>
>> That's a difficult evidentiary burden. I'm not sure how even an
>> experienced programmer can walk that fine line. Perhaps the best way
>> is simply not to look at Microsoft's source code at all."
>>
>
I'm familiar with teh problem. That's why we've been talking to sun
about the JRL, and I think that progress has been made in the area of
Residual Rights.
> And of course there is the simple observation that we have been
> working
> for more then 20 years on Free Software now (just 10 for GNU
> Classpath,
> gcj and kaffe of course) without needing to look at any proprietary
> source code. Often producing better, more efficient, robust and
> cleaner
> code then any proprietary implementation. So why would we start now?
No one is suggesting you do :)
geir
>
> The GNU Classpath developer wiki has more explanations about this
> topic:
> http://developer.classpath.org/mediation/ClasspathFirstSteps
>
> 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/
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Bulk contribution barrier to entry
Posted by Mark Wielaard <ma...@klomp.org>.
Hi Geir,
On Wed, 2005-10-12 at 10:11 -0400, Geir Magnusson Jr. wrote:
> For example, create a new subclass of Exception that doesn't look
> like ...
>
> public class FooException extends Exception {
> public FooException() {
> }
>
> public FooException(String message) {
> super(message);
> }
>
> public FooException(String message, Throwable cause) {
> super(message, cause);
> }
>
> public FooException(Throwable cause) {
> super(cause);
> }
> }
>
> I've actually been in a situation where a lawyer flagged something
> like this as a problem.
Yes, the problem your lawyer has is that if you say you studied an
implementation of FooException from a proprietary implementation and
then come up with a almost similar implementation you have something to
explain in court if you ever end up in a lawsuit. You may still get away
with it if you can proof that the implementation the only "obvious" way
to implement that piece of code. But suddenly you are the person having
to proof something. That is why projects like GNU Classpath have a rule
that you cannot study any proprietary implementation. That makes such
potential court cases a lot easier.
You might also want to look at what Lawrence Rosen said about the
problems with "Residual Rights" and looking at proprietary source code
while working on a Free Software project. See for example his online
book http://www.rosenlaw.com/oslbook.htm page 258 deals with the case of
implementing 'competing' open source software after looking at 'Shared
Source' code (in this case Microsoft code, but some of the SCSL, JRL,
etc covered code released by Sun have similar issues):
> "If you are a software developer who intends to write software that
> might potentially compete with Microsoft's copyrights or patents,
> there is great risk in looking at Microsoft's source code. Under the
> copyright law in the United States, if Microsoft proves that there is
> "substantial similarity" between your commercial software and theirs,
> you may be an infringer. You may have to prove that you saw and read
> Microsoft's source code but that you relied only on intangibles and
> only on your memory when you wrote your own software.
>
> That's a difficult evidentiary burden. I'm not sure how even an
> experienced programmer can walk that fine line. Perhaps the best way
> is simply not to look at Microsoft's source code at all."
And of course there is the simple observation that we have been working
for more then 20 years on Free Software now (just 10 for GNU Classpath,
gcj and kaffe of course) without needing to look at any proprietary
source code. Often producing better, more efficient, robust and cleaner
code then any proprietary implementation. So why would we start now?
The GNU Classpath developer wiki has more explanations about this topic:
http://developer.classpath.org/mediation/ClasspathFirstSteps
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] Bulk contribution barrier to entry
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 12, 2005, at 2:59 AM, Richard Nienaber wrote:
> What are the implications in the following scenario:
>
> Person A contributes completely original code X
> Independent reviewer compares X code to copyrighted code Y from
> $BIGCORP and
> finds them extremely similar
I think it comes down to "how extremely". For some problems, there
is only one way to do things.
For example, create a new subclass of Exception that doesn't look
like ...
public class FooException extends Exception {
public FooException() {
}
public FooException(String message) {
super(message);
}
public FooException(String message, Throwable cause) {
super(message, cause);
}
public FooException(Throwable cause) {
super(cause);
}
}
I've actually been in a situation where a lawyer flagged something
like this as a problem.
So I think that if the implementation is the "obvious" way - the
canonical way a competent practitioner would do it - we're probably ok.
OTOH, it's still possible to do an independent implementation of
something that does violate copyright - if you independently
composed music that sounded just like Vertigo by U2, you'd have a
copyright problem.
So I think we'll just have to handle those cases if and when they arise.
geir
>
> Now, I'm not saying that Person A was lying, they just solved the
> problem
> in the same way. Does that mean that Person A's contribution has to be
> scrapped and rewritten?
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Bulk contribution barrier to entry
Posted by Richard Nienaber <rj...@gmail.com>.
What are the implications in the following scenario:
Person A contributes completely original code X
Independent reviewer compares X code to copyrighted code Y from $BIGCORP and
finds them extremely similar
Now, I'm not saying that Person A was lying, they just solved the problem
in the same way. Does that mean that Person A's contribution has to be
scrapped and rewritten?
Re: [legal] Bulk contribution barrier to entry
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 11, 2005, at 1:24 PM, Leo Simons wrote:
> On Tue, Oct 11, 2005 at 07:54:04AM -0400, Geir Magnusson Jr. wrote:
>
>>>> However, I suspect it will be too high of a standard. For example,
>>>> suppose the Kaffe project wanted to offer a copyright license to
>>>> their codebase to Harmony? I bet it can't be done - we'd have to
>>>> chase down every contributor to the codebase and get the signed
>>>> agreement. Suppose Sun wanted to donate J2SE? :) I'm betting
>>>> they
>>>> couldn't provide the necessary documentation either...
>>>>
>>>> So what do we do?
>>>>
>>>
>>> Just-in-time revise the process when the problem arrives?
>>>
>>
>> I thought of that at first, but worry that without some objective
>> starting point - some minimum set of guidelines - we'd either get
>> accused of playing favorites, or not be able to defend a minimum
>> provenance standard for our entire codebase.
>>
>
> OK. I think the minimum set of guidelines is "produce a compliant J2SE
> implementation which can be licensed under the Apache License only".
I think we're talking about two different things. Yes, that's
clearly the project goal.
The goal of the legal framework is to support that in a way that
people are sure of the code they get from us because we are taking
extra steps to ensure that bulk contributions from outside have some
pedigree check beyond "do you own the copyright".
All of what we setup is basically a set of questions to get people to
think about things we believe are important to letting our users be
comfortable with the pedigree of what we produce. What I'm saying is
that right now, the questions are such that for "innocent" cases,
people will have to answer no. I want to find a set of questions
that are a little more reasonable yet still gives us the same level
of comfort.
> We
> are being extra careful here because of that "only" that's in
> there. We
> are worried about patents 'n stuff, no?
We are worried about all sorts of things. Patents are one. Trade
secrets are another ("Bob worked on Sun's JIT while at Sun...").
Copyright is another - but one I believe we can mitigate through
automated surveillance comparing the codebase against others.
We'll never be 100% sure, but these steps we have no are fairly low
cost, and provide a fairly substantive base of information to help
support our pedigree.
>
> So the alternative to our established process is "anything which fits
> the original goal". I don't care one bit whether we'll get accused of
> stuff -- the fact that this project exists causes lots of
> accusations of
> various kinds.
>
>
>>> I know very little about any of this, but I'll suggest that
>>> designing
>>> ahead of need is not a good idea. If and when we run into problems
>>> with
>>> this process, we will know exactly what the problem actually is and
>>> what steps would fix that problem.
>>>
>>> Software developers will recognize this is as the "extreme
>>> programming"
>>> approach :-)
>>>
>>
>> Erm, yeah. Like I've said before, a little upfront design goes a
>> long way... There's reasons why people don't do XP for anything
>> material that has any permanence, like skyscrapers or roads or
>> airplanes..
>>
>
> really? From what I hear, they tend to start building an airplane
> even before they know how long or how heavy it will be. They just
> have some educated guesses (which, to be fair, fill like several
> thousand pages) and start building stuff. Fascinating. But very
> off-topic :-)
>
I find that hard to believe... we'll chat about this offline...
>
>> First, it's just too embarrassing and expensive to
>> refactor a skyscraper "windows? you never said anything about
>> windows...", and you want to make sure that you can meet the basic
>> design goals "What do you mean 'land'?"..
>>
>> We have a basic legal/process design goal of creating a body of work
>> for which we've taken reasonable care to ensure clean origins and no
>> encumbrance by 3rd parties.
>>
>> In our case, when we get contributions, they are in a sense building
>> blocks for our work here - depending on the technology, it could be
>> very difficult or expensive to go back later and fix, or ensure we
>> treat all comers fairly.
>>
>> Anyway, we don't have a problem now, but this struck me as a bug when
>> doing it, so lets at least think about this a bit and suggest some
>> possible yardsticks to use.
>>
>
> I don't see the actual bug yet.
>
> In any case, did the above make sense as a yardstick?
Well, no, at least not where I'm coming from. let me illustrate.
Right now, the question is :
"Can every author of the code you are contributing be considered an
"Authorized Contributor", meaning that they can sign our document and
assert they have had no exposure to implementations that either
weren't under an OSS license, or have the copyright owners permission
to work on other implementations?"
We've been lucky so far. For David, Archie and Daniel, they each
could say "yes", because each was the solo author.
Now suppose that Dalibor has the ability and desire to contribute the
Kaffe codebase. There's no way he could answer that question
affirmatively, because he can't go off and get all the ACQs. But
suppose there was project policy like ours that prevented
contributions in areas for which people had prior exposure.
(Classpath has this, sorta..) I'd be happy with that. So we could
have questions like :
1) Do you know the origin of all the source you are contributing?
2) Did any of the authors have access to another non-OSS
implementation within X years of authoring the contribution? If so,
did they contribute in areas for which they had access?
etc...
I'll need some more time to invent more questions...
So given the answers to questions like this, we as a project could
decide that we're willing to accept the codebase and be able to
defend our pedigree. I hope this makes things a tad clearer...
Sorry for the confusion...
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Bulk contribution barrier to entry
Posted by Leo Simons <ma...@leosimons.com>.
On Tue, Oct 11, 2005 at 07:54:04AM -0400, Geir Magnusson Jr. wrote:
> >>However, I suspect it will be too high of a standard. For example,
> >>suppose the Kaffe project wanted to offer a copyright license to
> >>their codebase to Harmony? I bet it can't be done - we'd have to
> >>chase down every contributor to the codebase and get the signed
> >>agreement. Suppose Sun wanted to donate J2SE? :) I'm betting they
> >>couldn't provide the necessary documentation either...
> >>
> >>So what do we do?
> >
> >Just-in-time revise the process when the problem arrives?
>
> I thought of that at first, but worry that without some objective
> starting point - some minimum set of guidelines - we'd either get
> accused of playing favorites, or not be able to defend a minimum
> provenance standard for our entire codebase.
OK. I think the minimum set of guidelines is "produce a compliant J2SE
implementation which can be licensed under the Apache License only". We
are being extra careful here because of that "only" that's in there. We
are worried about patents 'n stuff, no?
So the alternative to our established process is "anything which fits
the original goal". I don't care one bit whether we'll get accused of
stuff -- the fact that this project exists causes lots of accusations of
various kinds.
> >I know very little about any of this, but I'll suggest that designing
> >ahead of need is not a good idea. If and when we run into problems
> >with
> >this process, we will know exactly what the problem actually is and
> >what steps would fix that problem.
> >
> >Software developers will recognize this is as the "extreme
> >programming"
> >approach :-)
>
> Erm, yeah. Like I've said before, a little upfront design goes a
> long way... There's reasons why people don't do XP for anything
> material that has any permanence, like skyscrapers or roads or
> airplanes..
really? From what I hear, they tend to start building an airplane
even before they know how long or how heavy it will be. They just
have some educated guesses (which, to be fair, fill like several
thousand pages) and start building stuff. Fascinating. But very
off-topic :-)
> First, it's just too embarrassing and expensive to
> refactor a skyscraper "windows? you never said anything about
> windows...", and you want to make sure that you can meet the basic
> design goals "What do you mean 'land'?"..
>
> We have a basic legal/process design goal of creating a body of work
> for which we've taken reasonable care to ensure clean origins and no
> encumbrance by 3rd parties.
>
> In our case, when we get contributions, they are in a sense building
> blocks for our work here - depending on the technology, it could be
> very difficult or expensive to go back later and fix, or ensure we
> treat all comers fairly.
>
> Anyway, we don't have a problem now, but this struck me as a bug when
> doing it, so lets at least think about this a bit and suggest some
> possible yardsticks to use.
I don't see the actual bug yet.
In any case, did the above make sense as a yardstick?
cheers!
LSD
Re: [legal] Bulk contribution barrier to entry
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 11, 2005, at 5:10 AM, Leo Simons wrote:
> On Mon, Oct 10, 2005 at 06:08:20PM -0400, Geir Magnusson Jr. wrote:
>
>> See http://incubator.apache.org/harmony/
>> bulk_contribution_checklist.html Part III
>>
>> This is a very high standard,
>>
>
> I thought it was a checklist.
Yes.
>
>
>> However, I suspect it will be too high of a standard. For example,
>> suppose the Kaffe project wanted to offer a copyright license to
>> their codebase to Harmony? I bet it can't be done - we'd have to
>> chase down every contributor to the codebase and get the signed
>> agreement. Suppose Sun wanted to donate J2SE? :) I'm betting they
>> couldn't provide the necessary documentation either...
>>
>> So what do we do?
>>
>
> Just-in-time revise the process when the problem arrives?
I thought of that at first, but worry that without some objective
starting point - some minimum set of guidelines - we'd either get
accused of playing favorites, or not be able to defend a minimum
provenance standard for our entire codebase.
>
> They check the appropriate checkboxes. For example, Sun donating J2SE
> would check the box "no" and then provide details along
> the lines of
>
> "authors are sun employees."
>
> "attached is a list of sun's employees over the last 10 years who we
> believe have worked on this contribution. Also attached is a list of
> companies which we have agreement such and so forth with."
>
> Now, if and when Sun states that they want to contribute something
> for which they can't fill in the template, we create a new one (its
> versioned isn't it) which they can fill in.
>
Right - the issue isn't "who wrote this" - we assume that if Sun or
any company brings us code and says "we have the right to donate
this" we simply take them at their word as expressed by the Software
Grant or CCLA. That's the easy part, and what we already do today.
No problem there.
The issue is "did those that write this have access to an
implementation for which the owner of that implementation could claim
an interest in our code if written by those people." For example,
suppose some key Sun HotSpot people came to work on a JIT here....
Now, Sun is a terrible example, because our chief worry is that
someone was exposed to Sun code in a way that creates problems for
us, and if Sun is donating the code this chief worry goes away.
Choose another company - like my employer, IBM, or BEA or Apple or
Nokia - all are Sun code licensees - and if not, have their own code
that they've written....
>
>> We need to balance a few things:
>>
>> 1) Make this flexible enough that the project can choose to accept
>> software for which ACQs aren't obtainable from all authors.
>> 2) Make this strong enough that we don't put the project at
>> unreasonable risk, and that the consumers of the software have
>> confidence that the codebase is clean.
>>
>> Suggestions? One possibility is that for those that can't satisfy
>> the status quo framework, we have a set of questions that allow us to
>> understand the source of the code and the manner in which it was
>> developed. We'd like this to be somewhat objective yet still give
>> the project room to reject if it doesn't "feel right", we want the
>> process used and information obtained to be available to the public
>> so that any interested consumer of our software can understand where
>> it came from.
>>
>> Ideas?
>>
>
> We'll have to change other bits of process too. If sun contributes
> J2SE
> I doubt we'll want to make all J2SE developers at sun, past and
> present,
> committers to the project. That's gotta be lots of people!
:)
No - it's not about committers either, but about the contributed
sourcebase.
>
> I know very little about any of this, but I'll suggest that designing
> ahead of need is not a good idea. If and when we run into problems
> with
> this process, we will know exactly what the problem actually is and
> what steps would fix that problem.
>
> Software developers will recognize this is as the "extreme
> programming"
> approach :-)
Erm, yeah. Like I've said before, a little upfront design goes a
long way... There's reasons why people don't do XP for anything
material that has any permanence, like skyscrapers or roads or
airplanes.. First, it's just too embarrassing and expensive to
refactor a skyscraper "windows? you never said anything about
windows...", and you want to make sure that you can meet the basic
design goals "What do you mean 'land'?"..
We have a basic legal/process design goal of creating a body of work
for which we've taken reasonable care to ensure clean origins and no
encumbrance by 3rd parties.
In our case, when we get contributions, they are in a sense building
blocks for our work here - depending on the technology, it could be
very difficult or expensive to go back later and fix, or ensure we
treat all comers fairly.
Anyway, we don't have a problem now, but this struck me as a bug when
doing it, so lets at least think about this a bit and suggest some
possible yardsticks to use.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Bulk contribution barrier to entry
Posted by Leo Simons <ma...@leosimons.com>.
On Mon, Oct 10, 2005 at 06:08:20PM -0400, Geir Magnusson Jr. wrote:
> See http://incubator.apache.org/harmony/
> bulk_contribution_checklist.html Part III
>
> This is a very high standard,
I thought it was a checklist.
> However, I suspect it will be too high of a standard. For example,
> suppose the Kaffe project wanted to offer a copyright license to
> their codebase to Harmony? I bet it can't be done - we'd have to
> chase down every contributor to the codebase and get the signed
> agreement. Suppose Sun wanted to donate J2SE? :) I'm betting they
> couldn't provide the necessary documentation either...
>
> So what do we do?
Just-in-time revise the process when the problem arrives?
They check the appropriate checkboxes. For example, Sun donating J2SE
would check the box "no" and then provide details along
the lines of
"authors are sun employees."
"attached is a list of sun's employees over the last 10 years who we
believe have worked on this contribution. Also attached is a list of
companies which we have agreement such and so forth with."
Now, if and when Sun states that they want to contribute something
for which they can't fill in the template, we create a new one (its
versioned isn't it) which they can fill in.
> We need to balance a few things:
>
> 1) Make this flexible enough that the project can choose to accept
> software for which ACQs aren't obtainable from all authors.
> 2) Make this strong enough that we don't put the project at
> unreasonable risk, and that the consumers of the software have
> confidence that the codebase is clean.
>
> Suggestions? One possibility is that for those that can't satisfy
> the status quo framework, we have a set of questions that allow us to
> understand the source of the code and the manner in which it was
> developed. We'd like this to be somewhat objective yet still give
> the project room to reject if it doesn't "feel right", we want the
> process used and information obtained to be available to the public
> so that any interested consumer of our software can understand where
> it came from.
>
> Ideas?
We'll have to change other bits of process too. If sun contributes J2SE
I doubt we'll want to make all J2SE developers at sun, past and present,
committers to the project. That's gotta be lots of people!
I know very little about any of this, but I'll suggest that designing
ahead of need is not a good idea. If and when we run into problems with
this process, we will know exactly what the problem actually is and
what steps would fix that problem.
Software developers will recognize this is as the "extreme programming"
approach :-)
LSD
Re: [legal] Bulk contribution barrier to entry
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 10, 2005, at 6:17 PM, Danese Cooper wrote:
> Geir,
>
> This is a special requirement of Harmony?
Yes.
> Certainly there are plenty of Apache contributions in bulk for
> which that wasn't the case (TomCat to name one) or where you
> aggregating "authorship" to Sun in that case?
Yes - we are trying to go an extra step when it comes to harmony,
because there are multiple implementations of the exact same thing
out there that aren't under open source licenses, so we wish to be
sure to protect both those holders of IP, as well as ourselves and
our users/licensees.
geir
>
> Danese
>
> On Oct 10, 2005, at 3:08 PM, Geir Magnusson Jr. wrote:
>
>
>> We've now accepted three contributions so far, and I think we have
>> a small problem that isn't easy to solve.
>>
>> The problem is that for a bulk contribution - something created
>> elsewhere and being contributed to harmony - we require that all
>> authors of that work are Authorized Contributors, meaning that
>> they hadn't been exposed to implementations of Java that weren't
>> either available under an open source license, or were owned by an
>> entity willing to give the author permission to work on other
>> implementations elsewhere.
>>
>> See http://incubator.apache.org/harmony/
>> bulk_contribution_checklist.html Part III
>>
>> This is a very high standard, one that helps ensure clean IP
>> provenance for our codebase.
>>
>> However, I suspect it will be too high of a standard. For
>> example, suppose the Kaffe project wanted to offer a copyright
>> license to their codebase to Harmony? I bet it can't be done -
>> we'd have to chase down every contributor to the codebase and get
>> the signed agreement. Suppose Sun wanted to donate J2SE? :) I'm
>> betting they couldn't provide the necessary documentation either...
>>
>> So what do we do?
>>
>> We need to balance a few things:
>>
>> 1) Make this flexible enough that the project can choose to accept
>> software for which ACQs aren't obtainable from all authors.
>> 2) Make this strong enough that we don't put the project at
>> unreasonable risk, and that the consumers of the software have
>> confidence that the codebase is clean.
>>
>> Suggestions? One possibility is that for those that can't satisfy
>> the status quo framework, we have a set of questions that allow us
>> to understand the source of the code and the manner in which it
>> was developed. We'd like this to be somewhat objective yet still
>> give the project room to reject if it doesn't "feel right", we
>> want the process used and information obtained to be available to
>> the public so that any interested consumer of our software can
>> understand where it came from.
>>
>> Ideas?
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Bulk contribution barrier to entry
Posted by Danese Cooper <da...@gmail.com>.
Geir,
This is a special requirement of Harmony? Certainly there are plenty
of Apache contributions in bulk for which that wasn't the case
(TomCat to name one) or where you aggregating "authorship" to Sun in
that case?
Danese
On Oct 10, 2005, at 3:08 PM, Geir Magnusson Jr. wrote:
> We've now accepted three contributions so far, and I think we have
> a small problem that isn't easy to solve.
>
> The problem is that for a bulk contribution - something created
> elsewhere and being contributed to harmony - we require that all
> authors of that work are Authorized Contributors, meaning that they
> hadn't been exposed to implementations of Java that weren't either
> available under an open source license, or were owned by an entity
> willing to give the author permission to work on other
> implementations elsewhere.
>
> See http://incubator.apache.org/harmony/
> bulk_contribution_checklist.html Part III
>
> This is a very high standard, one that helps ensure clean IP
> provenance for our codebase.
>
> However, I suspect it will be too high of a standard. For example,
> suppose the Kaffe project wanted to offer a copyright license to
> their codebase to Harmony? I bet it can't be done - we'd have to
> chase down every contributor to the codebase and get the signed
> agreement. Suppose Sun wanted to donate J2SE? :) I'm betting
> they couldn't provide the necessary documentation either...
>
> So what do we do?
>
> We need to balance a few things:
>
> 1) Make this flexible enough that the project can choose to accept
> software for which ACQs aren't obtainable from all authors.
> 2) Make this strong enough that we don't put the project at
> unreasonable risk, and that the consumers of the software have
> confidence that the codebase is clean.
>
> Suggestions? One possibility is that for those that can't satisfy
> the status quo framework, we have a set of questions that allow us
> to understand the source of the code and the manner in which it was
> developed. We'd like this to be somewhat objective yet still give
> the project room to reject if it doesn't "feel right", we want the
> process used and information obtained to be available to the public
> so that any interested consumer of our software can understand
> where it came from.
>
> Ideas?
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: [legal] Bulk contribution barrier to entry
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Oct 11, 2005, at 8:26 AM, Dalibor Topic wrote:
> Geir Magnusson Jr. wrote:
>
>> We've now accepted three contributions so far, and I think we have a
>> small problem that isn't easy to solve.
>>
>> The problem is that for a bulk contribution - something created
>> elsewhere and being contributed to harmony - we require that all
>> authors of that work are Authorized Contributors, meaning that they
>> hadn't been exposed to implementations of Java that weren't either
>> available under an open source license, or were owned by an entity
>> willing to give the author permission to work on other
>> implementations
>> elsewhere.
>>
>> See http://incubator.apache.org/harmony/
>> bulk_contribution_checklist.html Part III
>>
>> This is a very high standard, one that helps ensure clean IP
>> provenance
>> for our codebase.
>>
>> However, I suspect it will be too high of a standard. For example,
>> suppose the Kaffe project wanted to offer a copyright license to
>> their
>> codebase to Harmony? I bet it can't be done - we'd have to chase
>> down
>> every contributor to the codebase and get the signed agreement.
>>
>
> It couldn't be done since there is no legal entity representing the
> Kaffe project that could make such offers. :)
>
> You'd have to track down the actual contributors, and get a signed
> agreement.
Exactly why I think that we need to consider alternatives.
geir
>
> cheers,
> dalibor topic
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [legal] Bulk contribution barrier to entry
Posted by Dalibor Topic <ro...@kaffe.org>.
Geir Magnusson Jr. wrote:
> We've now accepted three contributions so far, and I think we have a
> small problem that isn't easy to solve.
>
> The problem is that for a bulk contribution - something created
> elsewhere and being contributed to harmony - we require that all
> authors of that work are Authorized Contributors, meaning that they
> hadn't been exposed to implementations of Java that weren't either
> available under an open source license, or were owned by an entity
> willing to give the author permission to work on other implementations
> elsewhere.
>
> See http://incubator.apache.org/harmony/
> bulk_contribution_checklist.html Part III
>
> This is a very high standard, one that helps ensure clean IP provenance
> for our codebase.
>
> However, I suspect it will be too high of a standard. For example,
> suppose the Kaffe project wanted to offer a copyright license to their
> codebase to Harmony? I bet it can't be done - we'd have to chase down
> every contributor to the codebase and get the signed agreement.
It couldn't be done since there is no legal entity representing the
Kaffe project that could make such offers. :)
You'd have to track down the actual contributors, and get a signed
agreement.
cheers,
dalibor topic