incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: moving a failed incubation project
Date Wed, 23 Jan 2008 18:40:17 GMT
James Carman wrote:
> On 1/23/08, Richard S. Hall <heavy@ungoverned.org> 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 <heavy@ungoverned.org> wrote:
>>>
>>>       
>>>> Niall Pemberton wrote:
>>>>
>>>>         
>>>>> On Jan 23, 2008 11:26 AM, Simon Kitching <sk@ops.co.at> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Niall Pemberton schrieb:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> On Jan 23, 2008 7:23 AM, Paul Fremantle <pzfreo@gmail.com>
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: general-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>>
>>>>         
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message