Comments (5)
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 [email protected]
on 8 Jan 2008 at 4:36
- Changed state: WontFix
from kaptcha.
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 [email protected]
on 24 Apr 2008 at 12:16
from kaptcha.
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 [email protected]
on 29 Apr 2008 at 12:01
from kaptcha.
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 [email protected]
on 29 Apr 2008 at 3:32
from kaptcha.
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 [email protected]
on 29 Apr 2008 at 4:06
from kaptcha.
Related Issues (20)
- Remove pixels-jar from distribution HOT 1
- Enhancement for Wiki documentation HOT 1
- image with wrong code HOT 8
- session key is previous image - don't think it is KAPTCHA; looking for direction HOT 1
- Problem with Can't read the image? Click it to get a new one HOT 3
- Issues with the test environment HOT 1
- Can't Re-genarate image HOT 1
- java.lang.NoSuchMethodError: com.jhlabs.image.RippleFilter.setXAmplitude HOT 1
- unhandled exception leads to java heap dump (Compiled_method=com/jhlabs/image/TransformFilter.filter(Ljava/awt/image/BufferedImage;Ljava/awt/image/BufferedImage;)Ljava/awt/image/BufferedImage;) HOT 1
- The package is not available from any of the existing maven repositories HOT 1
- java.lang.IllegalStateException: getWriter() has already been called for this response HOT 1
- Maven repo HOT 2
- wrong captcha after IE9 sends 2 requests and cuts one off HOT 9
- Kaptcha is not validated in Safari Browser
- the kaptcha image's font border can not be customrized. HOT 3
- It does not work well in Firefox 23.0.1 HOT 12
- config no working when use @WebServlet annotation HOT 6
- Kaptcha is not validated in Google Chrome browser HOT 1
- The image is not showing after uploading the application on amazon ec2 instance HOT 1
- Java Compatibility HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kaptcha.