Closed GoogleCodeExporter closed 8 years ago
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.
Original comment by latch...@gmail.com
on 8 Jan 2008 at 4:36
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.
Original comment by martin.f...@gmail.com
on 24 Apr 2008 at 12:16
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.
Original comment by latch...@gmail.com
on 29 Apr 2008 at 12:01
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.
Original comment by martin.f...@gmail.com
on 29 Apr 2008 at 3:32
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.
Original comment by latch...@gmail.com
on 29 Apr 2008 at 4:06
Original issue reported on code.google.com by
markus.s...@gmail.com
on 8 Jan 2008 at 10:48