You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Davanum Srinivas <da...@gmail.com> on 2005/05/10 20:29:24 UTC
Problems/Issues/Questions
Or as my wife would say opportunities :) Please be gentle. Not trying
to start a flame war. Just trying to draw out practial matters.
Facts:
- GNU Classpath is *NOT* GPL. It uses GPL+Exception
(http://www.gnu.org/software/classpath/license.html)
- FSF owns copyright for GNU Classpath
(example see http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/classpath/classpath/java/lang/Object.java?rev=HEAD&content-type=text/plain)
- The Exception clause was a joint effort with RedHat
(as explained by Anthony -
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/%3c1115497520.4768.218.camel@localhost.localdomain%3e)
- Any ASF contributor if they want to make changes to CLASSPATH, will
have to adhere to the clean room clauses
(http://www.gnu.org/software/classpath/faq/faq.html#faq3_2)
- For any contributions to classpath there has to be a copyright
assignment to the FSF. ASF does not ask for copyright assignment by default
as explained by Sam in a previous thread.
(http://www.gnu.org/software/classpath/faq/faq.html#faq3_4)
(http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/%3c427D2A2C.9050905@apache.org%3e)
Issues and possible solutions:
- Any source code or Jars under GPL cannot be checked into ASF CVS.
One possibility is for FSF folks to publish maven snapshots of
the daily build.
- Need to check if the classpath jars can be part of a install package
from ASF Legal folks. Problem is we don't want users do download two
things from two places to get a working JDK/JRE. One solution is the
shared classpath instance model where many VM's share the same
classpath jar. this may reduce the problem, but not an ideal solution.
- Classpath was once LGPL, but ASF/FSF still needs to resolve issues
around it, so even that may not be open for the short-term.
- It may or may not be very difficult to add/change the Exception clause
to make it easier to develop/ship/use code. Need ASF legal and FSF
legal folks to chime in. Ideally if we change the exception clause to
convey the information in say the MIT license
(http://www.opensource.org/licenses/mit-license.php). That would make
it REAL easy. But i know it's probably too much to ask for :) Note
that the two problems above will vanish if it happens.
Question from the point of view of a potential user of Harmony:
- Same question i asked for Geronimo...A specific product in my company
needs Java's, currently we ship JVM from [SUNW/IBM] by default. This
product is NOT positioned as a JVM/JRE engine and NO claims of Java
compliance is made. We want use Harmony+Classpath as the default JVM for
our product. We will comply with ALL requirements of ASL 2.0 under
which Harmony is licensed. We DON'T want to talk to SUN/ASF/FSF or pay
them any money (we don't pay SUNW now!!), we DON'T want to run the TCK's
before we ship the product. We just want to use Harmony as-is BUT we'd
like to issue some patches to our customers if necessary for product
support. What are my additional obligations because of Classpath
which is the default library in Harmony? (ones that are not applicable
to other ASF projects)
Thanks,
dims
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Problems/Issues/Questions
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
> Facts:
> - GNU Classpath is *NOT* GPL. It uses GPL+Exception
> (http://www.gnu.org/software/classpath/license.html)
> - FSF owns copyright for GNU Classpath
> (example see http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/classpath/classpath/java/lang/Object.java?rev=HEAD&content-type=text/plain)
> - The Exception clause was a joint effort with RedHat
> (as explained by Anthony -
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/%3c1115497520.4768.218.camel@localhost.localdomain%3e)
Later updated/clarified a bit for the SableVM hackers so we could also
accept their contributions.
> - Any ASF contributor if they want to make changes to CLASSPATH, will
> have to adhere to the clean room clauses
> (http://www.gnu.org/software/classpath/faq/faq.html#faq3_2)
I updated that FAQ entry just now. Hopefully it is much clearer about
what the ideas behind the rules are. I think it says the same thing as
what the Harmony proposal actually says: "Be careful, please".
> - For any contributions to classpath there has to be a copyright
> assignment to the FSF. ASF does not ask for copyright assignment by default
> as explained by Sam in a previous thread.
> (http://www.gnu.org/software/classpath/faq/faq.html#faq3_4)
> (http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/%3c427D2A2C.9050905@apache.org%3e)
The paperwork, assignment, company disclaimer, isn't that different from
the current Apache paperwork. And the intention behind it is the same.
Also note that in the case of the FSF paperwork it is a two-way
contract. You promise that you are entitled to contribute, the FSF
promises you to grand back your rights to your contributions and that
the FSF or any successor of the the FSF will always distribute your work
or derivatives under free terms.
> Issues and possible solutions:
> - Any source code or Jars under GPL cannot be checked into ASF CVS.
> One possibility is for FSF folks to publish maven snapshots of
> the daily build.
The only parts of GNU Classpath that are under the GPL are the tools,
which are currently distributed separated from a separate CVS module.
And the GNU Classpath Examples, which we could split off into their own
module if that makes people happy.
I don't know what maven snapshots are, but we can certainly create and
distribute daily snapshots. The FSF doesn't distribute binaries though,
only source archives.
> - Need to check if the classpath jars can be part of a install package
> from ASF Legal folks. Problem is we don't want users do download two
> things from two places to get a working JDK/JRE. One solution is the
> shared classpath instance model where many VM's share the same
> classpath jar. this may reduce the problem, but not an ideal solution.
> - Classpath was once LGPL, but ASF/FSF still needs to resolve issues
> around it, so even that may not be open for the short-term.
> - It may or may not be very difficult to add/change the Exception clause
> to make it easier to develop/ship/use code. Need ASF legal and FSF
> legal folks to chime in.
Is there any issue with the exception statement? I was under the
impression that it was fine. How would those issues be resolved by
distributing under the LGPL?
> Question from the point of view of a potential user of Harmony:
> - Same question i asked for Geronimo...A specific product in my company
> needs Java's, currently we ship JVM from [SUNW/IBM] by default.
Little nitpick. If you need Java (tm) then we (FSF/ASF/Harmony)
currently don't offer you that. We do have gcj, GNU Classpath and Kaffe,
but none of them claim to be Java.
> This
> product is NOT positioned as a JVM/JRE engine and NO claims of Java
> compliance is made. We want use Harmony+Classpath as the default JVM for
> our product. We will comply with ALL requirements of ASL 2.0 under
> which Harmony is licensed. We DON'T want to talk to SUN/ASF/FSF or pay
> them any money (we don't pay SUNW now!!), we DON'T want to run the TCK's
> before we ship the product. We just want to use Harmony as-is BUT we'd
> like to issue some patches to our customers if necessary for product
> support. What are my additional obligations because of Classpath
> which is the default library in Harmony?
Assuming that the whole stack is Free Software I think there is no
problem at all with this scenario.
> (ones that are not applicable to other ASF projects)
You might want to explain this if you want this to be a more formal
question for FSF legal.
Cheers,
Mark
Re: Problems/Issues/Questions
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 10, 2005, at 2:29 PM, Davanum Srinivas wrote:
[snip]
>
> Issues and possible solutions:
> - Any source code or Jars under GPL cannot be checked into ASF CVS.
> One possibility is for FSF folks to publish maven snapshots of
> the daily build.
Yes - that would solve things for now and get us going to get things
working
> - Need to check if the classpath jars can be part of a install package
> from ASF Legal folks. Problem is we don't want users do download two
> things from two places to get a working JDK/JRE. One solution is the
> shared classpath instance model where many VM's share the same
> classpath jar. this may reduce the problem, but not an ideal
> solution.
This is something to work on, but not critical to solve now.
[snip]
>
> Question from the point of view of a potential user of Harmony:
> - Same question i asked for Geronimo...A specific product in my
> company
> needs Java's, currently we ship JVM from [SUNW/IBM] by default. This
> product is NOT positioned as a JVM/JRE engine and NO claims of Java
> compliance is made. We want use Harmony+Classpath as the default
> JVM for
> our product. We will comply with ALL requirements of ASL 2.0 under
> which Harmony is licensed. We DON'T want to talk to SUN/ASF/FSF or pay
> them any money (we don't pay SUNW now!!), we DON'T want to run the
> TCK's
> before we ship the product. We just want to use Harmony as-is BUT we'd
> like to issue some patches to our customers if necessary for product
> support. What are my additional obligations because of Classpath
> which is the default library in Harmony? (ones that are not applicable
> to other ASF projects)
I think you are going to get into some trouble. What bothers me is
if you claim that such product runs on Java, and I can add Java code
to run in the product, I'm going to expect Java. I don't know what
Harmony + Classpath is unless it's certified via the TCK.
I think that we want to do a few things :
a) Make sure that we make certified Harmony (+ whatever
dependencies...) easy for people to bundle in the way you want to,
while still being Java. I think that is what the entire community
(including SUNW) wants - more compatible Java.
b) Encourage people that need to make derivative works and call them
Java to certify those derivative works. This also is good for the
Java universe.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Problems/Issues/Questions
Posted by Mark Wielaard <ma...@klomp.org>.
Hi,
On Tue, 2005-05-10 at 17:05 -0700, Anthony Green wrote:
> On Tue, 2005-05-10 at 14:29 -0400, Davanum Srinivas wrote:
> > - Any ASF contributor if they want to make changes to CLASSPATH, will
> > have to adhere to the clean room clauses
> > (http://www.gnu.org/software/classpath/faq/faq.html#faq3_2)
>
> I think this is worth pushing on a little if there is some interest.
> AFAIK, this was just a policy to minimize and risk of being called
> thieves, and is not central to the FSF's position on Free Software.
> Perhaps they may be convinced to tweak this policy a little if it makes
> sense.
As noted above I have updated the answer based on input from FSF legal a
while ago. There is even more information available at:
http://developer.classpath.org/mediation/ClasspathFirstSteps
> For example, Sun's Java Research License FAQ reads:
>
> "18. Does the JRL prevent you from being able to create an independent
> implementation of J2SE?
>
> The JRL is not a tainting license, and includes an express "residual
> knowledge" clause. Under the JRL, merely looking at Sun's code does not
> prevent you from being able to create your own independent
> implementation of J2SE, and in any event, you can terminate the JRL at
> any time for any reason. So, yes, you can look at Sun source code and
> then later on go and work on an open-source J2SE implementation."
>
> Somebody (mjw?) should run this past FSF legal.
I'll forward this to FSF legal, but in general we advise people not to
enter into contracts that potentially could result in tricky legal
issues in the future. Also normally FSF legal doesn't really want,
doesn't have the time, to go into all hypothetical scenarios. In general
we solve potential legal issues if there is a real need. So when someone
explicitly wants to enter into such a gated community contract and
actually has a real contribution that they want to contribute to GNU
Classpath.
The following doesn't come from FSF Legal, but is the advise given by
Lawrence Rosen. He made an analysis of the problems with Residual Rights
clauses in proprietary software from an attorney, check out Larry
Rosen's 'Open Source Licensing' book, also available online at
http://www.rosenlaw.com/oslbook.htm .
In chapter 11, Rosen deals with a nearly identical Residual Rights
clause from Microsoft's 'Shared Source' initiative (p. 257):
" You may use any information in intangible form that you re-
member after accessing the Software. However, this right
does not grant you a license to any of Microsoft's copyrights
or patents for anything you might create using such informa-
tion. (Microsoft Shared Source CLI, C#, and JSCRIPT
License.)"
p.258 continues to explicitely deal with the case of implementing
'competing' open source software after looking at 'Shared Source' code:
"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."
(Thanks to Dalibor for that link and text btw.)
Cheers,
Mark
Re: Problems/Issues/Questions
Posted by Anthony Green <gr...@redhat.com>.
On Tue, 2005-05-10 at 14:29 -0400, Davanum Srinivas wrote:
> - Any ASF contributor if they want to make changes to CLASSPATH, will
> have to adhere to the clean room clauses
> (http://www.gnu.org/software/classpath/faq/faq.html#faq3_2)
I think this is worth pushing on a little if there is some interest.
AFAIK, this was just a policy to minimize and risk of being called
thieves, and is not central to the FSF's position on Free Software.
Perhaps they may be convinced to tweak this policy a little if it makes
sense.
For example, Sun's Java Research License FAQ reads:
"18. Does the JRL prevent you from being able to create an independent
implementation of J2SE?
The JRL is not a tainting license, and includes an express "residual
knowledge" clause. Under the JRL, merely looking at Sun's code does not
prevent you from being able to create your own independent
implementation of J2SE, and in any event, you can terminate the JRL at
any time for any reason. So, yes, you can look at Sun source code and
then later on go and work on an open-source J2SE implementation."
Somebody (mjw?) should run this past FSF legal.
> Issues and possible solutions:
> - Any source code or Jars under GPL cannot be checked into ASF CVS.
> One possibility is for FSF folks to publish maven snapshots of
> the daily build.
Just out of curiosity, why is this? Would this apply to code licensed
under the current GNU Classpath license?
> - Need to check if the classpath jars can be part of a install package
> from ASF Legal folks. Problem is we don't want users do download two
> things from two places to get a working JDK/JRE. One solution is the
> shared classpath instance model where many VM's share the same
> classpath jar. this may reduce the problem, but not an ideal solution.
Having to go two places means something is busted. Hopefully this won't
be a problem. I would be surprised if it was.
> - Classpath was once LGPL, but ASF/FSF still needs to resolve issues
> around it, so even that may not be open for the short-term.
What does the LGPL have to do with GNU Classpath, and this effort now?
> - It may or may not be very difficult to add/change the Exception clause
> to make it easier to develop/ship/use code. Need ASF legal and FSF
> legal folks to chime in. Ideally if we change the exception clause to
> convey the information in say the MIT license
> (http://www.opensource.org/licenses/mit-license.php). That would make
> it REAL easy. But i know it's probably too much to ask for :) Note
> that the two problems above will vanish if it happens.
I can't speak for the FSF (or Red Hat) but as I see it, the problem with
the MIT license is that it doesn't preserve the central freedoms of the
code (as defined by the FSF). Somebody could modify it and not share
changes. A specific example of something I don't want to see is a
proprietary J2ME fork of our work. The point of the protective
properties of the GNU Classpath license is to prevent nonsense like
this. If somebody is going to make a J2ME fork of our hard work then we
should all benefit from this effort (this really speaks to the main
split between the Free Software and Open Source movements. The Free
Software movement focuses on the social benefits of having a community
around code, whereas the Open Source movement focuses on the practical
benefits).
> Question from the point of view of a potential user of Harmony:
I think it's important to distinguish between those "users" running
Harmony and those distributing Harmony. The point of the GNU Free
Software licenses is that you are free to run and modify code any way
you like, with few (if any?) restrictions. The user in your example
below is really a distributor of Harmony. This is where the protective
aspects of the GNU licenses steps in.
> - Same question i asked for Geronimo...A specific product in my company
> needs Java's, currently we ship JVM from [SUNW/IBM] by default. This
> product is NOT positioned as a JVM/JRE engine and NO claims of Java
> compliance is made. We want use Harmony+Classpath as the default JVM for
> our product. We will comply with ALL requirements of ASL 2.0 under
> which Harmony is licensed. We DON'T want to talk to SUN/ASF/FSF or pay
> them any money (we don't pay SUNW now!!), we DON'T want to run the TCK's
> before we ship the product. We just want to use Harmony as-is BUT we'd
> like to issue some patches to our customers if necessary for product
> support. What are my additional obligations because of Classpath
> which is the default library in Harmony? (ones that are not applicable
> to other ASF projects)
In the end it boils down to the following: source must follow binaries.
If you distribute binaries of GNU Classpath code, then source must also
be made available to that end user.
One interpretation of this is that if you distribute a "Harmony JRE"
binary release unmodified from one produced and archived by the ASF,
then this really shouldn't be much of an extra burden.
BTW, I'll point out that in the case of the JDK, my understanding is
that library source availability is an _expectation_ from current
commercial JRE users (bundled in something like src.zip, which is often
grokked by IDE tools).
Just a couple of other random comments:
----------------------------------------------------------------
Somebody recently asked me if what we really need is an LGPL specific to
Java. The danger here, as I see it, is that there will be a temptation
to draft this license in terms of what you can do with bytecode and jar
files. But there are other ways to build and distribute java code (for
instance, as native executables as produced by the gcj compiler).
Also, the point of the current license was to eliminate various
requirements in the LGPL (like the clause requiring that end users be
able to relink code after replacing the LGPL'd component).
----------------------------------------------------------------
Somebody on IRC recently distinguished between between the MIT and GNU
licenses by saying that GNU licenses force you to "give your changes
back". This isn't quite true. It's more accurate to say that the GNU
licenses ask you to give your changes "forward". Some software licenses
require that you send mods back to the original authors, but the GNU
licenses don't say this. The GNU licenses say that you are free not to
send your changes back to the original authors. And if you make changes
to GNU code for your own internal use, then you're free to do that
without sending any changes anywhere, or even telling anybody about
them.
AG