License Issue about kaptcha HOT 5 CLOSED

At this point (and especially after I apply the patches from cliff), there is 
very little simplecaptcha code left. 

The simplecaptcha developer is missing in action (no response to anyone in 
*years*). There also wasn't a license 
on simplecaptcha at all (and people had been requesting one), so I figure that 
taking the simplecaptcha code as 
a base, modifying it heavily and putting a very open license on Kaptcha is not 
a bad thing.

If you see a problem with this, then feel free to speak up, otherwise, I don't 
really understand what you are 
looking for or what your "license issue" is.

Even if I highly doubt anyone would sue you (and I'm sure you're working in good
faith), if simplecaptcha has no license you cannot use it at all without 
infringing
copyright, as per default any use of a copyrighted work is forbidden. I know 
this
seems silly and boring, but for many people this is important.

For example, I was considering creating a Debian package for kaptcha, but this 
little
issue might render it impossible due to the strict licensing requirements that 
Debian
has.

So, if you could explicitly tag which files have no license, you'll be easing 
our
lives :) And I might even volunteer for rewriting the missing code from scratch.

Cheers, Tincho.

There was no copyright on the simplecaptcha code either and like I said, there 
is very little simplecaptcha code 
left. There is nothing to re-write because the only code left (the image 
generation code) would be written exactly 
the same way that it was written in the first place.

As for a debian package. I'd rather that you do not make a debian package. 
Using the deb packaging system to 
install a .jar file is a terrible idea because java code dependencies shouldn't 
be managed that way.

You should take into account that not having a explicit copyright statement 
doesn't
make it public domain; on the contrary, copyright is implicitly granted. So the
license issue still holds, and -hate to say it- you're still infringing 
copyright.

As per managing dependencies, I beg to differ -and any GNU/Linux distribution 
would
agree with me-, as the best way to have a tidy and controlled system is to only 
use
resources made available from your distribution of choice, which takes care of 
all
the integration issues. A good example of this, is the licensing problem, since
Debian has a clear and enforced policy about what can be into Debian proper, so
everybody can use whatever we distribute knowing that licensing has already 
been checked.

Other good example is that you're distributing an embedded library (imaging.jar)
which is ancient, uses jdk1.1 interfaces and the author has superseded years ago
(current project is called pixels and it's hosted at 
https://pixels.dev.java.net/).
Using deprecated and undeclared libraries which can have bugs which will go 
under the
radar, when you can use the current code *and* avoid duplicated and uncontrolled
copies of libraries is something any sysadmin will avoid at any cost.

About the copyright... well, if the author has an issue, he can come bring it 
up with me. Until then, I'm not going 
to worry about it as, like I said, the code has been changed significantly 
since the original author wrote it. 
Additionally, I have not copyrighted the code (and all of its modifications) to 
myself, I have copyrighted it to the 
kaptcha project and I have given copyright credit to the original author. If 
you feel that you can't use or distribute 
my project because of your perceived issues, then that is your problem, not 
mine.

As for dependencies, I agree, for a Unix based system where you are installing 
applications and libraries, using 
something like dpkg is an important (and wonderful) thing. However, we are not 
talking about a unix system, we 
are talking about libraries which are included in a java application. Java 
applications have different rules for 
dependencies and should be managed differently than a unix os is managed. Using 
dpkg to manage java 
dependencies is a terrible idea. I have a requirement that I can check *any* 
version of my project out from a tag 
and be able to easily build it. Even 5-10 years from now. Using package 
managers does not promise that 
because the package repos and formats can (and will) get modified. The best 
solution is to check the jars your 
code relies on into your SCM system. The reason why I distribute the embedded 
library (imaging.jar) is a perfect 
example of one way of managing dependencies in a java environment. I have 
tested my software against 
imaging.jar and I know for a fact that it works as expected. I also want to 
make sure that you know that when 
you include kaptcha.jar, your code will work fine with it forever. I'm not 
concerned with any (potential) bugs in it 
because my code works as expected. Ease of use and known dependencies is my 
goal.

Thank you for pointing out the pixels project, I did not know about it and I'll 
take a look into switching to use 
that project in a future release.