Is standardization deemed to be against FS and how can it be tackled?

[Scott Wilson]

> On 13 Jun 2015, at 10:12, Nico Rikken <nico.rikken at fsfe.org> wrote:
> 
> Dear Tom,
> 
> That was quite an elaborate statement, thanks. I don't share your view
> on hostility. Copyright, patents and standardization practices have been
> around longer than actual software. As such the bodies cover more fields
> than just those related to software. As the matter of fact, my knowledge
> about standards mainly originates from non-software standards. In the
> software-related fields however the issue of free software should be
> known and addressed by now, I certainly agree with you on that.
> 
> Regarding your point on testing, as far as I know, testing
> specifications are defined, and testing organizations often request fees
> regarding the tests, but anyone can start testing according to the
> specifications. Or is this also regulated?
> 
> More generic I've seen the standardization process at work from afar and
> to me the process seems to be quite transparant. In the Netherlands the
> standardization body NEN is in charge of developing standards. The
> described approach [1] covers the forming of a committee which will
> develop a new standard, which will be up for public review, followed by
> publication and implementation. If the standard becomes outdated or
> needs other adjustments, the process will start over (this generally
> seems to happen every few years). I haven't yet gathered knowledge on
> how other bodies handle reaching consensus, so I can't really compare.
> [1] https://www.nen.nl/Normontwikkeling/Wat-is-normalisatie/De-7-stappen-van-normontwikkeling.htm
> 
> In the meantime I've contacted a few people involved in NEN and I've
> managed to get some information, but I still have some detailed
> questions in queue. I was told patents can't block implementation, and
> related patents should be known at the moment of standardization.
> However: what happens when patents are filed after the standard is
> drafted? and is a non-discriminatory low-cost license fee for each
> implementation acceptable? To me these seem to be the more fundamental
> questions for which I still lack an answer. This especially interesting
> in that I know of a GPLv3 client-side implementation of a standard. If
> this standard is indeed subject to license fees, there seems to be a
> legal conflict.
> 
> Regarding your point on strategy, I guess practical advise would be
> helpful to ease implementation and avoid conflicts. At least I assume
> you're referring to the interest of programmers. I guess such a strategy
> would have to cover:
> 0) how to stand against any discrimination, in order to prevent the
> upcoming points.
> 1) how to legally retrieve free-of-cost and free-for-use information on
> a standard (including reverse-engineering).
> 2) how to discover, handle or circumvent patent and copyright issues.
> 3) how to guarantee the freedoms with redistribution.
> 4) how to monitor external developments to prevent getting into new
> conflicts.

I like this strategy outline - its a great starting point,

I’ve been involved in three different “kingdoms” of standardisation: de jure national and European standards (CEN, BSI), consortia standardisation (W3, OASIS, IMS) and “community standards” (oAuth, Atom, OWF) and these are all quite different but I think the same principles can   apply.

For de jure standards, the issues for FOSS are the cost of accessing the documentation, but there is freedom to participate (at your own logistical expense) and to vote. The main issue is that most people from FOSS don’t have the time or inclination to participate. Patent policies tend to vary; most favour FRAND rather than royalty-free.

For consortia standards, the resulting standards tend to be free of cost to access, have variable freedom from encumbrance to use (W3 are royalty-free, OASIS are FRAND), but participation requires buying a seat at the table - so most FOSS projects don’t bother unless they get some sort of sponsorship to do so.

Community or ad-hoc standards are usually free to access and implement, and often open to participation, but in my experience the ad-hoc processes are also open to abuse by major vendors setting the agenda.

(The only thing I’d like to note is that its important not to confuse software freedom for users with financial costs for developers. Its easy to get exercised by having to pay €50 for a standards document, but if that standard can be implemented without encumbrance, and the implementation freely shared, modified and distributed by users then it better supports FOSS principles than a standard that is free to download, read and implement, but which incurs licensing costs or usage restrictions on users.)

> 
> I'm missing the expertise to fill de details, and furthermore it can be
> specific to local legislation, so that would be a task for experts to
> describe.
> 
> In a way your last paragraph describes both the issue and a possible
> solution to the issue: standards have become essential to our society
> and are even included in legislation. As such enabling the forming of
> standards seems to be a governmental act. Not so much the content
> itself, but rather about the process and the eventual standard. At the
> very least freedom in achieving and implementing the standards should be
> guaranteed, to avoid any discrimination.
> 
> I'm curious to hear your upcoming post. I have come to find this topic
> rather interesting.
> 
> Kind regards,
> Nico Rikken
> _______________________________________________
> Discussion mailing list
> Discussion at fsfeurope.org
> https://mail.fsfeurope.org/mailman/listinfo/discussion

OSS Watch - supporting open source in education and research
http://www.oss-watch.ac.uk

scott.bradley.wilson at gmail.com
scottbw at apache.org
http://scottbw.wordpress.com
@scottbw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20150613/f08be4ec/attachment.sig>