Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Software Government The Courts News

License for Open-Source Software w/ Plugins? 91

ThiagoHP asks: "I have developed MultiMAD, a rapid application development and prototyping for for mobile devices in my master's course, and now I want to share it with the community. It's written in Java and it has a plugin architecture in order to support different mobile device platforms (WAP, J2ME, PalmOS, etc). I want to give the freedom to anybody write their plugins, even closed-source, as long as the tool itself is not modified for them to run. This implies that GPL cannot be used. At the same time, I do not want any closed-source tool based in MultiMAD code, so licenses such as the Apache one cannot be used. Am I right in my assumptions regarding licenses? What license do you suggest?"
This discussion has been archived. No new comments can be posted.

License for Open-Source Software w/ Plugins?

Comments Filter:
  • Have you met this guy? [slashdot.org].
    • It's interesting as three guys at my university (Universidade Federal de Minas Gerais, Belo Horizonte, Brazil) were in the same situation as that guy. One already finished his project and implemented a PalmOS application generator (plugin). One is making a WindowsCE generator and other is still defining what he wants to do.
  • LGPL (Score:5, Informative)

    by A.K.A_Magnet ( 860822 ) on Saturday August 27, 2005 @07:37PM (#13418229) Homepage
    That's exactly what the LGPL is for.

    Derivative of your code will be in LGPL, but code linked to it (as plugins or using it as a library) have no license requirement.

    Check it out [fsf.org]
    • He could use the GPL variant that the Linux kernel uses that explicitly allows binary modules.
      • by hummassa ( 157160 ) on Saturday August 27, 2005 @08:23PM (#13418476) Homepage Journal
        Linux is a massively complex work when the subject is copyright. Basically, the kernel as a whole is GPLv2, and Linus (who has the copyright on a lot of code and has indirect copyright on almost the whole kernel [much kernel code which is not his is still derivative on his original linux v0.01]) says he -- like other intelligent people -- do not consider the FSF GPL FAQ as correct about linking (especially dynalinking) and the GPL.
        IOW: when you GPLv2 some code, you are probably granting the right to dynalink proprietary modules to your work. Linus only stated this explicitly, thus estopping himself from suing anyone (nVidia?) who makes proprietary loadable kernel modules.
        • 'when you GPLv2 some code, you are probably granting the right to dynalink proprietary modules to your work.'

          Yep, I agree google for 'Abstraction, Filtration, Comparison' and you should have no doubt that dynamic linking and GPLv2 are ok. This guy is obviously worried that the GPL doesn't allow linking (as many people seem to be) so I advised that he use the GPL with a clause that allows for plugin modules.

          The kernel license says...

          "NOTE! This copyright does *not* cover user programs that use kernel
        • Let's not compare apples and oranges. Linus made an exception for binary only modules, but that exception only applies to the Linux kernel.

          In this case, the question applies to a userland application, and I would agree that LGPL would be a suitable license as A.K.A Magnet wrote.

      • Re:Tried and tested (Score:2, Interesting)

        by Trepalium ( 109107 )
        The Linux kernel does not explicitly allow binary modules. This is a commonly repeated myth. Please see Linus's posting on LKML [iu.edu] for the truth behind this.
        • Ok, I actually read /usr/src/linux/COPYING....

          Please see Linus's posting on LKML for the truth behind this.

          I think you should see abstraction filtration comparison [google.co.uk] along with the fact that the GPL is a copyright license to work out what's a derived work or not and not relly on legal advise from someone who's not a lawyer (Yes and IANAL!!)
    • Re:LGPL (Score:4, Insightful)

      by NotoriousQ ( 457789 ) on Saturday August 27, 2005 @07:43PM (#13418260) Homepage
      Even better is to split the program into two parts. LGPL the core, and GPL the interface.

      • But, where does the 'core' end, and the 'interface' begin?

        Can you really divide it so cleanly?

        Are there not interfaces between all of the layers?

      • This would only work if you distributed the two parts seperately. Because once LGPL code is combined with GPL, the LGPL part gets promoted to GPL and you are back where you started.
        • by Mr Z ( 6791 )
          Huh? Aggregation means nothing. You can say "The stuff in src/libfoo is LGPL and the stuff in src/appbar is GPL" just fine. I mean, just look at any Linux distribution, with its combination of GPL, LGPL, BSD, public domain, and proprietary software, all within the same CD(s).

          Swinging back on topic, GPL would be a fine license for submitter's app. GPL covers redistribution. If the plugins are distributed separately of the application, then there's no issue. If you need special header files or whatev
    • Nothing stops you from adding your own clauses to the GPL that allow plugins to take on whatever license they want, as long as they do not use any GPL code. You'd also have to provide a self-contained header (ie one that doesn't call on any GPL'd parts) and wrap up the whole interface in there. Then you'd need to make a GPL exception in your derived license code containing your interface header. It's all too hard!!!

      The LGPL will do this to the same effect. Plugins are dynamically linked libraries (much
      • Do not modify the GPL text. Do not add your own clauses to it.

        You cannot modify the text of the GPL document. The GPL license document text is a copyright work, with a copyright notice on it. The GPL license text is Copyright by the FSF.

        If you create a license that is a very slight modification to the GPL, then you have created a derrivitive work of the FSF's text, requiring their permission. If you create your own license that is almost identical to the GPL, then you probably infringe on the FSF'
        • You cannot modify the text of the GPL document. The GPL license document text is a copyright work, with a copyright notice on it. The GPL license text is Copyright by the FSF.

          Where did you come up with this?

          You are allowed to use all of the GPL terms without the preamble, see here [gnu.org].

          • Thanks for your link to the FAQ.

            In answer to your question, I was going by the fact that this copyright notice....

            Copyright (C) 1989, 1991 Free Software Foundation, Inc.

            appears ahead of both the preamble and the main license text. Thus the entire text is a protectable work with a valid copyright notice. Personally, I would not modify and republish some existing copyrighted text without some clear permission or clear legal advice that I could do so.

            Here is one can of worms for instance. The

            • n answer to your question, I was going by the fact that this copyright notice....

              True, but any GPL'd work includes a copyright notice from the author as well. Having a copyright does not mean you are not allowed to change and redistribute; and the GNU/FSF is about freedom :)

              Can text that is part of court filings be copyrighted?

              Having the text listed as an exhibit does not change the fact that the FSF holds the copyright on the GPL. There are various parts of SCO code that were called as exhibits t

    • That or (Score:4, Insightful)

      by hummassa ( 157160 ) on Saturday August 27, 2005 @08:19PM (#13418456) Homepage Journal
      license your code under the GPL, and grant an additional exception that plugins can be proprietary. It would work, too... supposing the GPL really forbids dynlinking to proprietary modules, which is disputed.
      • license your code under the GPL, and grant an additional exception that plugins can be proprietary.

        This is exactly what Linus Torvalds did with the Linux kernel. The kernel is GPLed, and an exception is granted for proprietary kernel modules.

        • This is exactly what Linus Torvalds did with the Linux kernel. The kernel is GPLed, and an exception is granted for proprietary kernel modules.

          There is no such exception. Linus has already clarified this (more than once).

          Well, there really is no exception. However, copyright law obviously hinges on the definition of "derived work", and as such anything can always be argued on that point.

          I personally consider anything a "derived work" that needs special hooks in the kernel to function with Linux (

          • I expect this has been debated to death elsewhere, but:

            'I personally consider anything a "derived work" that needs special hooks in the kernel to function with Linux (ie it is _not_ acceptable to make a small piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs "help" from the main kernel.'


            Doesn't that precicely describe Nvidia's graphics driver? A GPL'd stub that wraps a huge proprietry blob of code?
            • I expect this has been debated to death elsewhere, but:

              You are right, the nvidia driver has been debated to death on LKML :-) Here is Linus personal opinion on that matter.

              So in order for nVidia to be able to legally distribute a binary-only kernel module, they have to be able to feel damn sure that they can explain (in a court of law, if necessary) that the module isn't a derived work. Enough to convince a judge. That's really all that matters. Our blathering matters not at all.

              Now, personally,

              • > the only opinion that matters is that of the judge.

                If they've got enough money to burn on barratry, the only opinion that really matters is that of the man paying the lawyers, because it is not difficult to ruin someone using the court system, if you have the veeriest shred of a pretext in law, and an overwhelming warchest.
    • I want to give the freedom to anybody write their plugins, even closed-source, as long as the tool itself is not modified for them to run...At the same time, I do not want any closed-source tool based in MultiMAD code

      That's exactly what the LGPL is for.

      That's a good question. The first sentence leads me to think he doesn't want ANYONE to modify his code, which LGPL would not be good for. The second sentence seems to imply he just doesn't want closed-source modifying his tool, which LGPL would be good

    • No. He doesn't want any derivitive from his project to be used on a closed source project. The LGPL allows this.
      What he wants is GPL. With GPL people can even make closed source plugins because they are not derivitive works. Also the GPL makes sure that derivitive projects will stay free and open source.

      So the GPL is exactly what he needs.
      • With GPL people can even make closed source plugins because they are not derivitive works.

        Is the reverse true? Can you have a closed source app with GPL plugins? At what point in "linking" does the viral nature kick in?
         
        • Yes the reverse is also true, as long as these plugins/projects are not derivitive projects of the closed source project. Example of this: MS windows is closed source. There are many ports of GPL projects to windows and that's ok cause these projects are not derivitive but they are using a public interface, eg. they could be using the win32 api.

          If however you modify/enhance the win32 api in some way, then you cannot redistribute it at all cause it's closed source which belongs to MS. Though with GPL proje
  • The GPL is fine. They will not be able to make commercial applications based off of your code, and they can make all the plugins they want, closed or open source, so long as they don't modify the host application's (MultiMAD's) code.

    Thank you for your contribution.
    • This is wrong. Any plugins that are loaded by a GPL program must be GPL.
      http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlu gins [gnu.org]
      • um...from the link:



        It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.


        If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and t

      • You don't have to use the stock GPL text.

        Anyone can modify the GPL to make their own similar-but-slightly-different version. You could make a version of the GPL that forbids Microsoft to use the code in any ways, for example.
        • Except that the GPL license itself is copyrighted:
          http://www.gnu.org/licenses/gpl.txt [gnu.org]

          Copyright (C) 1989, 1991 Free Software Foundation, Inc.
                51 Franklin St, Fifth Floor,
                Boston, MA 02110-1301 USA
          Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
          • Then add it as an addendum or appendix.

            (as a side note, that notice seems rather strange given the point of the GPL... heh... doesn't RMS know that information wants to be free?)
            • Actually, you can't. The GPL specifically disallows adding limitations to the license. See paragraph 6 and 7. The only exception for this is paragraph 8.

              You can, however, add a clause to give the recipient more rights.

              • Then open a new document, rewrite everything so you're not violating copyright while retaining the exact same spirit of the GPL, and add on your restriction.

                You can copyright a legal license, but you can't copyright "anything giving GPL-like freedoms".

                The point is, if you don't like what the GPL lets people do, release it under a license more acceptable to you. Add in an addendum and operate under the (probably safe) assumption that the FSF won't come charging you with copyright violation. Rewrite it in y
          • Except that the GPL license itself is copyrighted:....

            That just means you can't call it "GPL". You can come up with a very similar license (perhaps even a nearly identical one), but you can't claim it belongs to or was written by the FSF.

            Of course, technically (at least I think, IANAL), licenses are just like any other work (subject to the same copyright and derivative work protections), but I doubt RMS or the FSF is going to sue someone who changes the GPL to meet their needs and calls it something else.

            B
            • That just means you can't call it "GPL".

              Nope, it doesn't mean that. That would be the case if it was trademarked. When it's copyrighted, it means that you can't take the license text and redistribute and/or change it without the authors permission.

              The copyright of the GPL does not allow you to make changes to it. Period. End of discussion.

      • Actually what they say:

        If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program,

        Which is GNU-code for "we want to believe this despite what our lawyers may have told us".

        Regardless, if the main GPL program (Firefox) and the Plugin (Macromedia Flash) are distributed seperately and combined on the end-user's machine, there is simply just not a copyright violation to be found.

        That someone chose the GPL does not limit
    • The poster wants to deny users the freedom to modify the MultiMAD program ("[...] as long as the tool itself is not modified for them to run"). Thus, MultiMAD is to be licensed under a non-free license.

      The GNU GPL is a free software license; it allows users to modify the licensed program and to distribute those modified versions.

      They will not be able to make commercial applications based off of your code, and they can make all the plugins they want, closed or open source, so long as they don't modify

      • You took my words out of context. Yes, I would prefer to not have any MultiMAD forks, but I can live with that, so it would be free software. On the other hand, what I definetely want to forbid is plugins that need to fork MultiMAD to run.
        • Just a few minutes before making the parent post, you said I was right and that you hadn't made yourself clear [slashdot.org]. Now you're saying I'm taking your words out of context. That is confusing because you're addressing the same issue--granting users the freedom to modify MultiMAD for plugins.

          Yes, I would prefer to not have any MultiMAD forks, but I can live with that, so it would be free software. On the other hand, what I definetely want to forbid is plugins that need to fork MultiMAD to run.

          Users can't

          • That is confusing because you're addressing the same issue--granting users the freedom to modify MultiMAD for plugins.

            You're still wrong: we are not addressing the same issue and I do not want to grant users the freedom do modify MultiMAD for plugins. I want to grant them the right to make plugins, under any license they want, but without modifying my code for it. ;)

            Supposing that MultiMAD becomes a success, I can't see how forks would be good for users, as they would be incompatible among them and th

    • The GPL is fine. They will not be able to make commercial applications based off of your code....

      Anyone CAN make commercial applications out of a GPL program. (MySQL) They just have to comply with the GPL. The GPL does not restrict the act of selling the application for any amount of money. It just requires that the source code must be included, and that you may NOT charge anything beyond the cost of copying, for the source code.

      I bought a TiVo with a Linux kernel in it. I paid actual money for t
  • The GPL is only one way which a copyright holder may expose his work. If it's all your own original work, you can publish the interfaces under a less restrictive license, while still doing the GPL for the 'base' code.
  • Yes you can... (Score:5, Informative)

    by joto ( 134244 ) on Saturday August 27, 2005 @09:10PM (#13418710)
    Here's how you word it:

    This software is licensed under the General Public License (GPL), version 2 (see below for the full text of this license). As a special exemption, software plugins using the documented plugin API for this software, will be allowed to be distributed and/or run-time linked with this software regardless of their license.

    [Explain the plugin API, or where to find the "documented" parts of it]

    [Full text of GPL]

    • This is a good solution but remember to be careful about how you control the API definition (as I think the parent post is suggesting). If you are not careful, a user could use your software in a way that you don't approve of by changing the API to expose the parts of the program they want to use. If you lock down the API to much, you might limit what changes you (or other developers) could make in future versions (for example, if the API was in the license and other users has contributed code based on th
      • The obvious choice is to lock everything down as much as possible. And then add stuff to the API by request. The "allowed" parts of the API can easily be described with one sentence, e.g: "Only the functions and global names having names starting with 'myprog_plugin_api_' are allowed to use in plugins that are not released under the GPL".
        • What would stop a malicious user putting a wrapper around really_cool_internal_function() called myprog_plugin_api_hack_internal_function()? They might have to share their wrapper functions but they still get access to the bits they want.
          • What would stop a malicious user putting a wrapper around really_cool_internal_function() called myprog_plugin_api_hack_internal_function()?

            You are right. Since the program itself is GPL, they can create a fork, and modify it all they want. Hmmm... this is tricky to get right. Even if you explicitly list the allowed functions in the license, there is nothing preventing them from changing one of them (that they don't need), to do something else.

            I think the only solution to this problem is to only use th

  • by Anonymous Coward on Saturday August 27, 2005 @09:23PM (#13418774)
    Uhm, the GPL doesn't control your app, YOU do. Here's what you can do.

    #1) place the GPL in a file called "GPL".

    #2) Place the following text in a file called "COPYING":

    This program is copyright XYZ and can be distributed under the terms of the GPL (see the file "GPL") plus the following exception: any plugins written for this application are expressly exempt from any obligations required by the GPL. You must include this entire paragraph in any copies you make of this application.

    Jeezuz people, it's YOUR application, you can license it any way you want! You can make it GPL on Tuesdays and MIT on Saturdays. This isn't rocket science, RMS doesn't control your app, you don't assign copyright to the FSF, a little bearded man doesn't pop out of your screen if you choose not to sue people who make closed-source plugins. The GPL doesn't enforce your copyright, YOU DO!
    • You can make it GPL on Tuesdays and MIT on Saturdays.

      You could, but someone can relicense it as GPL on Saturdays and MIT on Tuesdays, since GPL and MIT by themselves don't have restrictions.

      You can always grant extra rights. You can't easily add extra conditions, though, unless you say that "This app is almost licensed under the GPL, except that you may not do foo, and when you redistribute the program, you must redistribute it under the terms of the GPL with this fooless clause." And even so, I'm not sure
      • You could, but someone can relicense it as GPL on Saturdays and MIT on Tuesdays, since GPL and MIT by themselves don't have restrictions.

        Not so. What license would grant them the right to do that? Certainly not the GPL, since once something is GPL, it's always GPL -- that's its strongest point, its ultimate protection. Not even the author can change the license of the version he has released under GPL. (He can license future versions differently of course, but note that he alone has this freedom as copy
        • Not so. What license would grant them the right to do that? Certainly not the GPL, since once something is GPL, it's always GPL -- that's its strongest point, its ultimate protection.

          That's exactly what I'm saying. You can't hold it as GPL for only one day - it's GPL forever. And same with MIT. You can't add the restriction that it's GPL only on Tuesdays, and MIT only on Saturdays, because neither license allows that.
          • You're both partly wrong, and partly right.

            You DO still have copyright over your software, unless you assign it to the public domain. You *can* change the license you distribute it under every day. You *can* add restrictions.

            But let's say you license it under GPL on Monday. I download it. On Tuesday, you change the license for the same exact code to MIT. YES, you can do this, but I still have the rights the GPL gave me to redistribute for my Monday version, so I'm free to distribute that myself under t
            • I think we're both saying the same thing and not realizing it.

              You're right about the Monday/Tuesday thing. My phrasing is that it would be pointless to do so, because you can't restrict people from reGPLling it on days other than Monday - unless you only license under a modified GPL.
              • This is probably more an academic exercise than sorting out an important point by now. You're right that it would generally be pointless to alternate licenses per dates.

                BUT it's important to understand that as the copyright holder, you *can* add restrictions to the GPL, and you can change the license (and presumably the new license applies to all updates to the code), and you can offer multiple licenses.

                Many people think that once you release your code as GPL, the people who download it have the same right
    • Sure. Unless you are building on top of some other GPLed code.

      There might be some rare cases where the latter does not apply.
    • the GPL doesn't control your app, YOU do. it's YOUR application, you can license it any way you want!

      Hi, my name is Darn McBribe. I really like your GPL'ed program FOO. I'm going to modify one line of the source code of FOO, thus creating a derrived work. Now I'll release my work and wait for people to use my "improved" version.

      (Actually, I might make some minor, or even worthy improvements -- in order for this scam to work.)

      My improved version of FOO is also under the GPL, since your origina
  • GPL + barrier (Score:3, Insightful)

    by vlad_petric ( 94134 ) on Saturday August 27, 2005 @10:09PM (#13418949) Homepage
    If you specifically say that use of the plug-in API does not make the plug-in a derived work, then you should be alright. A similar case is, interestingly enough, the linux kernel. While modifying the kernel is derived work, making syscalls from userspace does not make the user program a derived work. Besides the kernel/user space barrier, there's also a subset of kernel functions that are effectively GPL barriers (so some modules don't need to be GPL)
  • by Pope Raymond Lama ( 57277 ) <<gwidion> <at> <mpc.com.br>> on Saturday August 27, 2005 @10:15PM (#13418975) Homepage
    Since you own the copyright to your code, you can add an exception to the GPL that exempts plug-ins from being GPL compatible.

    Read the GPL FAQ on www.gnu.org to undertand this better. The GIMP itself uses |GP in this way, since there are non-free plug-ins for it.
  • by petrus4 ( 213815 ) on Sunday August 28, 2005 @12:47AM (#13419357) Homepage Journal
    What about using (*lowers voice to a whisper*) the BSD license? (*hears gasps of horror coming from the audience*)

    Before the GPL zealots come screaming out of the woodwork on this one, there's something they (and you) should know. The BSD license actually includes a copyright notice. Have a look at it and see. For FreeBSD as an example, the copyright is held by the CSRG.

    That means that in using it as a license, you don't actually surrender your copyright. (Unlike certain FUD which is spread by individuals who remain nameless states) You don't get a patent, no...but you *do* get copyright, in the originally intended sense of the word. This to me is a demonstration of why the GPL *is* both unnecessary and repressive, despite claims to the contrary.

    What you get the copyright to is your own work; what you're giving other people is the right to make *derivative* works. They get copyright on derivative works, yes...but they don't get the copyright on your work itself. So if you wanted to, you could use a non-viral license (the BSD license is only one option...www.opensource.org lists many) without having to assume that you're automatically putting your work in the public domain.

    My single biggest objection to Richard Stallman is that I believe that *his* philosophy is the only acceptable one. To me the use of the phrase "GPL compatible" in particular sounds a lot like the campaign Microsoft had a number of years back where they were certifying things as "Windows compatible" or "made for Windows 95."

    Stallman claims to be about freedom...but look closer. What he's really about is forming a cultural/social movement with himself at the head. That isn't anywhere near as much about freedom as it is about agreeing with whatever he decrees.
    • >My single biggest objection to Richard Stallman is >that I believe that *his* philosophy is the only >acceptable one.

      swap "I believe" with "I believe he thinks"
    • ...specifically

      I do not want any closed-source tool based in MultiMAD code, so licenses such as the Apache one cannot be used

      That precludes the BSD license as having any use for his problem. If he used the BSD license anyone could take his code, package it up, rename it and release it. As long as they then attributed that portions of the code are copyright by the original author (and include the list of disclaimers) they would be A.OK. and my programmer here would have no recourse.

      What I would sugges

      • That precludes the BSD license as having any use for his problem. If he used the BSD license anyone could take his code, package it up, rename it and release it. As long as they then attributed that portions of the code are copyright by the original author (and include the list of disclaimers) they would be A.OK. and my programmer here would have no recourse.

        They'd be doing that with what in essence would be a *fork*, though...or a derived work. This is what people don't understand. He'd still have his orig
        • Let me jump in here. This is stuff I've researched pretty thoroughly, and I don't even keep track of what RMS is talking about nowadays -- I just know what's in the licenses.

          They'd be doing that with what in essence would be a *fork*, though...or a derived work.

          Okay, so let's say he spends a year working on his application, than releases it under the BSD license. Acme company takes the source, changes the logo, packages it up, and sells it under a commercial license (binary only) for $20. They can do thi
    • I agree with the comments about GPL, Stallman and many of the GPL supporters. They simply refuse to underatand different philosophies. I prefer the apache license and think it or the BSD license are the true "free" software licenses.

      Expect such somments here on /. to get mod'ed down becuase of the stong presence of GPL supporters.
      • They simply refuse to underatand different philosophies.

        Stallman is not stupid. I think he understands different philosophies. I think he just does not agree with them.


        I prefer the apache license and think it or the BSD license are the true "free" software licenses.

        Stallman and other GPL proponents define "free" differently than you do.


        Myself, I use whatever license reflects my intentions for a particular purpose.
        • GPL is a business model, not freedom. It says that instead of paying license fees to use somehting, I must pay in labor and nothing I do, short of starting from scratch, even if I add 99% of the future value, changes this. How is this "free"? There is an ongoing payment, just labor instead of money.

          Apache or BSD say "Take it and do what you want". Now that sounds like free to me.
    • I think...in reading the original post, the author himself was asking about a license that would disallow the original code working its way into closed/commercial projects. Strictly speaking this is my biggest objection to the BSD license.

      Not to say I disagree that there should be a BSD license, but when *I* want to share something I want to share it plain and simple. Not have some jack-ass change the graphics around a bit do some re-tooling and market it themselves.

      Anyhow, Mozilla seems to be a big OSS
  • The licensing issues themselves are interesting. One of the things copyright does is allow you to control derivative copies. However there is always the fair use doctrine and the right to use material in a parody.

    I think the Pilsbury dough boy was caught up in this a few years ago and I have not heard what came of Pilsbury's attempts to stop the "XXX" version(s).

    Then there is the issue of adoption. Why would a developer choose to lock himself (herself) into any closed source product if there is a better
    • Free source code that's available on the internet is no different than any other commodity: take it with a grain - and preferable a whole block - of salt.

      There have been dozens of times where I thought "surely someone must have done this before" and then wasted quite a bit of time hunting it down. In some cases I simply couldn't find it (search engines yield irrelevant hits most of the time) and in the cases where I did I still had to spend a great deal of time looking through unfamiliar code with a fine co
      • Reusing code is only a timesaver when you can plug it in and not have to worry about it which is why I'd personally rather write it myself than be stuck with code I don't fully trust.

        I think this phrase says so much! Every programmer who undertook to re-invent the wheel has felt he could do a better job and of course he trusted his work.

        Then they quit and leave the problem for a maintenance programmer to deal with.

        Your points are quite valid mind you. But one day you will realise you have become your own
  • ... depending on where you want to put the boundary.

    Very roughly speaking (read the actual licences to clarify the real conditions...):

    The GPL's idea is: whatever is linked or derived from the original program must also be GPL-free.

    The LGPL: whatever is derived from the original code must be LGPL-free. No restriction on what code you can link or interface to.

    The MPL: the original code and modifications to its files must be MPL-free. No restrictions on code in new files.

  • I work on a Network Management application where the core is open source and the plugins can be any variation of license. We went through this same process and found GPL and LGPL to be more viral than beneficial for this same reason. We don't care, as you don't, that propriatary plugins (heck even extensions) are created and/or sold with our product, and they can have any license they want. However, we retain rights to our code, and any direct source code modifications to our files must be under our lice

  • Huh? Just use the GPL!

    The GPL does not regulate runtime linkage. RMS, the author of the GPL says so. While there may be a dispute over the boundaries of the GPL with regards to dynamic linkage, everyone agrees that runtime linkage is fine.

    A plugin is loaded at runtime. No problem.
    • > FreeBSD: Open Source without that fishy smell

      Are you referring to Puffy (OpenBSD) or the fish that Tux (uh, Linux) has overeaten?
  • with this guy [sveasoft.com] and his shill [linksysinfo.org], as well as someone [slashdot.org] who's dealt with Ewing? You might give that some consideration with licensing.

BLISS is ignorance.

Working...