James Carman wrote:
On 1/23/08, Richard S. Hall <[EMAIL PROTECTED]> wrote:
James Carman wrote:
I guess the big point here is what is the big issue with changing the
package name in the code? When people see a class that's in an
org.apache.*package, they assume that it's from the ASF. Leaving it
in an
ASF-namespaced package has two problems here:
1. People will assume that it's ASF code.
2. The ASF never put its "stamp of approval" on this code, since it never
made it out of the incubator.
Neither one of these problems is a legal problem based on the license (from
what folks have said here). But, there are certain conventions in the Java
community which we follow. If someone sees that code and they want to learn
more about it, they'll probably go to www.apache.org and try to find some
information. Leaving that code in an ASF-namespaced package is kind of like
putting words into someone else's mouth.
I didn't say that I was against asking people to change it nicely, but I
think there is nothing we can do if they don't. Section 4.b states:
You must cause any modified files to carry prominent notices stating
that You changed the files; and
So, if they make any changes, they must prominently say so, so they
wouldn't be putting words into anyone's mouth.
If someone downloads the binaries, they don't have the source code, so
they'd have to look at the NOTICE file to know what's going on. I
doubt many folks actually read those (I typically don't). To me,
publishing classes in someone else's namespace (that they didn't
author) is like putting words in someone else's mouth. I would
imagine other folks feel that way also. The fact that they legally
take care of their obligations with respect to the license wouldn't
change my perception either. I would still feel uneasy about it.
It seems that there are two discussions going on at the same time:
1. Whether it is cool for people to do this.
2. Whether we should try to stop people from doing this.
I am pretty sure that we all agree that it is not cool (1), so I wasn't
talking about this. Regarding (2), I think we shouldn't and can't do
much to stop it.
-> richard
Another interesting point to all of this is the question of whether the
package name really is part of "the code". Is "the code" everything that's
in the source file or is "the code" the actual logic inside the file? The
package statement could only be seen as a namespace facility and not
necessarily "code." I'm no lawyer, but one might try to make that
distinction.
I don't see how you could argue that it is not part of the code, when it
impacts the API.
The API is the way you talk to the object, or the interface (thus the
I in API). The interface consists of the name of the class itself and
the names of the methods and fields of the class (whether they be
instance or class level). You can change the package name of a
library without changing the client logic code. You'll have to use a
different namespace to address it (change imports or fully-qualified
class names), but the manner in which you use the objects/classes
doesn't change. I don't know that I necessarily agree with what I'm
saying. I'm just playing devil's advocate. :) In any case, I merely
said it was interesting and I don't really know if it's worth wasting
anyone else's time here on it (many things I find interesting aren't
worth others' time).
The main point in this discussion is that not changing the package
names is not illegal, but it's definitely uncool and goes against a
pretty well adhered to convention. Legally, all we can do is ask them
to change the package names and if they don't, there's nothing we can
do (at least that's what we're hearing from other folks in this
discussion).
-> richard
On 1/23/08, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:
On Jan 23, 2008 11:26 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:
Niall Pemberton schrieb:
On Jan 23, 2008 7:23 AM, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Niall
Asking someone politely to rename the package is hardly throwing our
weight around.
Well you were talking about "need to change the package name" and
"rigorous protection" rather than some kind of "hey we'd prefer
it...".
If people are so keen on *protecting* apache in this way then rather
than starting with a failed incubator project, then how about this
stuff:
https://glassfish.dev.java.net/source/browse/glassfish/appserv-webtier/src/java/org/apache/
Again, that is a bit different from the original TCIK issue. It
*appears* that here they are not doing this in order to *distribute* a
forked copy of tomcat, but instead to support tomcat as an alternative
internal servlet-engine implementation within their own j2ee server. In
other words, I would think that:
(a) you could not normally download this code except by downloading the
entire glassfish server, and
(b) they are not actively developing this code to add new features
(forking) but simply adding a few patches to make it integrate better
with Glassfish.
The alternate implementations of commons-logging have also been
mentioned in this thread. This is not the same IMO. Commons-logging is
both an API and an implementation. People should be able to provide
alternate implementations of an API, and that is what slf4j are doing
for example; they are not providing a "patched" or "forked"
commons-logging, but instead a complete alternative implementation, and
are distributing just the minimum amount of code to provide the same
api
to users.
So:
* distributing a few classes in order to implement an apache API : ok
* distributing a copy of apache code for the convenience of users of a
larger package, perhaps with a few minor tweaks for better integration:
ok
* publishing code to the world which bears no resemblance to code
approved by the ASF: not ok
My advice to anyone - read the license yourself, take advice if you
feel you need it and ignore all the stuff being spouted here:
http://www.apache.org/licenses/LICENSE-2.0.html#redistribution
That would be my feeling too. The license pretty much allows people to
do whatever they want with the code and the package name is part of the
code.
-> richard
Niall
All this just just my opinion of course..
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
