On Fri, May 01, 2015 at 11:01:55AM +1000, Les Kitchen wrote: > Thanks, Adam, for your helpful response.
Any time. :D > On Thu, Apr 30, 2015, at 00:37, Adam Bolte wrote: > > You say "option of interacting with DRM" and then attempt to draw an > > analogy between supporting EME, and supporting non-free operating > > systems the browser can run on. But this analogy is flawed. > > > > ... > > > I'm still not convinced that the analogy is flawed. It might > not be as strong as I thought it was, but I think it still > stands. I guess I need to do a bit more reading and thinking on > the topic. No worries. I look forward to hearing what you have to say if you come up with additional arguments or decide on a different conclusion. > > > For a long long time, free software will have to inter-operate > > > with non-free systems. > > > > "Inter-operate", "interact"... such vague terms. As previously > > illustrated, it might be a problem or it might not be a problem, > > depending on the situation. > > Yeah, and analysing those situations can be tricky and > contentious at times. I can recall the considerations and > discussions, say, that went into the formulation of existing > free-software licences, even the versions of the GPL — for > example considering process boundaries rather than say > subroutine boundaries. I think it safer to be clear and strict when discussing such things. If you read the thread I recently linked to regarding firmware and microcode, and how the Linux kernel started off with probably good intentions by accepting small strings that were only to initialise low level hardware, you might understand my reasoning. Ultimately without strict rules in place, this approach left the situation to be expanded upon and ultimately we now have firmware included in the Linux kernel that's bigger than older versions of the Linux kernel, and under a very restrictive license. If they just said "sorry, microcode and firmware is never getting in our kernel" from the start, I expect more hardware designs would have paid considerable attention to the issue before it became a problem, and the Linux Libre project would never have been necessary. I don't know for certain if Torvalds regrets his decision, but it would be very hard to change his stance on the issue now if he did. > > > We need to build a ramp so many people can move towards greater > > > freedom, not a high wall that only the few can climb. If free > > > software is only some kind of ascetic practice for the few, then > > > we're not really advancing freedom. > > > > What's happening here is that Mozilla has created a ramp for people to > > switch to a DRM-riddled video service in the browser. How is that a > > greater freedom? They have the freedom to have their freedoms taken > > away, sure... but that's the kind of backwards thinking which has > > resulted licenses such as the FreeBSD license. > > Interesting that you mention that. When I was writing that > post, I almost mentioned the traditional tension between > GPL-style and BSD-style licences (and perhaps more important, > the mind-sets behind them about what freedom means). I decided > not to, since I was already ranting on too much. But it was > certainly in my mind as I wrote. Part of it is the question of > whether you consider BSD licences bad or just less good. (And > in terms of organizational culture, I note that the Mozilla > Public Licence is a kind of GPL / BSD mashup.) Original BSD, Modified BSD, FreeBSD, X11, WTFPL, etc... I'm not a fan of any of those. Although this is an over-simplification, I feel the GPL protects the user, whereas those other kinds of licenses aim to protect the developer (less worry about compatibility, patents, free to perform Tivoization, etc.). > I need some time to think more about this. As I see it, the big > question is, What are the practical strategies that are going to > advance free software in the long term? In that, yes, as you say, > there are some lines that should not be crossed, but also a lot of > areas in which justifiable trade-offs can be made, and there is > scope for concerned, thoughtful people to reach different opinions. > The main thing is that in the end we work together. Perhaps it would help if you were able to illustrate some examples where a free software project deliberately supported DRM, which resulted in long-term benefits to free software overall (aside from situations where it prompted a fork by a 3rd party)? I don't think I can think of anything like this, but perhaps I'm just not thinking hard enough. Cheers, Adam
signature.asc
Description: Digital signature
_______________________________________________ Free-software-melb mailing list [email protected] http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/
