I wanted to give the issue of use of the GPL and the BSD to a separate thread because there is a lot of confusion about the issues here. The whole debate has been fogged by misinformation provided by the FSF concerning copyright. Quite of lot of programmers in the open source movement believe that because BSD is a liberal 'do as thou wilt' license; it is OK to 'relicense' BSD code under GPL. This is a myth. Feel free to copy this post to news groups.The whole BSD/GPL issue came up in 2007 in the OpenBSD group where an OS programmer Reyk created a program under BSD that the GPL Linux folks wanted to place under GPL. You can read De Raadt's account here.The story Theo gave, and I believe him, is that GPL Linux people pestered Reyk to allow them to license the code under GPL which he would not. According to Theo, they then simply took it and removed his name and put their names on top and GPLed it. This is of course illegal. When caught out, they resorted to a series of subterfuges including an argument that any BSD program could be 'relicensed' by having the GPL placed on it. According to de Raadt, Stallman disclaimed all knowledge of the episode. ("The FSF is not involved in this dispute."). However it seems Eben Moglen had knowledge of what was going on, and since Moglen is the right hand of Stallman, it is hard to credit Stallman not knowing the existence of the dispute. Here you will find him actively defending the Linux/GPL position with a view of copyright that is quite wrong.This is a very long thread (> 900 messages and I read them all) so type license into the search box if you want to read what Stallman says. His posts are masterpieces of prevarication and obfuscation.De Raadt fought his corner and good for him; the GPL people backed down under threat of legal action. Theo says; and he is worth quoting because he is right.But that is the clincher -- by law, a new person doing small changes to an original work is not allowed to assert copyright, and hence, gains none of the rights given by copyright law, and hence, cannot assert a license (copyright licenses surrender a subset of theauthor's rights which the law gives them; the licenses do not not assert rights out of thin air).Of course a decent organisation would have never tried such a disrespectful trick on an OS project. Unfortunately this relicensing idea has spread to the news groups.Now it is open to me as copyright holder, to dual license the kernel to GPL, but I will not do so until there are some fundamental root and branch reforms of the FSF. Like what you ask? Well, here they are.1. The whole 'closed source is evil' meme needs to be dropped. Programmers are entitled to do with their own work as they want, and it is obnoxious to call somebody a 'thief' as Stallman did to Bryan Lunduke (see 55m and after), merely for writing closed source games to feed his family. The arguments Stallman uses to support his position are lamentably weak. It is doubly obnoxious and hypocritical to do so because the FSF has been in receipt of donations from companies that make money from closed source.
2. Many of the programmers contributing to GPL are doing the work pro bono for little or nothing. Yet a vast share of the FSF income is being trousered by lawyers. Moglen is making a huge sum in addition to his income as a law professor at Columbia. The lawyers need to work under the same conditions that programmers do.
3. Creative rights do need to be respected. Stallman's advocacy of piracy under 'the right to read' is just an endorsement of a criminal offence; particularly if the author is relying on book revenue to get by.I would also add, not as a requirement, but as a wish, that the Orwellian use of the word 'free' to describe the GPL should be dropped.This does not affect the ability to write GPL programs on top of Shen, but no part of my code will be relicensed to GPL until these reforms are instituted.Mark
--
To unsubscribe from this group and stop receiving emails from it, send an email to qilang+unsubscribe@googlegroups">qilang+unsubscribe@googlegroups">qilang+unsubscribe@googlegroups">qilang+unsub...@googlegroups.com.
To post to this group, send email to qilang@googlegroups">qilang@googlegroups">qilang@googlegroups">qilang@googlegroups.com.
Mark, thank you for sharing the links to the controversy that took place in 2007. I was unaware of it previously (or had forgotten about it), and it does help to put things into perspective.
There is a long write-up on the SFLC's website from that same time period. It doesn't address the controversy head on, but does seem to have been written in reaction to it:
Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
I wouldn't describe it as fun reading, but I did read it completely, and the suggestions therein seem reasonable to me. If anyone knows of a critical piece or law case which invalidates various assertions and conclusions in that document, I would be grateful for references.
Let me say that I am no fan of the GPL and certainly not an advocate for it. I personally don't use it for my own projects (except as obligated), preferring permissive licenses (BSD, MIT, Apache 2). When copyleft seems called for, I tend to reach for the Eclipse Public License (EPL), which has softer terms regarding reciprocal licensing obligations. Going beyond the GPL to the ideals, even extremism, of RMS and crew -- I share many of your concerns and objections. So, all in all, please don't mistake me for a GPL advocate.
Regarding the points I raised in the other thread: I may not have been entirely clear, but I meant to refer solely to derivative, copyrightable works based on the Shen sources. I agree that no one has the legal right to relicense a work simply because the original author adopted a permissive license like BSD. The question then is to what extent the BSD license propagates itself with respect to derivative works? And by that I don't mean works written in the Shen Language and/or compiled with programs you wrote. I mean specifically the case where someone takes the body of work which is the "basis" of a Shen port (e.g. your soon to be released Shen 17 sources and Shen->KL program), changes those sources, and creates a derived set of sources and compiled programs. Perhaps there are aspects of KL they wish to change... who knows. The point is that it is possible (in practice, not with respect to legal concerns) to create a derivative work of this kind, and the question is then raised as to the derivative's author's obligation to adopt the same BSD license. For the sake of argument, let's ignore the case of trivial changes and assume we're talking about derivative works which are substantially modified from the originals.
Everything I've read (not just today) leads me to conclude that while the derivative's author is required by law to retain/reproduce the original's license text (and in effect point back to the original work), he is not bound by law to license his derivative -- used privately or distributed to the four winds -- under the same BSD license. He could choose any license which is compatible with BSD, so long as he does not neglect to include the original license text (as spelled out in clauses #1 and #2 of 3-Clause BSD). There appears to be no case law, in this country at least, which actually requires the derivative's author to keep the original license intact on a file-by-file basis. As the SFLC points out, maintaining licenses file-by-file is a common practice (and for good reasons), but I have yet to find any examples where a judge or jury or expert legal analyst has said that it's strictly required. The alternative being to collect the original's license notice/s into another file/s which is part of the derivative work.
So if you want to create a GPL-free zone, it seems to me that the only choice is to put an extra stipulation in your license or license notice. The Google Polymer Project (a software framework for Web developers) seems to have gone that direction:
https://github.com/Polymer/polymer/blob/master/banner.txt
"This code may only be used under the BSD style license found at http://polymer.github.io/LICENSE.txt"
The actual text of Polymer's license is boilerplate 3-Clause BSD:
http://polymer.github.io/LICENSE.txt
It's not entirely clear to me to what extent Google's notice actually (legally) restricts derivative or combined works from being licensed differently, but it does seem clear that they want to give the impression of a restriction.
For what it's worth, I would suggest not changing the text of the 3-Clause BSD license for Shen. That would only reintroduce the problems associated with having a non-standard license. So in distributions of Shen, the LICENSE.txt file, or whatever it's named, and comment blocks with the heading "License" (or whatever) would have only the standard license text, with your name in the appropriate places. But in proximity to the license, you could give notice of a generic restriction similar to the one used by Google for Polymer.
Personally, I don't like the idea. It feels like we end up back in the realm of copyleft – to avoid downstream GPL'ing there is put in place a restriction that has a lot in common with the GPL. Almost instantly, the spectre is raised of needing to hire a lawyer to figure out whether incorporation of "BSD only" source code will infect combined and derivative works to an unacceptable extent. For me, the point of permissive licenses is to say something like: "I wish people to know about, have access to, and make use of my open source code under the licensing terms I adopted for my work. You must give me credit always and indicate my licensing terms when you incorporate my work into yours, whether you choose to license your own work under the same or other terms. If you incorporate my work or parts of it as such, without creating a derivative work, then those portions of the combined work are understood to be, and must be indicated to be, licensed under the terms I originally chose. In this way, others will have the opportunity to know about, build on, and benefit from my work, as you did." And that's it.
Best regards,
--
Michael Bradley
@michaelsbradley
Let this be my last unprompted contribution to our 2 Minute Hate of the FSF/GPL/RMS (but feel free to ask specific questions):From: Mark Tarver <dr.mt...@gmail.com>Date: Sun, 11 Jan 2015 05:32:35 -0800 (PST)[...]The idea of relicensing under a 'compatible license' is something that the FSF introduced, but it is a fiction unless you actually can assert copyright over the work you are licensing. You cannot add extra conditions to a license without copyright and you get that by writing the work yourself or else by seeking permission from the author. This is exactly what Theo was fighting for. If you modify the code (as I do with the CL port to optimise performance) and put it in a seperate file then providing the changes are substantial - that code is yours....My understanding of copyright law as it's done in the US, especially in the context of translations of foreign media into English, is that such a file would still be a derivative work. You own your contributions, the original rights holder loses nothing. If the latter wants to use your work, they need your permission, and similarly you can't legally distribute your work without the rights holders' permission. BSD licensing makes this simple and mechanical, and I personally would never touch an in-file license notice, I'd only add my own as needed.
BTW, I strongly advise making the Shen site GPL free, or cleanly segregating any GPL material and allowing no non-permissive licensed code in the standard library. For the same reason as changing the Shen license to BSD: the less someone has to think about legal issues before using any of the Shen ecosystem, the better for its adaption. Any viral license deliberately and intentionally imposes additional conditions in an otherwise permissive license environment.
E.g. at best, use GPL for a complete stand-alone work like an editor. But please, especially given the small size of the Shen community, permissively license anything that others might want to use, like code to interact with a GUI.
It's good we're having this discussion and it's worth OS programmers taking it in.I'll look at the FSF stuff, but really if you read Stallman in the long thread I supplied you'll see exactly what I mean about corrupt. I encourage Shenturians to read it - it is fascinating.Let me interject why I can speak authoritatively about RMS and what became the FSF (and why, for entirely non-legal reasons, my favorite license is the "MIT" (X Consortium) license :-):I showed up at MIT as a freshman when the wire wrapping of the backplane of (CADR) Lisp Machine #9 was be checked by another Lisp Machine. Lisp Machines were obviously the hottest thing at the time (enough so that the director of the rival Lab for Computer Science was claiming them as a LCS project during tours he gave until the famous nameplate on top was generated to stop that), and after finances forced me into a sordid life of programming I eventually ended up at Lisp Machines Inc., the competitor of Symbolics, in the 1982-3 period.Before then RMS was a member of my social group, and we were on OK terms. At LMI we were allies, in that he was doing his best to implement the most important new features in the MIT/LMI fork of the code. I was also one of the few people left willing to break bread with him; if you've read the end of Steven Levy's Hackers which not entirely inaccurately portrays RMS as the last hacker left at the MIT AI Lab, well, one of his beefs was just that, almost all his colleagues off at Symbolics and able to politely avoid him.We both gave up on Lisp Machines at about the same time, summer of 1983, and were in fact roommates when he launched the GNU project (the FSF came a couple of years later). That didn't last too long for obvious reasons, and in due course, starting in 1985, I worked for UniPress, a company that published UNIX™ software. Back then the most important thing was to have access to one of every type of UNIX™ out there, and combined with that their general model is what is called "closed gate open source" ( https://en.wikipedia.org/wiki/Gated_community ), you got binaries and source, but you couldn't redistribute either.This was true for there most important product at the time, an obscure bit of software called Gosling Emacs™, an editor with a byte code compiler that was written by none other than the obscure James Gosling of eventual Java/JVM fame. About half of my professional work in the '80s was on various versions of EMACS, I got tapped to finish the MS-DOS port, and moved to New Jersey for a while where it was located.RMS outright stole Gosling Emacs™ to start the GNU version of it; the owners of UniPress acknowledged this and asked him not to do it. The were old hands in the field and knew nothing good would come from legal action, and that RMS's version would, at least for a while, increase the general market for EMACS, back in a time where it was hard to afford the hardware to run it (Eight Megabytes And Constantly Swapping was a legit criticism through the mid-90s). We were labeled "Software Hoarders" (and named our LaserWriter that :-), accused of burning down his apartment building (seriously, and it did happen, that was where we had been roommates, a not so nice part of Cambridge, MA, USA, the culprits were "a couple of kids" "playing" with matches and kerosine), etc. etc.E.g. our publishing and serious work in improving and bug fixing an version of EMACS that we shipped with source code was a worse crime than stealing that same code (RMS claimed he had received an email from Gosling that gave him permission, but never was able to produce a copy of such a vital document, and Gosling denied it). And I knew the low level C source at an intimate level, GNU Emacs was most definitely legally a derived work, it was most unwise to do this, for UniPress could have nailed him to the wall and severely damaged the GNU project in its cradle. His stewardship of GNU/FSF software projects is really that bad (and there's lots, lots more about GNU Emacs going forward, e.g. look into the Lucid fork. GCC also once forked, and the other GNU/FSF marque project, the infamous Hurd operation system, is 29 years in the making and pretty obviously never going make it).Anyway, enough of that, I'll close with two bits of humor; first a Not Necessarily Safe For Your Sanity (but really not that bad) mock advertisement of "GNU, a new fragrance by RMS" http://i.imgur.com/88Jgz.jpg and a very funny XKCD cartoon: http://xkcd.com/225/ (note Eric S. Raymond is (in)famously a gun owner).- Harold
Anyway, enough of that, I'll close with two bits of humor; first a Not Necessarily Safe For Your Sanity (but really not that bad) mock advertisement of "GNU, a new fragrance by RMS" http://i.imgur.com/88Jgz.jpg and a very funny XKCD cartoon: http://xkcd.com/225/ (note Eric S. Raymond is (in)famously a gun owner).- Harold
Richard Greenblatt’s proposal for a Lisp machine company had two premises. First, there should be no outside investment. This would have been totally unrealistic: a company manufacturing computer hardware needs capital.
Second, Greenblatt himself would be the CEO. The other members of the Lisp machine project were extremely dubious of Greenblatt’s ability to run a company....
Stallman’s characterization of this as “backstabbing”, and that Symbolics decided not “not have scruples”, is pure hogwash. There was no backstabbing whatsoever. Symbolics was extremely scrupulous. Stallman’s characterization of Symbolics as “looking for ways to destroy” LMI is pure fantasy.
Let this be my last unprompted contribution to our 2 Minute Hate of the FSF/GPL/RMS (but feel free to ask specific questions):
<snip>
E.g. our publishing and serious work in improving and bug fixing an version of EMACS that we shipped with source code was a worse crime than stealing that same code (RMS claimed he had received an email from Gosling that gave him permission, but never was able to produce a copy of such a vital document, and Gosling denied it). And I knew the low level C source at an intimate level, GNU Emacs was most definitely legally a derived work, it was most unwise to do this, for UniPress could have nailed him to the wall and severely damaged the GNU project in its cradle. His stewardship of GNU/FSF software projects is really that bad (and there's lots, lots more about GNU Emacs going forward, e.g. look into the Lucid fork. GCC also once forked, and the other GNU/FSF marque project, the infamous Hurd operation system, is 29 years in the making and pretty obviously never going make it).
<snip>
Since Gosling had permitted its unrestricted redistribution, Richard Stallman used some Gosling Emacs code in the initial version of GNU Emacs.[citation needed] Among other things, he rewrote part of the Gosling code headed by the skull-and-crossbones comment and made it "...shorter, faster, clearer and more flexible."[3]
UniPress began selling Gosling Emacs (which it renamed Unipress Emacs) as a proprietary product,[citation needed] and controversially, asked Stallman to stop distributing Gosling Emacs source code. UniPress never took legal action against Stallman or his nascent Free Software Foundation,[citation needed] believing "hobbyists and academics could never produce an Emacs that could compete" with their product.[citation needed] All Gosling Emacs code was removed from GNU Emacs by version 16.56, with the possible exception of a few particularly hairy sections of the display code.
Mark
Since Gosling had permitted its unrestricted redistribution, Richard Stallman used some Gosling Emacs code in the initial version of GNU Emacs.[citation needed]
Among other things, he rewrote part of the Gosling code headed by the skull-and-crossbones comment and made it "...shorter, faster, clearer and more flexible."[3]
[...] UniPress never took legal action against Stallman or his nascent Free Software Foundation,[citation needed] believing "hobbyists and academics could never produce an Emacs that could compete" with their product.[citation needed]
All Gosling Emacs code was removed from GNU Emacs by version 16.56, with the possible exception of a few particularly hairy sections of the display code.
Both not true and irrelevant, it was still a derived work in copyright law outside of RMS/FSF's ... interpretations of the law. That one of the 2-3 successful marque efforts of the GNU project was born in sin like this might have something to do with their subsequent and to this day IP postures....