Hi Jim,
1. I'm embarrassed to say that as a dues-paying member of the FSF since
2009, I didn't know there's a team of volunteers who can help compose a
response until this post from you!
Since the paper I linked to was from 2017, the journal will certainly
accept for consideration, but likely not agree to publish a rebuttal. It
will likely not be considered sufficiently "impactful" or to have
immediate relevance. I would disagree and indeed have strong opinions on
the sad state of academic publishing, but that's a topic for a whole
other thread.
*HOWEVER*, I really like your suggestion of a rebuttal in general.
Statements like the one I quoted in that paper occasionally pop up in
newer papers (especially with the current move towards "open science",
which comes with its own set of well-intentioned but oft-misguided
suggestions). Perhaps we should craft a rebuttal anyway, submit it to
the journal of that 2017 paper, and even if it doesn't get published we
can create a template for future uses?
Generally speaking, I've seen the following typical scenarios in
academic papers that discuss open science: (a) "Publish your code so
that your work is reproducible!" without any mention of licenses; (b)
"Make your code open source and remember to use a 'permissive' license
because GPL == bad", which is the situation described in my original
post; and (c) and combination of the other two but also includes lots of
proprietary suggestions such as using proprietary languages (e.g.
Matlab), proprietary toolchains (e.g. Apple Xcode, Microsoft Visual
Studio), and proprietary platforms (e.g. GitHub, Slack, Trello, etc.).
So going a step further, maybe we can craft template response to each
situation? Submitting a rebuttal to the 2017 paper can just be
"practice" and to see how a typical academic journal would respond so
that we can iterate on the template.
What do you think? I'd be happy to help you and the team if folks are
keen on this idea. There are so many well-meaning academics who are
sadly simply completely ignorant on software freedom and licensing issues.
2. What a great anecdote from the LLVM project and example of how
copyleft also benefits developers who care about freedom. The academic
in me wishes there's a citable source, haha! Hopefully someone else
remembers where it came from?
4. "We haven't lost the debate; we haven't *had* the debate. Just
getting the question on the table would be a success." - This is a much
more positive way of looking at things, thank you!
On 9/23/20 6:28 AM, Jim Garrett wrote:
(Not responding to Marinus specifically, just getting a few thoughts in
the thread.)
1. First, the FSF has a community team of volunteers who try to respond
to this sort of public issue. The public-facing PR arm of the FSF, as
it were. Perhaps it should send a rebuttal to the journal? Thoughts,
Pen-Yuan?
2. I recall an anecdote that might help crystallize things.
I recall reading a comment from the founder (and copyright holder) of
the LLVM project, saying that he chose a permissive license for the
project because he had the intention of someday making a proprietary
product based on it. (I probably can't find that quote, sorry!)
Now, if you're an expert in writing compilers and have a notion to
contribute to LLVM, how do you like the fact that you could offer your
contribution freely, but the copyright holder could take it, add his
own contributions, and put it not into LLVM but into a proprietary
"LLVM+". You would have no access to the improved version; you could
pay for a binary blob but you won't have the source code. All you have
is an assurance that LLVM--as of the version you contributed to--will
always be available. Not a bad thing, but aren't you a bit of a
sucker? You gave, he took; he gave, and now you can't get. Wouldn't
you rather contribute to a project with a strong Free license, so you
know you'll get the benefit of future contributions from others?
3. *Of course* corporations are expressing a preference for permissive
licenses. This benefits those that would like to make proprietary
products based on them. *Of course* the GPL makes it harder to work
with such software projects. This is simply a matter of large,
powerful entities generating discourse that benefits them, and people
not really paying attention to the deeper phenomenon. It seems
critical these days in all areas of our lives: we need to evaluate the
power and financial dynamics involved, and the motives of the entity
generating the discourse.
(Isn't it the case that Google has made a rule of no additional GPL
software in Android? And of course they are developing their own
kernel so they can get rid of Linux. Is it our business to make life
better for Google?)
4. 99% of people, including (especially?) highly computer-literate
people, have never even thought about associating ethics with
software. We haven't lost the debate; we haven't *had* the debate.
Just getting the question on the table would be a success.
-Jim Garrett
_______________________________________________
libreplanet-discuss mailing list
[email protected]
https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss
