Re: License recommendation for specs

Hi Egmont,

I don't think it's important to use licensing to prevent incompatible
versions of the specification. Compatibility is important, but it's
ensured by having a single place which everyone agrees is the canonical
version of the specification. Many specifications are also usefully
amended and updated in later versions, to clarify details or add extra
capabilities - this could be harder if the license forbids modifications
and the original author is no longer actively involved.
If there's any doubt on whether an implementation is a derivative work
of the specification, I think it would be best to add a note that
implementations are not meant to be bound by license conditions on the
specification. But I'd favour using a simple permissive license for the
specification in the first place.
Best wishes,
Thomas


On Wed, Jan 2, 2019, at 1:02 PM, Egmont Koblinger wrote:
> Hello,
> 
> I'm new on this list. I've been working on a specification for a few
> months that will kindly be hosted on FDO.> 
> Pretty much the only remaining step is to pick a license for my work.> 
> I've seen some relevant discussions on this mailing list between March-
> May 2018. What I haven't seen, though, is some evaluation of the
> potential licenses and guidelines to pick one, nor the final choices
> you went for.> 
> I tried to read and interpret some of the popular licenses. The lack
> of good web search matches, and in particular [1] and [2] suggest to
> me that there isn't any designed or well suited for specifications.> 
> My first big dilemma: I'm wondering what does "free" mean in the
> context of specifications, and what does FDO want it to mean on its
> site and in its overall vision.> 
> My instincts tell me that a "free specification" should be one that
> everybody is free to implement, without imposing restrictions on the
> implementation. That is: okay to implement in a closed source
> commercial application. As per [1], it's unclear whether an
> implementation of a specification counts as "derived work" or not, and
> thus whether CC BY-SA allows this.> 
> Debian's guideline of being "free" instead seems to focus on the
> modification and distribution of the material in question instead.
> E.g. they only consider GFDL free if it doesn't have an invariant
> section. For a piece of software or documentation, Debian's is a
> reasonable approach. For specifications I don't think so. And this
> leads to my second big dilemma.> 
> For specifications, even for "free" ones, I think it's outright
> undesirable to create and distribute modified work. In order to avoid
> incompatible specifications competing against each other, resulting in
> quite a mess and poor interoperability between implementations,
> contributors should be pushed to improve the original specification
> whenever feasible (e.g. the project is maintained actively), or
> perhaps come up with extensions as separate new projects that
> potentially refer to the original one, but should not create forks and
> slightly altered variants (especially in backwards incompatible ways)
> of the original.> 
> Not sure if this restriction belongs to the license, though, or should
> sort itself out by other means, e.g. by the original work having some
> "respect" and the community refusing to go with forks.> 
> Also note that even if the license chosen for a specification
> disallows the creation of modified work, it should probably still be
> allowed if done with the explicit intent of sending suggested
> modifications back to mainstream. (If I understand correctly, CC BY-ND
> doesn't allow the creation of publicly visible merge request?)> 
> I would not like to release my work to the public domain / CC0 or so.
> Ideally I wouldn't want others to distribute my work (the
> specification itself, or parts of it) commercially, so I'm not keen on
> CC BY either. And, since I'm not a laywer, I wouldn't want to come up
> with something custom.> 
> Something that occurred to me as a little bit of custom, though, is CC
> BY-SA clarifying that implementing in commercial apps is okay. Since
> I'm not confident enough to amend the CC license by a sentence,
> technically I'm thinking of addressing it by dual-licensing my work
> under CC BY-SA and a self-written sentence along the lines of "okay to
> implement anywhere, all other rights reserved". Users would need to
> pick one of these two, contributors would need accept this OR-
> combination of them. This is the approach I like the most so far, but
> I'm not sure if it makes sense to you guys too, or if maybe you see a
> red flag.> 
> Or, what happens if I just release without any licensing? What are the
> downsides of that approach? Why is it important or encouraged to have
> a license? Aren't the "legal defaults" of any published work without a
> license good enough, and perhaps closer to what I imagine than any of
> these existing license texts? Note that most of the standards I used
> during my work, e.g. ECMA ones, come without a license.> 
> What do you guys think of these? Which licenses did you consider?
> Which ones do you or do you not recommend? Which one did you end up
> choosing for specifications, and what were the main reasons behind
> your decisions?> 
> Thanks a lot,
> 
> egmont
> (gnome-terminal/vte developer)
> 
> [1] https://lu.is/blog/2008/03/27/brief-cc-licensed-specification-rant/> [2] https://creativecommons.org/2008/03/29/what-good-is-a-cc-licensed-specification/> _________________________________________________
> xdg mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg