On Friday, 9 August 2019 02:19:30 CEST Brendan Hickey wrote: > Branching off from the Libre Source discussion. Not necessarily in reply to > Russell, but this seems like a good jumping off point. > > On Thu, Aug 8, 2019 at 8:09 PM Russell McOrmond <russellmcorm...@gmail.com> > > wrote: > > I will register my standard objection, which is that 2.2 seems to attempt > > to restrict private modification. Many countries are starting to > > recognise > > the harm of claiming restrictions on private copying under copyright, so > > this reads as an attempt to circumvent in contract law a limitation or > > exception of copyright law. > > > > I believe any such attempts to circumvent limits and exceptions to > > copyright violate the intent of FLOSS even when not clearly understood to > > violate the language of the OSD. > > What are some good policy arguments in favor of restrictions on private > modification? My own impression is that these licenses are so onerous as to > discourage any serious use. Are there any significant projects using the > RPL or similar licenses?
I'm not sure if it can be considered a good policy argument, but my point of view is that it's - at the very least - ethically questionable to take source code that the author clearly intended to be libre, improve upon it, and then keep the improvements from the rest of the world; or the sinister variant of it: Make it worse and pretend you didn't. As an example of the latter consider the following (contrived, but imho not implausible scenario): You are a business that on the one hand wants its office workers to feel safe while browsing the web, but on the other hand wants to (or maybe has to due to regulations for things such as insider trading) monitor all your employees network activities. There are common ways to accomplish this, but they are usually fairly easy to detect for those of your employees with basic technical expertise. Now suppose you want to make your monitoring as close to undetectable as feasible. To your luck there's an open source security library that's basically used by every program you want to monitor. And to your further luck, you may do private modifications. So you go ahead, add your monitoring capability to the library, build it, and deploy it within your business (which generally doesn't count as distribution) while calling it by the same name. Your employees won't be able to distinguish between the library with reduced security and the original one. You could argue that the use in the example isn't private anymore, but I could extend the example to a network service that claims to be secure due to their use of aforementioned security library, but internally use a weakened one. While I don't think forcing modified source code to be published would stop this completely, it would at least make it a lot harder for the people involved. _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
