Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Censorship Software Your Rights Online

SQL-Ledger Relicensed, Community Gagged 194

Ashley Gittins writes "Users of the popular accounting package SQL-Ledger were being kept in the dark about a recent license change. Two weeks ago a new version of the software was released but along with it came the silent change of license from GPLv2 to the 'SQL-Ledger Open Source License' — presumably in an effort to prevent future forks like LedgerSMB. As it turns out, the author was making deliberate attempts to prevent the community from finding out about the license change. No posts to the SQL-Ledger mailing lists asking about the license change were getting past moderation and direct questions to the author were going unanswered. Just recently the license was switched back to GPLv2. This behavior is not a first for this particular project, and is part of the reason for the original LedgerSMB fork. Does a project maintainer have an ethical obligation to notify his or her community of a license change? What about a legal obligation?"
This discussion has been archived. No new comments can be posted.

SQL-Ledger Relicensed, Community Gagged

Comments Filter:
  • Oh no! (Score:5, Funny)

    by rolfwind ( 528248 ) on Sunday April 15, 2007 @02:40PM (#18742995)

    Nothing for you to see here. Please move along.
    The developer is in charge of /. too!
  • by erroneus ( 253617 ) on Sunday April 15, 2007 @02:43PM (#18743023) Homepage
    Of course! Being open is exactly what open source is about. Well, hopefully the LedgerSMB fork will be able to get beyond the personality defects of the SQL-Ledger guy...
  • switched back (Score:2, Redundant)

    by stoolpigeon ( 454276 ) *
    if you read the links, you will see that the author has already switched back to gpl v2
    • You'll see the same if you read the summary.

      It's too late now though. The damage has been done and the apparent intent to keep people in the dark about major changes which could have a negative impact on their use of the software will no doubt see a lot of users lose faith and switch to an alternative.
      • good - i emailed the editor when i saw the story was going to hit the front page. nice to see it wasn't for nothing. when i read the summary after it went live, i missed that they had made the change, so i appreciate your pointing it out.
  • Relicensing... (Score:5, Insightful)

    by mlwmohawk ( 801821 ) on Sunday April 15, 2007 @02:44PM (#18743041)
    If the author is the sole author and/or owns all the copyrights, then they can do what ever they like. If, however, they have accepted third party submitions then they may have a legal obligation to remain GPLv2
    • As you say, if it's the author's own work, that's fine, but if there's contributor content, they may have extra constraints, and that also applies to using packages with GPL or other licenses as a platform or component of your code. That was certainly one of the goals of the GNU Public Virus approach - if you're using Free Software, you can't make the Free parts non-Free, and if you're doing things the way RMS would really like, all of your contributions would also be Free. If you want to be able to late
      • No a project CAN NOT switch from GPLv2 to GPLv3 unless EVERYONE who contributed code agrees.

        However - the reality is if a majority agree and a minority do not then what happens is that minorities code is removed from the project and re-implemented by those who do.

        Now of course this only works if the minority is very small. If the minority is large enough to make it unfeasible then such a license change does not take place. Which is the way things SHOULD be.

        I have been a contributor to projects that subseque
    • Re: (Score:3, Insightful)

      by pla ( 258480 )
      If the author is the sole author and/or owns all the copyrights, then they can do what ever they like.

      They can do whatever they like in the future. And anyone can take the entire GPL'd code base from the day before the license change and tell the "owner" to go fork himself.

      That in itself counts as one of the best reasons to use GPL'd software - Eternal compatibility, as long as someone, anyone, continues work on the older codebase (which may mean nothing more than compiling it as-it-stands once every
      • The "in the future" issue is not about the GPL, it is an issue with law, i.e. you can't change the rules in the middle of the game. So, yes, you are right, you can use GPL code as long as you want, no matter what the new license is.

        • The "in the future" issue is not about the GPL, it is an issue with law, i.e. you can't change the rules in the middle of the game.

          Unless you write an EULA, in which case you can change the terms of sale after the sale (or licensing or whatever you actually get from a software store).

    • Still, even if he is the sole author of it, he has a moral obligation to inform the stake holders, which includes the users, of the license change. Let the users then make an informed decision about what to do.
      • That's an interesting take, "stake holders," I can understand that position, but let me ask you this:

        You write a open source application. You poor a lot of time and effort into it. You do it for what ever reason, on-line resume, share what you have, what ever. People take your work and spin off their own project because they disagree with what you want to do. They may assume they have a "stake," but by introducing something do you give them the rights?

        More to the point, I have an open source project that I
  • by Kjella ( 173770 ) on Sunday April 15, 2007 @02:46PM (#18743055) Homepage
    Legally you don't have to announce your business decisions in advance, ethically well... I can understand why you wouldn't, the day you came out and said it the GPL version is as good as yours - no reason to switch. You'd want to have some sort of carrot "New version with $foo and $bar" so people would actually change. Everyone producing anything OSS is entitled to stand up at any moment and say "Screw this, I'm going to try making money off it", assuming it's all their code of course. If you want reliability and future commitment, perhaps you should pay for it? As long as you rely on volunteer contributions you haven't really got a leg to stand on, should they disappear in a puff of smoke.
    • by Kjella ( 173770 )
      Sorry to respond to my own post but that should read "Screw this, I'm going close the source and try making money off it", clearly you can make money of an OSS product too.
    • by ScrewMaster ( 602015 ) on Sunday April 15, 2007 @03:32PM (#18743405)
      If you want reliability and future commitment, perhaps you should pay for it?

      That doesn't always work either. Just read the EULA for, well, pretty much any piece of commercial software. If the vendor disappears, decides not to support the product, if it vaporizes your computer and most of the building its in ... tough. Paying for it doesn't mean anything in and of itself. Consequently, you have no assurance of anything in the software world unless you're dealing with a vendor that has a significant track record of playing square with its customers. Still no guarantee, but that's about as good as it gets, and it is true whether it's open source or not, commercial or not.
      • if you have any sense when buying software, and you're big enough to make the vendor agree, then a code escrowe agreement is critical in case the vendor folds (sometimes even have a release condition predicated on the vendor being bought by another company who may abandon the product).

        if you're subcontracting the software to another company, then make sure that you have full rights over the code and that you get regular SCCS/RCS/CVS/Subversion snapshots (you need to have direct access to the contractor's

      • If you want reliability and commitment you *should* pay for it. If you buy a subscription ot RHEL update services, that is one way. You could also pay members of the core teams for support accounts, and the like.

        But it doesn't mean you need to pay for the software license.
    • If you want reliability and future commitment, perhaps you should pay for it?
      perhaps but it is important realise that by buying propietry software licenses you are not buying that. If a competitor decides they want to squash your suppliers product by buying them out and all you have are licenses there isn't anything much you can do.

      you may be able to get a contract that gaurantees reliability and future commitment but that contract would have to be very carefully worded and it still doesn't really help you
  • by Ant P. ( 974313 ) on Sunday April 15, 2007 @02:47PM (#18743065)
    Both the links to their "public support forum" and wiki bring up a HTTP password prompt.
  • by $RANDOMLUSER ( 804576 ) on Sunday April 15, 2007 @02:57PM (#18743149)
    Forcing people to accept a change in the license without telling them? Definitely unethical - kind of like forcing people to accept Windows Genunie Advantage if you want patches.
    • There is no ethical problem here. (At least the way I see it and my ethics does not necessary = other's ethics). As the author of the project he can change the license as he pleases. What others see as deliberate attempt at not disclosing the change can just be laziness. If the license is included with the distribution and clearly readable it is the responsability of the user to check it.

      BUT if the software was GPL before then that old version is still GPL (imagine it has been forked or integrated in other

      • " What others see as deliberate attempt at not disclosing the change can just be laziness"

        Yes, it *can* be laziness. But in this case, as long as the summary states it, it can't be laziness since the project leader took the effort of not aproving for being published any comment relating to such decision.

        "if someone downloaded it within that hour can they treat it as GPL even though now it has a different license but it is the same software?"

        Of course. It took *his own copy* under the GPL. He can do with
      • In the first instance, yes, you have a licence to use the code under the GPL, so you can continue using it.

        In the second instance, no, because you do not have any sort of valid licence from the copyright holder.
    • No one's being forced to accept any changes. If you don't like the new license, don't use the new software. Stick with the old GPLv2 version. It's simple really.
    • I'm not quite sure what you're talking about. In this case, you can use your existing version of the app without the new license. In your other example you can just turn on Automatic Updates and you get all the patches! No WGA needed!
    • by mqx ( 792882 )
      "Forcing people to accept a change in the license without telling them? "

      Umm, who forces anyone to accept anything: if you find that a new release has a license you don't like, then you don't have to accept it: use older versions or choose an alternative.
  • Simader (Score:4, Informative)

    by hpavc ( 129350 ) on Sunday April 15, 2007 @03:01PM (#18743181)
    Simader is a putz and always has been. That project is the worst of programming with Perl ever -- its a contraption. Its developed like any 'job security' program would be, using a rube goldberg approach when ever possible. Any attempt to integrate with that project with anything has always met with his poison. Much rather put my efforts into something like http://frontaccounting.com/ [frontaccounting.com] rather than SQLL. Even though I am a perl zealot.

    Finally the death of his project.
    • Re: (Score:3, Interesting)

      by daeg ( 828071 )
      I came here to say the exact same thing. We have another OSS project that "integrates" with SQL-Ledger (I use that term very loosely) and I am replacing both with, uh, real programming. I am convinced that SQL-Ledger and other hobbled-together "open source" projects are merely fronts for greedy developers that hook businesses with the prospect of free, open source packages that can replace commercial packages that can run into the thousands for even the smallest of businesses. Then, when the company wants t
      • The guys at LedgerSMB had exactly the same problem, and they're busy cleaning up the code. Their stance is different as they provide a service, not software, and they make more sense re Open Source approach to code.

        I think the root problem is that the SQL Ledger guy didn't realise what Open Source meant when he 'opened' it. LedgerSMB seems more focused on simply being a reasonable product, and their focus is the SME market who coul dnever afford the gazillion dollar programs..
    • Re: (Score:3, Informative)

      by einhverfr ( 238914 )
      First, I would not run *any* accounting db on MySQL 4.x... Google "MySQL Gotchas" for good reasons why. So Frontaccounting is pretty much out.... (I am not sure I would trust MySQL 5.x either but that is another matter).

      Second, Simader's Perl is pretty much as you describe (\%$form?), and his db design isn't any better. We have spent six months doing what mostly amounts to security patches and now we are ready to re-engineer in place. By 2.0, LedgerSMB will have no code left from SQL-Ledger.
  • Does a project maintainer have an ethical obligation to notify his or her community of a license change? What about a legal obligation?

    Ethical obligation: certainly, I would argue.

    Legally, it's in the ballpark of something like this:

    You cannot change the license on contributions to your project without permission of every contributor.

    The enforceability of a license often depends in no small part on the notice of the change. For example, a quiet change of the license obligating you to make retroactive paymen
    • by cheros ( 223479 )
      and intentionally didn't tell his contributors who kept making valuable contributions

      To be fair to the guy, he wasn't very keen to take in contributions so that doesn't seem to be a huge problem. I think he could have just been a bit clearer about his intentions, and that includes the realisation that Open Sourcing may not have been quite what he intended to do.

      Oh, and acting when angry isn't a good thing either, but we've all been there, I think :-).

      The prime problem I can see is that he did something su

    • But, arguably if the project is run with a dictator type model, then the dictator doesn't need to ask. They _can_ just make changes.
  • absolutely! Yes!

    The evidence of this is shown in the development of GPLv3

    It's old school to bait and switch.
    It up and coming to be Honest and open.

    Perhaps honesty and openness was what was needed regarding the concerns that resulted in the flip flop?
    Would the flip flop had happened?

  • by ThinkComp ( 514335 ) on Sunday April 15, 2007 @03:12PM (#18743257)
    I have been writing accounting software of my own lately (http://www.thinkcomputer.com) that also does taxes, and licensing has come up in the past week for me, as well. I used the PDFlib 6 library with PHP, which I paid over $1,400 for, to create PDF files so that my software could prepare tax returns, and all was working fine until my server crashed in March. I was forced to upgrade to new hardware, which I did, in the form of two Sun Fire X2200 servers running Linux. Installing PDFlib on my new setup didn't work, because even though my server had two processors, and I had a license for two processors, PDFlib detected four logical processors (each AMD CPU is dual-core). This was irritating on its own, but the fact that the newer version of PDFlib, version 7, uses a *different* system-based license (and of course they didn't tell anyone) that makes the number of logical processors irrelevant, means that the PDFlib acknowledge the flawed nature of their original license. When I asked them for assistance, since I needed to get my software up and running again, their response was that I should pay them $2,700 more in license fees for version 6 (more than the cost of the server) or $1,194 for a single-system upgrade to the new licensing scheme of version 7 (more than the cost of the original single-CPU license for version 6). To me, it sounded like extortion, but since the company is in Germany they can get away with it easier I suppose.

    Needless to say, I'm never using PDFlib again, and I'm re-writing all of my code to use FPDF (http://www.fpdf.org), which is free, and works just as well. It's even easier to write code for. Stay away from PDFlib!
    • by dinther ( 738910 ) on Sunday April 15, 2007 @03:47PM (#18743493) Homepage
      So the lesson is:

      Never, ever, ever buy third party libraries without source. Without source you no longer own the solution you create. I have seen it happen many times before and these days I put a lot of pressure of the library vendor with the hard rule, "No source no Sale". Many of these third party library providers have gone out of business or shifted focus to other products. Without source I would be in trouble.

      Never, ever, ever buy any software at all that licenses against a specific set of hardware.

      Lately I more often contemplating switching OS to get away from the worst black box of all... "Windows" With Vista and the brain dead security rules introduced it becomes impossible to write software.
    • You can still host the old software on your new box, just by running it under VMWAre or Xen and configuring the VM to have less CPUs than your real box. You may need a bit more RAM, but RAM costs less than PDFLIb upgrades.
  • TLUG (Score:4, Informative)

    by hey ( 83763 ) on Sunday April 15, 2007 @05:24PM (#18744175) Journal
    This was the topic at the recent Toronto Linux User Group meeting.
    http://tlug.ss.org/wiki/Meetings:2007-04 [ss.org]
    The talk was by a Ledger SMB core developer.
    I bought what he said... Ledger SMB is now on Source Forge, reacts to security issues,
    accepts patches, is converting to a saner architecture, uses CURRENCY instead of FLOAT for money.
    Seems like its a winner.
  • by Colin Smith ( 2679 ) on Sunday April 15, 2007 @05:58PM (#18744445)
    There are actually rather a lot of free and open source accounting packages around.

            * Front Accounting
            * Ledger SMB
            * WebERP
            * OpenAccounting
            * TurboCash
                        o Windows
            * GnuCash
            * Personal
                        o HomeBank
                        o jGnash
                        o GFP
                        o Grisbi
            * CK-Ledger
            * Compiere
            * Lazy8
            * Quasar
                        o Linux Canada
            * phpCOIN
            * opentaps
            * Bambooinvoice
            * GnuAccounting
            * phpOrganisation
            * OpenBravo

    They are in various states of repair and different markets from the personal to the one man band to the multinational.
     
  • by The Breeze ( 140484 ) on Sunday April 15, 2007 @06:10PM (#18744545) Homepage
    I never even tried SQL ledger, simply because while researching different Linux accounting packages I came across some post by one of the head guys, possibly this "Dieter" doorknob, replying to a user with something very much like the following:

    "Well, I wouldn't worry about it. We are not that concerned with security because there's nothing that SQL Ledger works with that would be of interest to anyone except an accountant, and I don't think we need to worry about a bunch of rogue accountants."

    That statement alone made me not want to touch the packae, even though it looked very nice otherwise.

  • In a similar vein:

    I'm still trying to figure out why the Anti-Grain Geometry library went from BSD-like to GPL a few months ago with no code change. http://www.antigrain.com/ [antigrain.com]

    I haven't found any information on why the switch occurred and the author doesn't appear to have explained his motivations. I find myself working on a project in which I can employ 2.4, but I can't upgrade to 2.5 due to the licensing restriction, so I must either fork and maintain what I am using from 2.4 or abandon the library.

    The bait
  • If there are no third party contributions to the software, then the author can change the license in whatever way he wants to (of course, not retroactively--old GPL'ed copies remain GPL).

    If there are third party contributions, it depends on whether the contributors assigned the copyright to him. If they did not, he can't change the license. If they did, it depends on what the copyright assignment forms imposed on him.

    In many cases, I wouldn't consider a GPL->proprietary license change a big deal for a
    • All your arguments hold if the question is can the maintainer change the license. The question posed in the summary is does the maintainer have an obligation to inform people of the license. The license is a contract between two enities. If one of those enities takes delibirate steps to withhold the terms of the contract until after the contract is in effect, the contract is null and void. This is the exact problem that most people have with shrink wrap licenses on commericially purchased software, and
      • If you obtained foo.c under the GPL, then the terms of the GPL apply to you: that is the "contract" between you and the author. Those terms can be modified only if all parties to the contract agree. It doesn't matter what terms the owner of foo.c distributes the file under to other people, either at the same time or at a later time.

        Even if the owner of foo.c wanted to change the terms of your license retroactively, he couldn't; any such attempt wouldn't be "fraud", it would be futile. The only way this w
  • From the article, it really doesn't sound like the developer really understands what Open Source or the GPL is all about. Let him go and good riddance - I understand there's a pretty good fork out there anyway. :+>

One man's constant is another man's variable. -- A.J. Perlis

Working...