JSR166+backport: Licensing Issues

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

JSR166+backport: Licensing Issues

gnu_andrew
Hi all,

Some of you may be aware of the GNU Classpath project
(http://www.gnu.org/software/classpath), which aims to produce a Free
cleanroom implementation of the core class libraries.  Given the recent
addition of the concurrency classes to the 1.5 API, this is obviously
something we need to include at some point to produce a complete
implementation.

The availability of these classes within the public domain is thus
beneficial to us, as it should hopefully allow their inclusion without
the need to produce our own versions of this code.  Instead, we should
hopefully be able to include the public domain code in later releases.

In reviewing previous posts, there seems to have been some confusion
over the licensing of these files, and, as a result, we were hopeful
that you may be able to clarify the license of the files within both the
JSR166 package and the backport to 1.4.  As is currently understood, it
appears that most files are public domain save the following:

* java.util.concurrent.CopyOnWriteArrayList, which is under a Sun
license.
* Various java.util classes (e.g. AbstractMap, Collections, TreeMap),
which, at a guess, are taken from earlier Sun releases, and which we
already have implementations of.

We would be grateful if you could clarify this with us, so as to avoid
any later confusion.

Thanks in advance for any help you can give, and again for making these
classes available to us,
--
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman

Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JSR166+backport: Licensing Issues

Doug Lea
Andrew John Hughes wrote:
>
>
> We would be grateful if you could clarify this with us, so as to avoid
> any later confusion.
>


There's a simple, universally valid rule you can use for JSR166 files
as they appear in CVS:
For any file of interest, do "head -5 <filename>".
It will either clearly say that it is released to the public domain or
it won't. Nearly all are.

But especially during release integration, our CVS contains not only
files originated by us, but also other files that are modified by us.
We do this to make sure that everything goes into a release exactly
right, which is more important to us than maintaining license purity.

This rule is better than an enumeration, since the actual files
might change over time.

(BTW, our diffs to files not originated by us are also
released to the public domain, but they might not be
very useful.)

-Doug




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR166+backport: Licensing Issues

Dawid Kurzyniec
In reply to this post by gnu_andrew
Andrew John Hughes wrote:

>(...)
>We would be grateful if you could clarify this with us, so as to avoid
>any later confusion.
>
>  
>
As far as the backport is considered, there are two versions currently
available:

* public domain version. All files are public domain, except portions of
CopyOnWriteArrayList, which is adapted from SUN code and is subject to
terms described in file "LEGAL" in the distribution (basically, the file
can be freely redistributed; the only SUN restrictions are: it is
prohibited to use SUN trademarks to endorse derived products, and to use
the software in nuclear facilities). If these terms prove to be
incompatible with GPL, I guess the ClassPath folks will need to write a
clean-room implementation of COWArrayList.

* default version. In addition to the above, it contains 4 collection
classes from java.util that are subject to SUN license. They include new
functionality of collection classes that was introduced in Java 5.0 and
later (e.g. TreeMap implementing NavigableMap etc.)

Regards,
Dawid Kurzyniec

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR166+backport: Licensing Issues

Alexander Terekhov-2

> incompatible with GPL

Somewhere in the cyberspace (Shlomi Fish on Monday April 01).

----
A recent press conference of the Free Software Foundation confirmed
the rumors that the GNU General Public License was found to be
incompatible with itself. This newly discovered fact may actually
cause a lot of disorder in the free software world in which most
programs and libraries are licensed under this license.

Richard Stallman, chairman of the FSF, called upon developers to
immediately exempt GPL-licensed software from the GPL, as far as
linking them with GPL programs is concerned. "We have already made
sure all GNU software and every other software that is licensed to
the Free Software Foundation would be ad-hoc compatible with itself.
However we need other developers to do the same for their software",
Stallman said.

Eben Moglen, the FSF's attorney outlined the subsequent steps that
his organization will take to overcome this crisis. The first step
would be releasing a Modified General Public License (or MGPL for
short) that will be compatible with the GPL and with itself as well
as with all other licenses that the GPL is already compatible with.
It will be labeled the GPL version 2.1, thus allowing developers to
convert their software to it. He noted that care would be taken to
make sure the upcoming GPL version 3.0 will be compatible with
itself, as well as the MGPL.

For the time being, though, there is an explosion of commentary,
confusion and otherwise bad temper about the newly formed situation.
Eric S. Raymond, the famous Open Source Guru notes: "This is one of
the greatest blows to the Open Source world, I have yet encountered.
I have already exempted all of my own software from the GPL in this
regard, but there is a lot of other software out there, and many of
its authors are not very communicative.

Bill Gates, Microsoft's co-founder, on the other hand, seems to
find the situation very amusing: "I said times and again, that
viral licenses such as the GPL are a bad idea, and many open-source
advocates disagreed. Now they see that even making sure one's
license is compatible with itself, is hard to do when you open that
can of worms."

The integrity of many software projects whose license is the GPL and
yet contain works licensed by several developers is in jeopardy. The
Linux kernel is a prominent example of such a case. In a post to its
mailing list, Linus Torvalds commented that, in their case, it was
not an issue. "My interpretation of the GPL is already quite unusual,
so I'll simply rule that I also interpret the GPL as compatible with
itself."
----

Sorry, I just could not resist.

regards,
alexander.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JSR166+backport: Licensing Issues

gnu_andrew
In reply to this post by Doug Lea
On Wed, 2005-09-14 at 18:49 -0400, Doug Lea wrote:

> Andrew John Hughes wrote:
> >
> >
> > We would be grateful if you could clarify this with us, so as to avoid
> > any later confusion.
> >
>
>
> There's a simple, universally valid rule you can use for JSR166 files
> as they appear in CVS:
> For any file of interest, do "head -5 <filename>".
> It will either clearly say that it is released to the public domain or
> it won't. Nearly all are.
>
> But especially during release integration, our CVS contains not only
> files originated by us, but also other files that are modified by us.
> We do this to make sure that everything goes into a release exactly
> right, which is more important to us than maintaining license purity.
>
> This rule is better than an enumeration, since the actual files
> might change over time.
>
> (BTW, our diffs to files not originated by us are also
> released to the public domain, but they might not be
> very useful.)
>
> -Doug
>
>
>
>
>
Thanks for your help.  With regard to including the code in GNU
Classpath, we'd like to use java.util.concurrent code provided by you as
an upstream provider.  Ideally, this would thus be based on some kind of
stable release point, rather than a random CVS snapshot.  Is such a
thing available, specifically a version which forms the basis of the 1.5
release (i.e. without the unstable 1.6 additions which are now appearing
in the repository).  Is such a thing available, or would it be possible
to make this available for use as an upstream provider for Classpath?

Also, I note that the code, as-is, use some internal Sun classes
(notably in the atomic classes).  Is there some documentation available
which specifies what these external methods are expected to provide?

Thanks,
--
Andrew :)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman

Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: JSR166+backport: Licensing Issues

Doug Lea
Andrew John Hughes wrote:
>  
> Thanks for your help.  With regard to including the code in GNU
> Classpath, we'd like to use java.util.concurrent code provided by you as
> an upstream provider.  Ideally, this would thus be based on some kind of
> stable release point, rather than a random CVS snapshot.

There are CVS tags (like "JSR166_PFD") at release points.
But you are better off getting more recent versions, that
contain fixes. (There were three "serious" bugs in
initial Tiger release, but you might as well get others.)
And in fact, we are very near stable Mustang/JSE6 freeze,
so in a month or so, there will be very few changes for
a while, and then none at all for a longer while.

>
> Also, I note that the code, as-is, use some internal Sun classes
> (notably in the atomic classes).  Is there some documentation available
> which specifies what these external methods are expected to provide?
>

The only internal class used is "sun.misc.Unsafe". This (poorly
named) class should be familiar to all JVM implementors, since it
contains "intrinsics" underlying various JSRs that require
bytecode-like VM support in the era where people don't dare add byte
codes. Someday this class should undergo JCP standardization, but
different JVM providers seem to want to retain some flexibility about
it, so it probably still premature to standardize. I believe that
JikesRVM for example contains overlapping methods but in a differently
named class. For simplicity, I believe that all the commercial JVMs
contain supersets of the Sun version. Implementation of this class
requires tight coupling with a JVM -- intrinsics are things
the look like methods, but act like bytecodes.

-Doug
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest