Quoting Steve Litt (sl...@troubleshooters.com): > I use copyleft licenses when: > > 1) The work is a substantial coding effort > > And, > > 2) I see very little reason for someone to use parts of my code in > proprietary programs.
You know, I do the same thing. > In theory I'd use lgpl in cases of #2, but lgpl, if I remember > correctly, forces the person incorporating the code into either > revealing his source code or submitting very reverse-engineerable > object code (I don't remember which). No, this entire 'forcing to reveal' thing is a blatant crock, just like the 'forcing to open-source' allegation frequently leveled against GPLv2 over the years. There is no legal mechanism available to copyright holders to compel revelation of source code by creator of a derivative work, just as there is no legal mechanism to compel open-sourcing of derivatives. Neither of those is available in civil tort litigation as a remedy for (proven-in-court) copyright violation. The courts offer these remedies: 1. Injunction against further violation (an equity remedy) 2. Monetary damages (a remedy 'at law', i.e., one of recompense). With any copyright licensing, proprietary or open source, the courts apply the same standard of review and offer the same remedy if the defendent is found to have violated copyright: Was defendent's actions a violation of the copyright owner's reserved rights (or in the alternative did defendent have lawful access to those rights under licence)? Did defendent's actions touch plaintiff's rights, e.g., by creating/distributing a derivative work as that term is defined in copyright law? Did plaintiff have standing to bring suit? If rights were at stake and infringed, which remedies are merited and how much money? Nowhere in that process is 'force the other guy to reveal source code' or 'force the other guy to open-source a derivative work'. Because those simply _aren't_ part of the copyright legal process. No, I'm not a lawyer, and even if I were would not be _your_ lawyer unless certified to the bar in your jurisdiction and working for you. But I am the former licensing guy at VA Linux Systems, Inc. and one of the regulars on the OSI license-discuss and license-review mailing lists for some decades, now. > For little projects I just use the Expat license, which practically the > same as one of the BSD licenses and one of the MIT licenses, except > there's only one Expat license so there's no ambiguity. You could avoid your hapless self-trapping into obscurity by specifying 'MIT License as published at https://opensource.org/licenses/MIT' -- and you could _also_ explicitly waive the hidden obligation you're accidentally imposing on third parties to add in the 'Expat License' text you omit from your works. I've told you this before. Show of hands: Is there anyone here except me or Steve who has ever heard the phrase 'Expat License' uttered by anyone but Steve Litt? (Anyone, anyone? Bueller?) Steve, there's your main problem. You bought a line from FSF perspective-challenged dumbasses that the expression 'MIT License' is 'too ambiguous' and that therefore licensors should use a term nobody knows, instead. Don't you know better than to take FSF advice without due wariness for dumbassery? > For copyleft stuff I usually use GPLv2 because I understand it, but for > my recent UMENU2 I used GPLv3 because it addresses software patents. I > *NEVER* include the words "or later", because I have no idea what kind > of animals might take over the FSF in later times. Yes, you do. FSF is legally constrained _very_ tightly by tax and corporate law to follow its declared charitable purpose. It literally has no legal power to be anything but a free-software outfit. Morever, ignoring that, if Cthulhu arises from R'lyeh, moves to Cambridge, takes over FSF, and somehow defeats the entire body of corporate regulatory law to make FSF a House of the Old Gods devoted to proprietary software or whatever, what do you imagine GPL v. 3.1 could declare that prevents utterly obvious workarounds? Consider cases: 1. Evil Future FSF makes GPLv3.1 specify tightly proprietary terms. Remedy for copyright owners of GPLv2+ codebases: Ignore this option. 2. Evil Future FSF makes GPLv3.1 specify permissive terms. Remedy for copyright owners of GPLv2+ codebases: Accept that a one-time permissive fork can now occur, change the main branch's code to GPLv2, and soldier on. But an option for a permissive fork isn't actual horrible, I'd say. 3. Evil Future FSF makes GPLv3.1 require a giveaway of licensor's patent, trademark, or other rights. Remedy for copyright owners of GPLv2+ codebases: Same as case 1. Basically, hypothetical Evil Future FSF has no power to actually hurt you. If you can think of a way, I'm (as my barber says) all ears. > I never use licenses with mentions of indemnification. Um, have you considered that the phrase 'In no event shall the authors or copyright holders be liable' in Expat License _is_ a mention of indemnification? _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
