[jcifs] We seem to have found a home in Android Apps.

[Michael B Allen]

On Tue, Jan 3, 2012 at 8:00 AM, Jim Hurne <hurne at vivisimo.com> wrote:
> On 01/02/2012 08:18 AM, Sebastian Sickelmann wrote:
>>
>> i love to see that you think some contributors to jcifs would be great.
>> But it is not that easy to participate to jcifs as for many other
>> open-source projects.
>
>
> I agree with Sebastian. In particular, the lack of a true version control
> system is holding the JCIFS project back.
>
> I'm sure Mike would agree he cannot do everything. In fact, based on some of
> his responses to questions posted to the mailing list over the past year,
> it's increasingly clear Mike has less time to devote to JCIFS than he had in
> the past. This is perfectly reasonable. After all, it is a lot to ask one
> person to maintain a critical library like JCIFS. Hosting the JCIFS source
> code in a public version control system like git would definitely make it
> easier for others to pitch in and help out.
>
> Beyond version control, JCIFS could really use a true issue management
> system. Such a system would: (a) make it easier to track and prioritize
> reported issues, and (b) reduce the number of redundant posts on the mailing
> list because people tend to look at the issue management system first.  In
> terms of priority, the need for a true version control system is much higher
> than the need for an issue management system, so I'd suggest looking into
> git and samba.org git hosting first.

Hi Jim,

I have to totally disagree with you here.

It's actually not that common to get a contribution that is accepted
as-is. In fact with the exception of the NTLMSSP code from Eric and
occasional one liners, I don't recall ever actually applying a
contributed patch directly. In fact, contributed code is almost always
wrong in some way (the NTLMSSP code is - I just rewrote for a
commercial package to workaround problems where that code was not
compatible with Windows behavior). I just look at what the contributed
code does and then make the changes necessary to do what it fixes /
does. Version control is of no use when you only have one person
controlling the tree. JCIFS uses the Linux style development model -
just take a copy, make the changes and post the new package. If the
changes are useful, they will make it into the main tree. If you want
to post something in github, do it.

In fact, I would go so far as to say that the current dev model is not
holding the project back - it is holding it UP. If other people could
commit to the tree I think it would turn into a mess. This is in part
because JCIFS is not very object oriented. There's a lot of encoding
and decoding and multiplexing of messages and locking going on that
has absolutely nothing to do with OOP. Most Java programmers are way
over psyched about OOP and I would be very concerned that if someone
were to be let loose on the JCIFS codebase they would quickly drive it
into the ground. Try one of the crawler examples against a server with
lots of files (like millions) in a memory profiler and look at the
objects created. It creates almost NO objects (aside from lots of
Strings because the String class is immutable and there's no string
primitive). JCIFS is very lean as Java code goes. That was not an
accident.

>> Am 01.01.2012 22:54, schrieb Christopher R. Hertel:
>>> Speaking of cellphones...
>>> I know of two very popular file browser apps for Android that use jCIFS
>>> as
>>> their underlying SMB/CIFS implementation.  As far as I can tell, however,
>>> there is no acknowledgement of jCIFS in these apps, and no pointer to the
>>> jCIFS source.  I would like to see jCIFS acknowledged and the links
>>> provided, per the license.  The LGPL was specifically chosen to make it
>>> easy
>>> to use jCIFS with closed-source applications, so there is no reason not
>>> to
>>> meet the terms.

Actually this has come up on the list before about Android apps and
the LGPL and I'm pretty sure I've told them to outright ignore the
link-back requirement in the LGPL in this case and that if someone had
a problem with that I would just re-license JCIFS using a new license
that didn't have the link-back requirement. And I stand by that
position. Sebastian may have been one of these people. I don't recall.
If someone has a link to said post be a sweet heart and reply to this
message with the link for completeness please.

The problem with the LGPL and "apps" is that the LGPL requires that
the distributor either provide the source code with their package or a
link-back to the source but at the origin of the binary (in this case
the app store) and in a form that can be used to rebuild the
distributors package with the possibly modified JCIFS source. For a
variety of reasons this is not practical with any kind of "app store"
for Android or Apple or whatever the next device OS is.

However, I believe I did tell people to include the LGPL 2.1 license
text and reference to JCIFS in their legalese that goes with the app
and do everything except the link-back part. So in that respect, the
distributor should credit JCIFS. If they don't do this, that is
naughty. But unless they do something really interesting and we ask
about it and they decline to provide the source, I just don't care
honestly. JCIFS is not a new fresh innovative thing. It just
implements and old boring network protocol (albeit an important one).
The point being, it is highly unlikely that someone is going to come
up with a derived work that does something really new and clever. Even
if someone did a really good Kerberos mod, the Kerberos that comes
with Oracle's Java is so bad, I'm not sure I would be all that excited
about it.

And from the questions being asked on the list it sounds like these
Android apps are trying to do things like browse for servers on the
network or print which probably makes for a pretty horrible app since
NetBIOS is all but dead and printing is an ultra complex quagmire. So
I'm not sure I want to be given credited for stuff like that :->

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/